<p dir="ltr"><br>
On Feb 25, 2014 9:48 AM, "Michael Lange" <<a href="mailto:michael.lange@imperial.ac.uk">michael.lange@imperial.ac.uk</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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.<br>

><br>
> 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:<br>
> a) Add the ex_open() call to DMPlexCreateExodus() and change the interface to use the file name directly<br>
> b) Add a utility function DMPlexCreateExodusFromFile() which calls ex_open and then invokes DMPlexCreateExodus() as before<br>
><br>
> Please tell me what you think and which way you prefer, and I will provide a pull request to implement this.</p>
<p dir="ltr">I like b). Very often users want to control their own files. Note that you can make the ex_open() call without appealing to your system since PETSc has already linked it.</p>
<p dir="ltr">   Matt</p>
<p dir="ltr">> Kind regards,<br>
><br>
> Michael Lange<br>
</p>