search

visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
438 stars 116 forks source link

Visit visualization error with Silo time series #4845

Closed eschnett closed 4 years ago

eschnett commented 4 years ago

I have a time series of 3d data in Silo format, with one iteration per file. When I visualize the file for one particular iteration (192) directly, I see the expected result. When I open all files together (as "database") and choose the respective iteration, then the output is wrong. This error does not occur when I output the data as Plotfile instead of Silo.

I am using a Pseudocolor plot with a Slice and an Edge operator. I attach the two outputs as screen shots. For reference, the simulation advects a square by rotating it about the Z axis; shown in the X-Y plane. The calculation uses adaptive mesh refinement. The expected output is a rotated, slightly blurred square. The physical content of the simulation is a priori not relevant here. The visualization has two errors: (1) the fine grid does not cover the square, and (2) there is an outline of an unrotated square visible. Since the same data also produces a good visualization, I assume that some part of VisIt gets confused as to what the grid structure is, and accesses the wrong data of the wrong iteration. This is, of course, just a guess from the outside.

I am using VisIt 3.1.2 on MacOS, with a binary downloaded from https://wci.llnl.gov/simulation/computer-codes/visit. I also attach session files. I put the simulation output into a git repository at https://github.com/eschnett/square-l2. The session file is here visit0000.session.gz. The GUI session file is here visit0000.session.gui.gz.

The data were produced by AMReX. I used their built-in Plotfile output routines. The Silo data were produced via the silo-4.10.2-bsd library.

To Reproduce

To show the bad (wrong) output:

  1. Open data file square-l2.visit (see git repo)
  2. Create Pseudocolor plot for variable advecthrsc_phi
  3. Add Slice operator
  4. Set Slice operator to "orthogonal to Z"
  5. Add Edge operator (to view grid structure)
  6. Go to iteration 192
  7. Draw

To show the good (correct) output:

  1. Open data file square-l2.it00000192.silo (see git repo)
  2. Create Pseudocolor plot for variable advecthrsc_phi
  3. Add Slice operator
  4. Set Slice operator to "orthogonal to Z"
  5. Add Edge operator (to view grid structure)
  6. Draw

Attachments

Desktop

markcmiller86 commented 4 years ago

@eschnett thanks for this super detailed report and associated data! Very helpful in diagnosing cause.

Just curious...did you happen to try the nuclear option...VisIt->Preferences->Databases... check the box for Treat all databases as time varying? Its a potential performance killer but am wondering if it might fix your current issues

eschnett commented 4 years ago

I confirm that this preference corrects the problem! Thank you.

Do you think that this is an issue in VisIt, or is there a setting missing in the Silo files? For example, could there an "iteration" tag missing on one of the grid structures?

Each Silo file corresponds to a single iteration and is written independently, then these files are "stitched together" via a *.visit file. Is there a way to indicate to VisIt that the grid structure is changing?

markcmiller86 commented 4 years ago

Do you think that this is an issue in VisIt, or is there a setting missing in the Silo files? For example, could there an "iteration" tag missing on one of the grid structures?

You can have the Silo database tell VisIt to treat it is time varying by having the data producer do the following...

int n = 1;
DBWrite(dbfile, "/MetadataIsTimeVarying", &n, &n, 1, DB_INT);

in every file.

I suspect always doing this for an AMR code like AMReX is probably ok. But, in truth, it only needs to be done for those time series where metadata is indeed time varying. Thats a bit of a squishy subject though. If material names or counts change, number of levels of refinment or domain counts change (which is common in AMR data) or if the list of variables defined on the mesh changes with timesteps, then a good first step is to declare metadata is time varying by adding this variable, with a value of non-zero, to the files.

I don't regard this as a bug per-se. I do think VisIt can sometimes try a bit too hard to be performance optimal (e.g. avoid reading files it doesn't think it should have to) at the expense of other good behavior. That is what is going on here.

eschnett commented 4 years ago

Thanks for the quick help. The MetadataIsTimeVarying does the trick.

I wonder whether this is documented somewhere, or whether this is one of these gems that gets passed orally from mage to apprentice.

markcmiller86 commented 4 years ago

I wonder whether this is documented somewhere, or whether this is one of these gems that gets passed orally from mage to apprentice.

That specific case, no, I don't think it is documented anywhere. Just added #4847. There are other such variables documented in the Silo User's Manual