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

allows mix precision compilation #360

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JosephMouallem
Copy link
Contributor

Allows a mixed precision compilation of the dycore. FV3 can be compiled in 32bit and works with other components compiled in 64bit. This depends on:
NOAA-GFDL/SHiELD_physics#56
NOAA-GFDL/SHiELD_build#46

Inspired from #357

@JosephMouallem
Copy link
Contributor Author

Copy link
Contributor

@uramirez8707 uramirez8707 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Copy link
Contributor

@bensonr bensonr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

I just caution you to check the area of the Earth quantity output during dycore initialization to ensure it doesn't have errors with the OVERLOAD_R4 option and these code modifications.

@JosephMouallem
Copy link
Contributor Author

Thanks for the hint, I will keep that in mind, so far I haven't seen any output error. Please let me know if there is anything specific to keep an eye on.

@bensonr
Copy link
Contributor

bensonr commented Oct 2, 2024

If you are getting identical results from before and after the changes, then I'm sure it's all good. You can do a visual check by looking at the Earth area in the stdout and compare it to known values.

@lharris4
Copy link
Contributor

lharris4 commented Oct 3, 2024

@JosephMouallem you should also check the area of the earth in the stdout, especially for both lower- and higher-resolution grids. It has a comparison to the exact value that is very useful for this purpose.

@JosephMouallem
Copy link
Contributor Author

For low resolution 200km cases, the stdout values are exactly the same between the computed global areas (but still slightly different compared to the ideal global area)

I just tried XSHiELD and saw a small difference in the values between 32bit and 64bit:
32bit: GLOBAL AREA (mm): 0.51009649711388E+15 IDEAL GLOBAL AREA (mm): 0.51009649655132E+15
64bit: GLOBAL AREA (mm): 0.51009649711422E+15 IDEAL GLOBAL AREA (mm): 0.51009649655132E+15

We can assume this is an acceptable difference?

@lharris4
Copy link
Contributor

lharris4 commented Oct 4, 2024

@JosephMouallem This is a good result. For reference here is the area values for my original 32-bit X-SHiELD run:

GLOBAL AREA (m*m): 0.51009649711428E+15 IDEAL GLOBAL AREA (m*m): 0.51009649655132E+15

The difference with your 32 bit run is only at the 12th decimal point, and is smaller than the difference in the computed and true global area in the 64-bit run (9th decimal point).

The small differences come in from rounding errors in the computation of the angles between grid lengths. Since in FV3 grid cells are bounded by great circles/geodesics, if we know the interior angles and the radius, we can compute the area of the cell exactly. This differs from many dynamical cores that assume grid cells are flat plates, which introduces significant error in computing areas.

More fun with differential geometry: Wikipedia: Spherical excess and Geodesic polygon

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

Successfully merging this pull request may close these issues.

5 participants