On Feb 25, 2014 9:48 AM, "Michael Lange" <[email protected]> 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. Note that you can make the ex_open() call without appealing to your system since PETSc has already linked it. Matt > Kind regards, > > Michael Lange
