search

clawpack / visclaw

Clawpack visualization tools
http://www.clawpack.org
BSD 3-Clause "New" or "Revised" License
29 stars 47 forks source link

Fort files are incorrectly labelled as "from an old run" #168

Closed cjvogl closed 8 years ago

cjvogl commented 8 years ago

In frametools.py, line 1428, there's code to account for fort files that are closed "out of order": delaytime = 5. With some large runs, I'm seeing more than 5 seconds inbetween consecutive fort files. Is there a reason for this check with the output directory being cleared of fort files before each run?

rjleveque commented 8 years ago

The reason for discarding files that don't appear to be from the latest run is so that they don't accidentally contaminate _PlotIndex.html or an animation, in cases when you do a run with fewer output frames than the previous run.

It's checking for later files in the sequence that were closed more than 5 seconds before an earlier file. Are you seeing cases where e.g. fort.q0005 is closed more than 5 seconds before fort.q0004? For a large run that takes a long time to output, I would think this would be less of a problem than for a smaller run.

cjvogl commented 8 years ago

I think my case is a unique one: I have fort.q0136 with a timestamp of 16:42... and fort.q0137 with a timestamp of 11:50. This happened in two runs on HYAK, so either HYAK travelled back in time or there was a problem with the system clock. It seems to be somewhat isolated (ie there are runs from HYAK that don't have this problem). I see now that in runclaw, old fort files aren't removed if overwrite is set to false, and now the utility of the check makes more sense to me. Thanks!