You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following run file illustrates a pattern that we use in the test_overrides_fo_surface_radiative_fluxes.py and test_set_ocean_surface_temperature.py sets of test cases:
In theory, at the end of this process, the model should have the state equivalent to taking two steps (even though four steps have been taken). As it turns out, I think somewhat by accident, the configuration file that we load in the tests happens to not output any physics diagnostics, due to the lack of setting an appropriate fhout value. If we change this, as we have by accident in work on the Python wrapper of SHiELD, and output physics diagnostics (specifically time-averaged fields), the model tries to write out NaN values, leading the tests to crash for a reason unrelated to what we are testing.
As far as I can tell, the NaN values are a result of the physics diagnostics code thinking at some point during the time loop (which has been awkwardly traversed in the running of these tests) that the integration duration for a diagnostics interval was zero seconds, leading to a division by zero when computing the interval means. Whether we care to fix this or not is an open question (is it even feasible to keep track of accumulated diagnostics when we are running and re-running steps?), but I am mainly opening this issue to document this side effect of how the tests were written, and that it may motivate writing them in a slightly different way in the SHiELD wrapper.
The text was updated successfully, but these errors were encountered:
The following run file illustrates a pattern that we use in the
test_overrides_fo_surface_radiative_fluxes.py
andtest_set_ocean_surface_temperature.py
sets of test cases:In theory, at the end of this process, the model should have the state equivalent to taking two steps (even though four steps have been taken). As it turns out, I think somewhat by accident, the configuration file that we load in the tests happens to not output any physics diagnostics, due to the lack of setting an appropriate
fhout
value. If we change this, as we have by accident in work on the Python wrapper of SHiELD, and output physics diagnostics (specifically time-averaged fields), the model tries to write out NaN values, leading the tests to crash for a reason unrelated to what we are testing.As far as I can tell, the NaN values are a result of the physics diagnostics code thinking at some point during the time loop (which has been awkwardly traversed in the running of these tests) that the integration duration for a diagnostics interval was zero seconds, leading to a division by zero when computing the interval means. Whether we care to fix this or not is an open question (is it even feasible to keep track of accumulated diagnostics when we are running and re-running steps?), but I am mainly opening this issue to document this side effect of how the tests were written, and that it may motivate writing them in a slightly different way in the SHiELD wrapper.
The text was updated successfully, but these errors were encountered: