[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