[petsc-dev] DMplex reader / viewers

Brad Aagaard baagaard at usgs.gov
Wed Jan 22 11:16:20 CST 2014


On 01/22/2014 08:57 AM, Jed Brown wrote:
> Moving back to list.
>
> Blaise A Bourdin <bourdin at lsu.edu> writes:
>
>> On Jan 21, 2014, at 11:20 AM, Jed Brown <jed at jedbrown.org> wrote:
>>
>>> Matthew Knepley <knepley at gmail.com> writes:
>>>>    - Reading from or writing to exodus files is not supported.
>>>>>
>>>>
>>>> Yes, I think this is the best target. It should be similar to writing HDF5
>>>> that we do for PyLith.
>>>
>>> How are we going to represent high-order elements in Exodus?  Doesn't it
>>> only support quadratic continuous spaces?  What about DG spaces, H(div)
>>> spaces, or higher than second order?
>>
>> It only supports first and second order elements. I don’t think that continuity is an issue. Nothing prevents you to alter the connectivity table.
>> Element types is set by blocks, so mixing polynomial orders is not possible without some trickery
>
> Do we consider this an acceptable long-term solution?
>

I see a DMPlex layout for HDF-5 files as a convenient means of providing 
fast, parallel I/O with Xdmf files as a means to provide a way for 
ParaView/Visit, etc to be able to display much of the info within the 
HDF5-files without custom plug-ins. Plug-ins might be necessary for 
specialized information that can't be expressed in Xdmf files. We deal 
with end-users with limited programming experience for which plug-ins 
might be difficult.

For PyLith, I like being able to use h5py for high-level access to the 
info in the HDF5 files for post processing.

We have plans to add higher order basis functions to PyLith this spring, 
and recognize the deficiencies in many of the available formats. It 
would be nice to have a consistent way to deal with DMPlex I/O and these 
other issues (boundaries, high order, etc) across various codes using 
DMPlex.

Brad




More information about the petsc-dev mailing list