> On Nov 28, 2017, at 12:39 AM, Jed Brown <[email protected]> wrote: > > Blaise A Bourdin <[email protected]> writes: > >> There may be good reasons to want to read / write in a given ordering: >> post-processing an existing computation, applying non trivial boundary >> conditions that need to be computed separately, or restarting a computation >> on a different number of processors. >> Also, Exodus has restriction on cell ordering (cells in an element block >> must be numbered sequentially) so the distributed cell ordering may not be >> acceptable. > > Does PETSc have the ability to write Exodus files? Yes, if this is a > requirement then that viewer needs to reorder in some way to write. > > For concreteness, what postprocessors are you thinking about here that > need an ordering that matches that of the input file? (I ask because I > usually see the simulation writing a different format from the input > file, and often viewed using different tools.)
I have a bunch that I wrote myself. For example: computing stress intensity factor using the G_theta method. This involves computing integrals but not solving linear systems, it can be run on a much smaller system than the analysis itself. It would be a pain to have to move back the data file to a large syste and requeue in order to get the same parallel layout. But the main difficulty with exodus is that the distributed cell ordering is not necessarily admissible for exodus element blocks, and that exodus cell sets are not implemented in most tools... Fine elements file formats are a mess and there are very few formats for which mesh generator, visualization, and I/O library are available. Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
