Wrong time unit usage in PRP package

[tandreasr]

Hi,
I've got another issue regarding the time units used / expected inside PRP package input / output.
Some entries of the PRP file do ignore the setting made in TDIS.

For example with TDIS entry 'TIME_UNITS days'

The following PRP entries do still seem to use seconds instead:
'BEGIN RELEASETIMES' ... 'END RELEASETIMES'

And the results (CSV as well as binary) do output seconds as well for columns
'TRELEASE' & 'T'

The RELEASE_TIME_FREQUENCY however already uses days.

Best regards
Andreas

[wpbonelli]

Hi @tandreasr the PRT model ignores time units and doesn't try to do any conversions — curious what you are seeing to suggest otherwise?

For instance the code implementing RELEASE_TIME_FREQUENCY is just

times = arange( &
        start=DZERO, &
        stop=totalsimtime, &
        step=this%rtfreq)

where rtfreq is the frequency, totalsimtime is the sum of period lengths, assumed to be in whatever unit is specified in TDIS, if any, and arange works more or less like numpy. And release times, tracking times, everything for PRT is assumed to use those same units, if any.

[tandreasr]

Hi @wpbonelli

It might be the case that I misunderstood the concepts :-)

But when testing one of your testmodels delivered with Modflow6 (ex-gwe-prt) which has 'TIME_UNITS days' and a total simulation time of 1 day (STEADY-STATE),
I tried to specify different 'RELEASETIMES' and noticed, that even specifying 86401 (which would be above 1 day even if interpreted in seconds) did output the very same particle path as a 'RELEASETIMES' time of 0 (with the time shift of 86401).
But after 86400 seconds there shouldn't be any flows available form the GWF model...
Or do you proceed for such cases by indefinitely using the flows calculated for the last timestep?

Regards
Andreas

[wpbonelli]

Hi @tandreasr I see now. This is certainly a bug. Really I think we shouldn't allow releases outside the bounds of tdis, but currently there is no such check..

Or do you proceed for such cases by indefinitely using the flows calculated for the last timestep?

Yes, if the extend_tracking option is on (as in this example model). That's why the particles are tracked as usual, just with the time shift. If you turn that option off you'll see they terminate after some brief nonsensical (backwards..?) behavior.

Thanks for raising this.

[tandreasr]

Hi @wpbonelli,
you are welcome :-)
Another question concerning time units regarding the very same example model.
As you might see in the attached CSV,
when just specifying the FIRST option in the PERIOD block (without additional RELEASETIMES)
the resulting time unit in the CSV for TRELEASE & T is obviously seconds, but in my opinion should be the one specified in TDIS (days). What do you think?
Thanks you very much for your time and efforts!
Andreas

_csv_and_prp.zip

[wpbonelli]

Hi @tandreasr the time unit in the t and trelease columns is whatever is specified in tdis, in this case it is really days even though the values look large. PRT does no time unit conversions.

(from the example notebook)

[tandreasr]

Hi @wpbonelli,
thanks again for the clarification!
Andreas