Hi Greg, Thanks for the info. I've briefly gone through the ExodusII Sandia report at http://prod.sandia.gov/techlib/access-control.cgi/1992/922137.pdf but didn't notice any information on parallel sets. Is that available some place that I can look at?
Thanks, Andy On Thu, Jan 19, 2017 at 12:17 PM, Sjaardema, Gregory D <[email protected]> wrote: > It is legal to create an exodus file with no nodes and no elements. If > that file is part of a parallel set (using file-per-processor mode), then > that “empty” file should have consistent metadata (block counts, sideset > counts, …), but it is allowed to have zero nodes and elements. > > ..Greg > > -- > "A supercomputer is a device for turning compute-bound problems into > I/O-bound problems” > > On 1/13/17, 2:13 PM, "ParaView on behalf of David Thompson" < > [email protected] on behalf of [email protected]> > 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. > > > At this point I'm thinking it's better to modify the reader than the > writer... > > I would be very wary of this. > > David > > > > > On Fri, Jan 13, 2017 at 2:59 PM, Andy Bauer <[email protected]> > 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 < > [email protected]> 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:[email protected]] On Behalf Of > Andy Bauer > > Sent: Friday, January 13, 2017 12:00 PM > > To: [email protected] > > 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 > > _______________________________________________ > 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 > > >
_______________________________________________ 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
