Hi Matt,
On 25/02/14 15:41, Matthew Knepley wrote:
On Feb 25, 2014 9:48 AM, "Michael Lange" <michael.la...@imperial.ac.uk
<mailto:michael.la...@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
