[Gmsh] Bug when loading 2 files resulting from a domain decomposition solve

[Karin&NiKo]

Dear Christophe,

First I would like to thank you warmly for your  responsiveness : the new
feature is great.

I have 2 remarks :
- I think their is a little bug when you rebuild the Physicals from the med
result file. In order to check it, I have attached an archive containing
the initial mesh + the 2 partitioned meshes (you can see their are 2 new
Physicals called joint_1 and joint_2 that are the interfaces between the
subdomains)

- I would like to know if it is possible to produce the following view : I
would like to load the different results files, and, on the global view,
display the interfaces (the join_* Physicals)? I have not succeeded in
doing that (when trying to display the interfaces, Gmsh also displays the
view on these Physicals).

Regards,
Nicolas

2013/1/27 Christophe Geuzaine <cgeuzaine at ulg.ac.be>

>
> Hello Nico - Could you test with the next nightly? When reading MED files
> we now use the filename as a kind of "partition indicator". This should fix
> the problem that you encountered, which is linked to the fact that your MED
> file has not a full profile, but uses implicit entity indexing.
>
> Christophe
>
> On 25 Jan 2013, at 14:55, Karin&NiKo <niko.karin at gmail.com> wrote:
>
> > Dear Gmsh Gurus,
> >
> > The attached archive contains 2 med files resu.proc.0.med and
> resu.proc.1.med, that result from a parallel solve with a domain
> decomposition approach.
> > But, when loaded in Gmsh, the visu is all but correct : this can be
> easily checked by loading the files separately.
> >
> > Is it a bug? Perhaps this feature is not in Gmsh yet.
> >
> > Thanks,
> > Niko
> > _______________________________________________
> > gmsh mailing list
> > gmsh at geuz.org
> > http://www.geuz.org/mailman/listinfo/gmsh
>
> --
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130128/dc678b85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAIL.7z
Type: application/octet-stream
Size: 477174 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130128/dc678b85/attachment.7z>