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

Consider how to enable wrapping a fortran model compiled in mixed 32-bit / 64-bit mode #2

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

Comments

@spencerkclark
Copy link
Member

Up to this point when wrapping FV3GFS, we have always compiled the model with 64-bit precision for both the physics and dynamical core. While it can be compiled and run with full 64-bit precision (as is done in #1), for efficiency SHiELD is generally compiled and run in "mixed mode," meaning that the dynamical core uses 32-bit precision values and the physics uses 64-bit values. @lharris4 would like to see this eventually; quoting from NOAA-GFDL/SHiELD_build#27 (comment):

Note that we will probably eventually need to support 32-bit/mixed-mode arithmetic if we wish for greater uptake of the SHiELD wrapper, since we typically run SHiELD with 32-bit dynamics for efficiency purposes.

The Python wrapper currently implicitly assumes that numbers are in 64-bit precision when building the template fortran and Cython modules for getters and setters (see the data types specified in places like here or here). At a minimum this is something that would need to be relaxed / configurable to support wrapping a mixed-mode model. There could be other details I am not considering as well, but this issue is meant to track notes / discussion about this feature.

@spencerkclark spencerkclark changed the title Consider how to enable wrapping a fortran model compiled in mixed 32bit/64bit mode Consider how to enable wrapping a fortran model compiled in mixed 32-bit / 64-bit mode Oct 2, 2023
spencerkclark added a commit that referenced this issue Oct 19, 2023
# This is the 1st commit message:

Add updates required for overriding radiative fluxes

# The commit message #2 will be skipped:

# Uncomment and update diagnostic-based test
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