Skip to content

Comments

Fix: prevent duplicate exports by popping matched time in is_it_time_…#1071

Closed
AdriaLlealS wants to merge 1 commit intofestim-dev:fenicsxfrom
AdriaLlealS:fenicsx
Closed

Fix: prevent duplicate exports by popping matched time in is_it_time_…#1071
AdriaLlealS wants to merge 1 commit intofestim-dev:fenicsxfrom
AdriaLlealS:fenicsx

Conversation

@AdriaLlealS
Copy link

Description

Summary

This PR updates is_it_time_to_export so that when a timestep matches a desired export time (within the np.isclose tolerances), the corresponding entry in times is popped. This prevents repeated exports for the same target time.

Related Issues

Motivation and Context

Previously, multiple consecutive timesteps inside the tolerance window could all return True, causing repeated exports for a single requested export time, especially at high simulation times where the relative tolerance (rtol) allows larger absolute differences. This change ensures a 1‑to‑1 mapping between requested and actual exports, provided the simulation reaches timesteps sufficiently close to the target times.

Type of Change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • ✨ New feature (non-breaking change which adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 🔨 Code refactoring (no functional changes, no API changes)
  • 📝 Documentation update
  • ✅ Test update (adding missing tests or correcting existing tests)
  • 🔧 Build/CI configuration change

Testing

  • All existing tests pass locally (pytest)
  • I have added new tests that prove my fix is effective or that my feature works

Code Quality Checklist

  • My code follows the code style of this project (Ruff formatted: ruff format .)
  • My code passes linting checks (ruff check .)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas

Documentation

  • [] I have updated the documentation accordingly (if applicable)
  • I have added docstrings to new functions/classes following the project conventions

Breaking Changes

Screenshots/Examples

Additional Notes

Even though duplicates are now removed, very large simulation times can still cause the matched timestep to be several seconds away from the desired export time. Exposing tolerances (e.g. reducing rtol) cannot fully solve this issue: tightening rtol only delays it and may prevent matching early in the simulation, while relying on a small atol may fail when the timestep becomes larger near an export event.

If precise export timings are required, one way to mitigate this limitation is to use a small atol and ensure that the desired export times are included in the solver’s milestones so that the simulation visits them closely enough.

…to_export

This updates `is_it_time_to_export` so that when a timestep matches a desired export time (within the `np.isclose` tolerances), the corresponding entry in `times` is popped.

Previously, multiple consecutive timesteps within the tolerance window could all trigger `True`, leading to repeated exports for the same target time, especially at high simulation times where the relative tolerance (rtol) allows larger absolute differences.

With this change:
- only the first matching timestep triggers an export
- the matched time is removed, preventing any subsequent exports for it

This ensures a 1-to-1 mapping between requested and actual exports, provided the simulation reaches timesteps sufficiently close to the target times.
for i, time in enumerate(times):
if np.isclose(time, current_time, atol=atol, rtol=rtol):
times.pop(i) # consume the time so it is not exported again
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be safer to make a copy of times elsewhere in order to avoid destroying user inputs?

@RemDelaporteMathurin
Copy link
Collaborator

Hi @AdriaLlealS thanks for this! Maybe it would be helpful to make an example reproducing the issue? That way we can check that this fix is working.

I think we should make a copy of the times list somewhere to avoid destroying user inputs (this is why the tests are currently failing).

@AdriaLlealS
Copy link
Author

Hi @AdriaLlealS thanks for this! Maybe it would be helpful to make an example reproducing the issue? That way we can check that this fix is working.

I think we should make a copy of the times list somewhere to avoid destroying user inputs (this is why the tests are currently failing).

Absolutely, I'll create a copy of 'times' to solve this. About the example, should I post it in the discourse group and then somehow link it here in the PR or how would you suggest doing it?

@RemDelaporteMathurin
Copy link
Collaborator

About the example, should I post it in the discourse group and then somehow link it here in the PR or how would you suggest doing it?

That's ok just post it here

@AdriaLlealS AdriaLlealS deleted the branch festim-dev:fenicsx February 23, 2026 14:17
@AdriaLlealS AdriaLlealS deleted the fenicsx branch February 23, 2026 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants