[Dune] Dune Digest, Vol 108, Issue 9
Andreas Dedner
a.s.dedner at warwick.ac.uk
Fri Jun 27 13:14:56 CEST 2014
Hi.
The dgfwriter knows nothing about the gmsh file. It just takes a
constructed grid and
produces a dgf file from the leaf level of that grid. Boundary id are
written to that file
taking the intersection.boundaryId method which is not standard.
The gmsh writer might read your id but it is not used during grid
creation so the
grid that the gmsh reader produces does not have those ids any more (but
just a default 1).
My question is now:
does the gmsh reader store the boundary ds that it obtained from the
gmsh file and does it have some method so that the user can extract them
after grid creation
something like gmshreader.boundaryData( intersection ) or whatever.
If it does you can go into the dgfwriter.hh and modify the line where it
uses the method intersection.boundaryId() replacing it with the
gmshreader.boundaryData( intersection ) method or whatever the Gmsh
reader provides
to access the data provided in the gmsh file (provide it has such a
method in place).
Hope that clears it up
Andreas
On 27/06/14 11:45, Jelena Griz(ic' wrote:
> Gmsh writes elements this way:
>
> elm-number elm-type number-of-tags < tag > ... node-number-list
>
> In my code there are two tags: physical entity (which has to be
> written to boundarysegments block of dgf file) and elementary
> geometrical entity.
>
> Part of gmsh reader responsible for "reading" boundary elements:
>
> for (int i=1; i<=number_of_elements; i++)
> {
> int id, elm_type, number_of_tags;
> readfile(file,3,"%d %d %d ",&id,&elm_type,&number_of_tags);
> int physical_entity = -1;
> std::vector<int> mesh_partitions;
> if ( version_number < 2.2 )
> {
> mesh_partitions.resize(1);
> }
> for (int k=1; k<=number_of_tags; k++)
> {
> int blub;
> readfile(file,1,"%d ",&blub); -> PICKS UP PHYSICAL
> ENTITY FROM FILE
> if (k==1) physical_entity = blub; ->SAVING PHYSICAL ENTITY
> FOR PASSING FURTHER
> // k == 2: elementary entity (not used here)
> if ( version_number < 2.2 )
> {
> if (k==3) mesh_partitions[0] = blub;
> }
> else
> {
> if (k > 3)
> mesh_partitions[k-4] = blub;
> else
> mesh_partitions.resize(blub);
> }
> }
> pass2HandleElement(file, elm_type, renumber, nodes,
> physical_entity);
> }
>
> Reader picks up wright physical entities (checked by printing them
> out) but I coudn't figure out where they "get lost" on the way to dgf
> writer.
>
>
> 2014-06-27 12:00 GMT+02:00 <dune-request at dune-project.org
> <mailto:dune-request at dune-project.org>>:
>
> Send Dune mailing list submissions to
> dune at dune-project.org <mailto:dune at dune-project.org>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.dune-project.org/mailman/listinfo/dune
> or, via email, send a message with subject or body 'help' to
> dune-request at dune-project.org <mailto:dune-request at dune-project.org>
>
> You can reach the person managing the list at
> dune-owner at dune-project.org <mailto:dune-owner at dune-project.org>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dune digest..."
>
> Today's Topics:
>
> 1. Re: Fwd: gmsh2dgf (Oliver Sander)
> 2. Re: Fwd: gmsh2dgf (Andreas Dedner)
>
>
> ---------- Proslije?ena poruka ----------
> From: Oliver Sander <sander at igpm.rwth-aachen.de
> <mailto:sander at igpm.rwth-aachen.de>>
> To: dune at dune-project.org <mailto:dune at dune-project.org>
> Cc:
> Date: Thu, 26 Jun 2014 15:53:23 +0200
> Subject: Re: [Dune] Fwd: gmsh2dgf
> Hi,
> I don't know much about either dgf or the
> EXPERIMENTAL_GRID_EXTENSIONS.
> It may well be that the gmshreader contains a bug (it was me who
> wrote parts
> of it, after all :-) ) but to look into that we'd need a more precise
> report of what's going wrong.
> Best,
> Oliver
>
> Am 26.06.2014 11 <tel:26.06.2014%2011>:52, schrieb Andreas Dedner:
> > Hi,
> >
> > Since you are getting the boundarysegment block in your dgf
> file, you seem to be using
> > the DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS so that
> intersection.boundaryId() is
> > available. The problem is that adding boundary ids was decided
> to be unnecessary.
> > I don't know that much about the gmsh format or the reader to
> know if boundary id information
> > from the gmsh file is in some way passed on to the user. If so
> it will not be made available ithriough
> > the intersection.boundaryId method but stored somehow externally
> and you will have to modify the
> > code in io/file/dgfparser/dgfwriter.hh accordingly
> > (search for iit->boundaryId(); and replace that call).
> >
> > Perhaps experts on gmsh to provide the way to get the boundary
> ids out of the gmsh file.
> >
> > Best
> > Andreas
> >
> >
> > On 26/06/14 07:19, Jelena Griz(ic' wrote:
> >> Dear all,
> >>
> >> I have a problem using gmsh2dgf (also applies to
> gmshreader.hh): it doesn't seem to pick boundary segment ids
> from.msh file rather using some default value (1) for all boundary
> elements.
> >>
> >> Example of .msh and .dgf file obtained using gmsh2dgf are in
> attachment.
> >>
> >> Thank you in advance,
> >>
> >> Jelena Grizic
> >>
> >>
> >>
> >> _______________________________________________
> >> Dune mailing list
> >> Dune at dune-project.org <mailto:Dune at dune-project.org>
> >> http://lists.dune-project.org/mailman/listinfo/dune
> >
> >
> >
> >
> > _______________________________________________
> > Dune mailing list
> > Dune at dune-project.org <mailto:Dune at dune-project.org>
> > http://lists.dune-project.org/mailman/listinfo/dune
> >
>
>
>
>
> ---------- Proslije?ena poruka ----------
> From: Andreas Dedner <a.s.dedner at warwick.ac.uk
> <mailto:a.s.dedner at warwick.ac.uk>>
> To: <dune at dune-project.org <mailto:dune at dune-project.org>>
> Cc:
> Date: Thu, 26 Jun 2014 16:28:19 +0100
> Subject: Re: [Dune] Fwd: gmsh2dgf
> My question has nothing to do with dgf or experimental grid
> extensions.
> The dgfwriter just takes a grid and used the
> intersection.boundaryId() method to write
> the ids into the file (that method is now only available with
> DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS
> So that will not work since the gmsh reader will not set these
> boundaryId so that this
> metod could actually read them.
>
> So the question is: how can the user extract boundary data
> provided in a gmsh file using the
> gmsh reader. So just a question about gmsh and the reader not
> about dgf or any grid extensions....
>
> Best
> Andreas
>
> On 26/06/14 14:53, Oliver Sander wrote:
>> Hi,
>> I don't know much about either dgf or the EXPERIMENTAL_GRID_EXTENSIONS.
>> It may well be that the gmshreader contains a bug (it was me who wrote parts
>> of it, after all :-) ) but to look into that we'd need a more precise
>> report of what's going wrong.
>> Best,
>> Oliver
>>
>> Am26.06.2014 11 <tel:26.06.2014%2011>:52, schrieb Andreas Dedner:
>>> Hi,
>>>
>>> Since you are getting the boundarysegment block in your dgf file, you seem to be using
>>> the DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS so that intersection.boundaryId() is
>>> available. The problem is that adding boundary ids was decided to be unnecessary.
>>> I don't know that much about the gmsh format or the reader to know if boundary id information
>>> from the gmsh file is in some way passed on to the user. If so it will not be made available ithriough
>>> the intersection.boundaryId method but stored somehow externally and you will have to modify the
>>> code in io/file/dgfparser/dgfwriter.hh accordingly
>>> (search for iit->boundaryId(); and replace that call).
>>>
>>> Perhaps experts on gmsh to provide the way to get the boundary ids out of the gmsh file.
>>>
>>> Best
>>> Andreas
>>>
>>>
>>> On 26/06/14 07:19, Jelena Griz(ic' wrote:
>>>> Dear all,
>>>>
>>>> I have a problem using gmsh2dgf (also applies to gmshreader.hh): it doesn't seem to pick boundary segment ids from.msh file rather using some default value (1) for all boundary elements.
>>>>
>>>> Example of .msh and .dgf file obtained using gmsh2dgf are in attachment.
>>>>
>>>> Thank you in advance,
>>>>
>>>> Jelena Grizic
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dune mailing list
>>>> Dune at dune-project.org <mailto:Dune at dune-project.org>
>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org <mailto:Dune at dune-project.org>
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org <mailto:Dune at dune-project.org>
>> http://lists.dune-project.org/mailman/listinfo/dune
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org <mailto:Dune at dune-project.org>
> http://lists.dune-project.org/mailman/listinfo/dune
>
>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20140627/9a9d7b16/attachment.htm>
More information about the Dune
mailing list