truncated output for terminated/inactive particles

[jtwhite79]

When a particle terminates or becomes inactive, the pathline and timeseries files seem to stop reporting about that particle for any remaining sim times. This is probably fine in most cases, but if you are using particles with PEST(++), having the mp7 output files change record sizes makes things difficult. Any chance to write out terminated/inactive particles across all sim times? Maybe there is an option for this that I missed somewhere?

[aprovost-usgs]

@jtwhite79 Thanks for the suggestion - I can see how that would create headaches. I'll look into what it would take to include that option.

[aprovost-usgs]

@jtwhite79 With respect to pathline results, each particle is on its own schedule, so to speak, and it seems inevitable that you'll generally get a different number of pathline records for each particle. But for timeseries output, evening out the number of records by including all particles is relatively straightforward. I've coded up that option and should be ready to post the commit shortly.

[aprovost-usgs]

@jtwhite79 ... I should add that in the case of pathline results, it seems there's no guaranteeing the number of records for a given particle won't change from one run to the next, which I guess is the real issue you're facing with the parameter estimation runs.

[jtwhite79]

Yup that's the problem. I think getting the timeseries file evened out will be a big help!

[aprovost-usgs]

@jtwhite79 Timeseries output did not include inactive particles or particles pending release, resulting in variable numbers of timeseries records, which complicated processing of output for parameter estimation, for example. Commit 6930530 includes a new TimeseriesOutputOption (optional at the end of Item 3 of the Simulation File) that addresses this. No value or a value of 0 gives the original output behavior, and a value of 1 results in timeseries output for all particles at all times. Unreleased and terminated particles are placed at their initial and final locations, respectively.

[jtwhite79]

Awesome! Thanks @aprovost-usgs !