PRT package creates incomplete tracking times in output .csv

[mrojasc8]

Hello MODFLOW Community,
I hope this message finds you well. I’ve been working with the Particle Tracking (PRT) package in MODFLOW 6 and have encountered what appears to be a potential bug related to the output of user-specified tracking times in the CSV file.

Issue Description:
When running a simulation with the PRT package, I specified a list of custom tracking times using the tracktimes input option. While the simulation runs successfully, the output CSV file (prt.csv) does not include all the user-specified tracking times. Specifically, only a subset of the requested times is written to the file, and some expected times are missing. I am using the dry_tracking_method='stay' option and releasing particles in a layer that is initially dry.
This behavior seems inconsistent with the expected functionality, as the tracking times should be recorded regardless of the initial dryness of the layer. To reproduce this bug, I am using the test case provided in issue #2014.

To reproduce:
• In the attached notebook,
ex-prt-tr.zip

Observed Behavior:
• The output CSV file contains only a subset of the user-specified tracking times, e.g., for particle ‘irpt=1’ the csv only records tracking times starting from from t = 118.0, omitting earlier specified times (0.0, 0.5, 1.0, …, 117.5).

Expected Behavior:
• The output CSV file should include all user-specified tracking times as defined in the tracktimes input, even if the cell is dry.

Additional Information:
• MODFLOW 6 version 6.6.0
• Flopy Version: 3.9.1
• Operating system: Windows 11

Thank you for your time and effort in maintaining this powerful tool. I look forward to your feedback!

Best regards,

M. Rojas

[wpbonelli]

Thanks for reporting this @mrojasc8.

The output CSV file should include all user-specified tracking times as defined in the tracktimes input, even if the cell is dry.

If the particle is active (i.e. Newton is on) agreed. This is a bug.

[wpbonelli]

@mrojasc8 this (and a few other output recording conditions) should be fixed in the next nightly build.