[petsc-users] MWE for DMPlexCreateCGNS

Matthew Knepley knepley at gmail.com
Tue Feb 5 13:01:29 CST 2019


On Tue, Feb 5, 2019 at 11:13 AM Andrew Parker <andy.john.parker at gmail.com>
wrote:

> On Tue, 5 Feb 2019 at 15:27, Matthew Knepley <knepley at gmail.com> wrote:
>
>> On Tue, Feb 5, 2019 at 9:47 AM Andrew Parker via petsc-users <
>> petsc-users at mcs.anl.gov> wrote:
>>
>>> Does anyone have a MWE for DMPlexCreateCGNS to use in parallel? Ideally,
>>> read parallel, distribute in parallel, construct ghost cells (for parallel
>>> comms and halos for physical boundaries)? It's for a cell-centered solver
>>> working with cgns meshes.  Is there any limitation on cell-types?
>>>
>>
>> 1) CGNS is a terrible format, unfortunately. Are you sure about
>> committing to it? Always best to question design decisions before lots of
>> code has been written.
>>
>
>> 2) DMPlexCreateCGNS() probably works, but it has not been tested
>> exhaustively.
>>
>
>> 3) It does not work in parallel, and is unlikely to in the near future.
>> In order to read in parallel, you should be able to nicely select
>>     blocks from disk in the format, and also have local BC specification
>> (rather than global numbers). MED is a nice format like this.
>>     It is the CASCADE format, and GMsh uses it internally. We can now
>> read MED in parallel. Without too much work, we could also
>>     read ExodusII in parallel I think.
>>
>
> Do you have a MWE for either of those two formats then?
>
> Key for me is to be in parallel by the time the setup stage is finished,
> if there is some serial reading here and there at the initial phase that's
> fine.  For a cell-centered code I just want to go from file read to
> parallel distribute, parallel ghost-cell creation, physical halo creation,
> and boundary condition (faces, edge in 2D) marking re-using as much of the
> petsc DMPlex system as possible.
>

Oh, that is fine then.


> My main requirement with any file format is the ability in a mesh/cad
> package to mark complex groups of edges/faces/cells together (on the
> boundary but also groupings of cells in the volume) to infer groups and
> therefore bcs, or material regions etc.  I am aware med/exo provide this:
> my reason for picking cgns is that is central to their format also.  I need
> to ensure for complex geometry and meshes, that if the file format does
> encode groupings/bcs then these are accessible after the parallel
> distribution phase in complete.  It would help me massively if there were
> an example that does all of this....I'll jump ship on file format to get
> that.
>

I think it should be fine to use CGNS for you. How about you make a small
CGNS file with some marked boundaries
and I will help get that in as a PETSc example (we can use Plex ex1 to read
it in and write out the Plex).

  Thanks,

     Matt


> Thanks,
> Andy
>
>>
>> 4) Once read, you get a regular Plex, so you can redistribute, make ghost
>> cells, etc. as you can for any Plex mesh.
>>
>> 5) As long as all you want Plex to do is manage topology and field data,
>> then you can have whatever mix of cell types you want.
>>
>> 6) Limitations on cell types come from routines that calculate geometric
>> quantities, integrate, etc.
>>
>>   Thanks,
>>
>>      Matt
>>
>
>
>>
>>
>>> Thanks,
>>> Andy
>>>
>>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>> https://www.cse.buffalo.edu/~knepley/
>> <http://www.cse.buffalo.edu/~knepley/>
>>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20190205/9feb6727/attachment-0001.html>


More information about the petsc-users mailing list