When the option delete_outside_domain is enabled, Fluidity attempts to write particles after deleting their detectors, leading to write errors. In the (contrived) case of a particle subgroup with zero remaining particles after deletion, this can also crash the simulation, causing runaway memory usage. The relevant sections of the code are:
It seems like there are two parts to a potential solution: flag when detectors have been deleted and propagate this information to particles to stop the output, and add a final write before deleting the detectors. Alternatively, a simpler way would be to add a catch to prevent writing anything in the zero particles case, I'm not quite sure if that would be enough.
Hopefully the following options tree and mesh will reproduce the issue:
zero_particles.tar.gz
The example options tree contains two particle subgroups, one with initialise_during_simulation set, which acts as a workaround for the issue. I get a fluidity.err-0 that contains:
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#49/x' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#49/y' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#49/z' failed.
[proc 0] E: h5pt_writedata_i4_: Write to dataset '/Step#49/id' failed.
[proc 0] E: h5pt_writedata_i4_: Write to dataset '/Step#49/proc_id' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#49/test1' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#50/x' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#50/y' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#50/z' failed.
[proc 0] E: h5pt_writedata_i4_: Write to dataset '/Step#50/id' failed.
[proc 0] E: h5pt_writedata_i4_: Write to dataset '/Step#50/proc_id' failed.
[proc 0] E: h5pt_writedata_r8_: Write to dataset '/Step#50/test1' failed.
The log shows that for the last two timesteps, the first subgroup has 0 local and 0 global detectors after moving.
When the option
delete_outside_domainis enabled, Fluidity attempts to write particles after deleting their detectors, leading to write errors. In the (contrived) case of a particle subgroup with zero remaining particles after deletion, this can also crash the simulation, causing runaway memory usage. The relevant sections of the code are:It seems like there are two parts to a potential solution: flag when detectors have been deleted and propagate this information to particles to stop the output, and add a final write before deleting the detectors. Alternatively, a simpler way would be to add a catch to prevent writing anything in the zero particles case, I'm not quite sure if that would be enough.
Hopefully the following options tree and mesh will reproduce the issue: zero_particles.tar.gz
The example options tree contains two particle subgroups, one with
initialise_during_simulationset, which acts as a workaround for the issue. I get afluidity.err-0that contains:The log shows that for the last two timesteps, the first subgroup has
0 local and 0 global detectorsafter moving.