Re: [Libmesh-users] Subdomain_id not getting set when reading Gmsh meshes

[Arvind A. <arv...@gm...>]

Thanks a lot everyone! I am happy and relieved that I can use Gmsh meshes
with libmesh.

Regards
Arvind

On Wed, Oct 28, 2009 at 10:08 PM, Vijay S. Mahadevan <vi...@gm...>wrote:

> Arvind, If you are interested in storing the surface/volume ids for
> each element, you need to create additional data in Elem class. This
> would be very similar to the subdomain_id() method. And you could also
> set the partition while reading the mesh but I do not know how this
> would affect the mesh topology or partitioning that internally goes on
> through ParMetis interface. Hence, I've commented these out but it
> should be easy to add/change this in read_mesh().
>
> For others who are not interested in using this extra memory, may be
> we can make this as a configurable option ? If not, whoever needs this
> functionality can add it themselves as and when a need occurs.
>
> Roy, I've attached the patch for the GmshIO.C file. I removed all
> references to mesh_data and so this should not intervene if you decide
> to pull this class out of the library later. If any of the additional
> changes do not follow libmesh coding patterns, feel free to change
> them.
>
> And do test the code with a ".msh" file using example 1. Let me know
> if you have any questions.
>
> Vijay
>
> On Tue, Oct 27, 2009 at 7:16 PM, Arvind Ajoy <arv...@gm...> wrote:
> > Thanks for the immediate replies.
> >
> > @Vijay : I look forward to the functionality in your patch! My work
> involves
> > setting
> > bound charges between dielectrics. I was in fact thinking about how I
> could
> > handle these interfaces ... I guess having surface_ids in a 3D mesh will
> > allow me to solve the problem.
> >
> > @Dave : I am using r3510. Could the problem arise from the fact that
> ex1.C
> > uses the function mesh.read( ) .... is there something special that needs
> to
> > be done for Gmsh
> > meshes?
> >
> > Regards
> > Arvind
> >
> > On Wed, Oct 28, 2009 at 4:56 AM, Roy Stogner <roy...@ic...>
> > wrote:
> >>
> >> On Wed, 28 Oct 2009, Arvind Ajoy wrote:
> >>
> >>> I am trying to read in a simple mesh created using Gmsh, which has
> >>> two Physical regions.  I use the example programme ex1.cc to read
> >>> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2
> >>> in.msh out.msh.
> >>>
> >>> I find that the output of ex1.cc mentions n_subdomains()=1, though
> >>> there are two physical regions.
> >>
> >> Interesting...
> >>
> >> MeshBase::n_subdomains() has been around since 2005, when Ben added
> >> it (presumably to Mesh, back then?). MeshBase::set_n_subdomains()
> appears
> >> to be an easy accessor that Derek
> >> added earlier this year... but other than a little overloading in the
> >> BoundaryInfo::sync() method, I can't find anywhere that subdomain
> >> counts are actually getting *set* rather than just copied around!
> >>
> >> I suppose a typical use case is for the user code to set subdomain
> >> ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O...
> >> yet none of that code seems to update the total mesh id count.
> >>
> >> Ben, Derek, anyone else know what I'm missing?  It seems as if
> >> updating MeshBase::_n_sbd ought to be a standard part of
> >> prepare_for_use(), but isn't...
> >> ---
> >> Roy
> >
> >
>