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 <vijay.m@gmail.com> 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 <arvindajoy@gmail.com> 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 <roystgnr@ices.utexas.edu>
> 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
>
>