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

Some wrapper unit tests require that no time-averaged physics diagnostics be output #384

Open
spencerkclark opened this issue Oct 10, 2023 · 0 comments

Comments

@spencerkclark
Copy link
Member

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:

import os

import fv3config
import fv3gfs.wrapper


rundir = "rundir"
with open("default_config.yml", "r") as file:
    config = fv3config.load(file)
fv3config.write_run_directory(config, rundir)

os.chdir(rundir)
fv3gfs.wrapper.initialize()

checkpoint_state = fv3gfs.wrapper.get_state(fv3gfs.wrapper.get_restart_names())
fv3gfs.wrapper.step()
fv3gfs.wrapper.set_state(checkpoint_state)
fv3gfs.wrapper.step()

checkpoint_state = fv3gfs.wrapper.get_state(fv3gfs.wrapper.get_restart_names())
fv3gfs.wrapper.step()
fv3gfs.wrapper.set_state(checkpoint_state)
fv3gfs.wrapper.step()

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.

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

No branches or pull requests

1 participant