-
Notifications
You must be signed in to change notification settings - Fork 9
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
Building the fortran model with call_py_fort in debug mode leads to crashes #365
Comments
The particular flag that leads to errors is |
spencerkclark
added a commit
that referenced
this issue
Sep 7, 2023
This PR refactors the build infrastructure in this repo to eliminate the need for the Docker component. All development and testing is now done in the `nix` shell. This should be a quality of life improvement for anyone developing the fortran model, as it no longer requires maintaining checksums in two separate build environments. In so doing it introduces the following changes: - New `make` rules are provided for compiling the model in different modes: - `build` -- build executables in `repro` (our production mode) and `debug` mode. - `build_repro` -- build only the `repro` mode executable. - `build_debug` -- build only the `debug` mode executable. - Tests are run with each of the executables available in the local `bin` directory, and are tagged with the associated compile mode. - An option, `check_layout_invariance`, is provided to trigger regression tests be run with a 1x2 domain decomposition instead of a 1x1 domain decomposition to check invariance to the domain decomposition layout; this is used for the all the coarse-graining regression tests and replaces the previous `test_run_reproduces_across_layouts` test that would run in the docker image. - `debug`-mode and `repro`-mode simulations produce different answers, which is something we noticed in #364 when upgrading compiler versions as well, and so require different reference checksums. In working on this PR, we ran the fortran model in `debug` mode in more contexts than we had previously, some of which turned up errors, which we currently work around by using `pytest.skip` (something we had implicitly already been doing before): - #365 - #381 Working on this PR also brought my attention to the fact that `pytest`'s `tmpdir` fixture does not automatically get cleaned up after each test; `pytest` versions older than 7.3.0 keep around directories from the last three runs of `pytest`, which fill up disk space quickly since running these tests requires creating 10's of run directories, each with their own initial conditions and input files (#380). For the time being I manually clean up these run directories after successful tests. Resolves #340.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was exploring the possibility of addressing #340 (now that we are removing the serialize tests in #364 we might as well explore eliminating testing in docker entirely). This requires running tests in debug mode in the nix environment. In doing so I came across the fact that the basic native regression tests crash due to call_py_fort-related code:
fv3gfs-fortran/FV3/atmos_model.F90
Line 463 in cb106f2
A workaround would be to build the model without call_py_fort in debug mode to exercise this functionality, but ideally these tests would not crash in debug mode even when the model is built with call_py_fort active.
A basic way to reproduce this is to copy the
configure.fv3.nix
file into a new file withinFV3/conf
, setDEBUG=Y
andREPRO=
within it, configure/build the model, and run the tests:The traceback for one of the failing tests can be found below:
The text was updated successfully, but these errors were encountered: