[petsc-dev] DMplex reader / viewers

[Blaise A Bourdin]

On Jan 22, 2014, at 11:16 AM, Brad Aagaard <baagaard at usgs.gov> wrote:

> 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.


How about the following strategy:
1. implement Q&D exodus / silo / whatever format based on Jed’s current VTU. It should be a good exercise in understanding PetscSF.
2. write a scalable hdf5 / xdmf scheme starting from the code already in pylith. Last time I checked, the pylith xdmf scheme used multiple files (1 per cell block / time step), and did not allow to preserve continuity of fields across cell sets (because it does not make sense to do so in its applications). Would the scheme from the attached xmf and hdf5 files make sense? It was an old attempt at translating from exodus to xdmf without loss of information.

Blaise
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Beam-0000.xmf
Type: application/octet-stream
Size: 359050 bytes
Desc: Beam-0000.xmf
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140122/f532c305/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Beam-0000.h5
Type: application/octet-stream
Size: 612320 bytes
Desc: Beam-0000.h5
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140122/f532c305/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140122/f532c305/attachment.txt>