Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not update computed/updated fields timestamps from AtmosphereProcess #2942

Open
bartgol opened this issue Aug 7, 2024 · 0 comments
Open

Comments

@bartgol
Copy link
Contributor

bartgol commented Aug 7, 2024

Right now, the base class AtmosphereProcess is updating the timestamp of ALL computed fields at the end of the run method. This "simplifies" a bit the downstream classes, in that it saves them from writing a piece of code that is relatively the same for all of them.

However, this prevents fine-grain code that depends on knowing when a field was last really updated. Two examples:

  • right now, the SC import class "imports" qv_2m and wind_speed_10m, even though no atm procs use them. We could maybe skip them. However, if 3months from now someone need them, they would get uninited values. Since atm proc sets the timestamp of these two fields to a valid one, there's no flag telling us they were never computed. If SC was instead in charge of updating the timestamp of qv_2m, then , if it doesn't import it (cause we don't need it), it could not update it, which would lead to qv_2m having an invalid timestamp (since nobody ever updates it), which would likely be detected.
  • We could foresee using diagnostics to compute derived quantities on a "per need" basis from inside atm procs. However, we would likely not want to recompute a diag that a previous atm proc already computed, unless 1+ of the diag inputs has changes since the last calculation. E.g., a diag that only depend on RAD, may not need to be recomputed if RAD is supercycled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant