[Paraview] exodusII reader & writer in parallel

[Andy Bauer]

On Fri, Jan 13, 2017 at 4:13 PM, David Thompson <david.thompson at kitware.com>
wrote:

> Hi all,
>
> > It's looking like there could be a decent amount of hacking in the
> ExodusII code to get the writer to work properly for this (as well as the
> reader to read it back in without issues). The main issue appears to be
> that NetCDF doesn't allow creating a dimension of 0 length/size. Thus the
> stuff in VTK/ThirdParty/exodusII/vtkexodusII would need to be changed.
> >
> > Both the reader and writer make the assumption that if the num_nodes
> dimension exists that there are points to be read in.
>
> Yes, that is a basic assumption of the Exodus file format: each rank is
> assigned a subset of the cells and nodes in the simulation domain, since
> otherwise there is no state to store. If rank 0 of a simulation has no
> nodes (and thus cannot have cells either), then it should probably not
> participate in writing the Exodus dataset. You could create an MPI
> subcontroller without the rank 0 process and have the writer use that.
>

My worry here is that with the processes that have data possibly changing
between time steps I'm not sure how well it would be read back in since
there probably isn't a regular way to deal with that. The current ExodusII
reader complained trying to read in parallel.ex2.4.[1,2,3]
if I just deleted parallel.ex2.4.0. Also, how would time be supported in
this?


>
> > At this point I'm thinking it's better to modify the reader than the
> writer...
>
> I would be very wary of this.
>

Yeah, this scares me as well with all of the blocks that ExodusII wants to
have in there but my thought was to basically skip reading in files that
had the num_nodes dimension not specified. Maybe there just isn't a good
solution here based on the format requirements. I'll test out modifying the
reader though and see what happens...


>
>         David
>
> >
> > On Fri, Jan 13, 2017 at 2:59 PM, Andy Bauer <andy.bauer at kitware.com>
> wrote:
> > Hi Ken,
> >
> > Thanks for the input.
> >
> > There is an explicit check in the writer to see if there are any points
> before writing out point data. I took that check out and am hitting a
> NetCDF error that the "num_nodes" dimension isn't specified. It will
> probably take a bit of investigating to fix this but at least you've helped
> me go down the correct path.
> >
> > Thanks,
> > Andy
> >
> > On Fri, Jan 13, 2017 at 2:44 PM, Moreland, Kenneth <kmorel at sandia.gov>
> wrote:
> > Andy,
> >
> >
> >
> > That sounds like a bug in our Exodus writer to me. I’m not positive, but
> I’m pretty sure that you can specify in Exodus point and cell arrays if no
> grid points or cells exist. The writer is probably making a shortcut and
> skipping that if there is no actual data.
> >
> >
> >
> > -Ken
> >
> >
> >
> > From: ParaView [mailto:paraview-bounces at paraview.org] On Behalf Of Andy
> Bauer
> > Sent: Friday, January 13, 2017 12:00 PM
> > To: paraview at paraview.org
> > Subject: [EXTERNAL] [Paraview] exodusII reader & writer in parallel
> >
> >
> >
> > Hi,
> >
> > I'm trying out the ExodusII writer in parallel and had some questions
> about how it should work in general when there isn't any data on process 0.
> Currently what happens in ParaView is that a file for each process is
> written out but the file corresponding to process 0 doesn't have any grid
> information or field data (an example is attached). When I read this back
> into ParaView using the built-in server (i.e. in serial) the ExodusII
> reader gets the proper points and cells but no field data is read in.
> >
> > So my question is this, does the ExodusII file format allow specifying
> point and cell arrays in a file if no grid points or cells exist?
> >
> > I'm tempted to fix this issue by modifying the reader to properly pass
> the field data information to process 0 from another one that has data but
> wanted to get the community's thoughts on this before I go through the
> implementation. The alternative would be to modify the writer to include
> point and cell data information and that's probably a better solution,
> assuming that the ExodusII format allows for that.
> >
> > Thanks,
> >
> > Andy
> >
> > ps. Attached is a sample set of ExodusII files that doesn't have any
> data on parallel.ex2.4.0 in case someone wants to play around with it.
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
> >
> > Search the list archives at: http://markmail.org/search/?q=ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/paraview
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20170113/e594aa1a/attachment.html>