[petsc-dev] DMPlexCreateExodus directly from file

[Michael Lange]

Hi Matt,

On 25/02/14 15:41, Matthew Knepley wrote:
>
>
> On Feb 25, 2014 9:48 AM, "Michael Lange" <michael.lange at imperial.ac.uk 
> <mailto:michael.lange at imperial.ac.uk>> wrote:
> >
> > Hi,
> >
> > I keep hitting problems in my application code when I try to read in 
> ExodusII meshes via DMPlex due to the exodus libs installed on my 
> system. I can get around those simply by adding adding the ex_open() 
> call required to get the exoid directly to DMPlexCreateExodus(). This 
> solution works great with the ExodusII version PETSc downloads during 
> configure and also makes the DMPlex-ExodusII interface self-contained, 
> which means that I do not have to link my application code against 
> exodus libs at all. The same argument applies to the DMPlex-CGNS 
> interface.
> >
> > So, I would like to prepare a pull request to make the ExodusII 
> (CGNS) interface self-contained, and I can see two ways to do this:
> > a) Add the ex_open() call to DMPlexCreateExodus() and change the 
> interface to use the file name directly
> > b) Add a utility function DMPlexCreateExodusFromFile() which calls 
> ex_open and then invokes DMPlexCreateExodus() as before
> >
> > Please tell me what you think and which way you prefer, and I will 
> provide a pull request to implement this.
>
> I like b). Very often users want to control their own files.
>
Great, I just sent a pull request that implements b).
>
> Note that you can make the ex_open() call without appealing to your 
> system since PETSc has already linked it.
>
Usually yes, but I want to use ExodusII/CGNS meshes via the recently 
added DMPlex Python wrappers in petsc4py, which is much cleaner if the 
mesh files are handled by PETSc.

Thanks,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140226/571aa4d1/attachment.html>