output time incorrect

[reint-fischer]

Parcels version

v4-dev

Description

When I initialise a ParticleSet at the start of the FieldSet.time_interval, with a ParticleSet.dt of 5 minutes and an outputdt of 10 minutes, and a runtime of 30 minutes (dtype=np.timedelta64), the simulation is run for 25 minutes and the output is written at 5, 15, and 25 minutes from the start of the simulation. I would expect it to run for 30 minutes, with output written at 0, 10, 20, and 30 minutes.

I believe part of the issue is in the time loop of particleset.execute(), in line 565:

output_file.write(self, next_output)

In v3.1.4 the equivalent is:

output_file.write(self, time_at_startofloop)

As I understand it this means that outputs are no longer written for the initial timestep. I have not familiarized myself enough with the full new time loop to say whether changing next_output would completely solve this issue. This would also not resolve the runtime being 25 instead of 30 minutes I assume.

Code sample

# Particle locations and initial time
npart = 10  # number of particles to be released
lon = 32 * np.ones(npart)
lat = np.linspace(-32.5, -30.5, npart, dtype=np.float32)
time = np.repeat(
    ds.time.values[0], npart
)  # release all particles at the start time of the fieldset
depth = np.repeat(ds.depth.values[0], npart)

pset = parcels.ParticleSet(
    fieldset=fieldset, pclass=SampleParticle, lon=lon, lat=lat, time=time, depth=depth
)

output_file = parcels.ParticleFile("SampleTemp.zarr", outputdt=np.timedelta64(10,'m'))

pset.execute(
    [parcels.kernels.AdvectionRK4],
    runtime=np.timedelta64(30,'m'),
    dt=np.timedelta64(5,'m'),
    output_file=output_file,
)

Particle_data = xr.open_zarr("SampleTemp.zarr", decode_times=False)

Particle_data.time[0,:].values

array([ 300,  900, 1500], dtype=uint64)

[erikvansebille]

Thanks for reporting this issue, @reint-fischer. Note that the current implementation of the ParticleFile is not very robust and the test coverage is very low; we quickly put it in so that we could show some trajectories with v4, but haven't fully tested it.

@VeckoTheGecko is planning a major refactor of the ParticleFile, but that's probably a few weeks/months away

In the meantime, I will quickly check if this is an issue in the Kernelloop or the ParticleFile. If the former, perhaps we can fix it already. if the issue is deep inside the ParticleFile code, I propose we wait until the refactoring

@reint-fischer, perhaps you can start with creating a branch/PR with the minimal example above as a unit test, so we can at least keep updated on it's failing status?