[Paraview] exodusII reader & writer in parallel

[David Thompson]

Hi Andy,

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

Exodus assumes the node IDs and cell-connectivity are time-constant within a single file. Each timestep the number of nodes and/or cells changes, a new Exodus file should be created. There's a convention for how filenames should change at adaptation steps as opposed to process rank.

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

Be aware that the vtkPExodusIIReader behaves differently on rank 0; during UpdateInformation, I believe it is the only rank to do some tasks in order to avoid slamming parallel filesystems with tons of identical requests. I know one of the tasks it does it discover the list of files to split among the ranks. I'm less sure about transmitting lists of array names to all processes, but it may do that from its own list of arrays, too. There was a problem long ago (that got fixed) where element blocks with no cells were missing arrays -- I don't think we've ever had processes with no points/nodes, though.

	David