-
Notifications
You must be signed in to change notification settings - Fork 18
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
Bug fixes to 3D diagnostic tendencies; add more tendencies #12
Bug fixes to 3D diagnostic tendencies; add more tendencies #12
Conversation
… and physics/moninedmf.f
…s, implement model/ccpp/total tendencies.
…YTHING" flag, YES by default, which deletes everything at the end of the script.
…dded model and cppp tendency variables
…model tendencies add up to total change in 3 hours for the gfs v16 beta suite
… tendencies for gvsv15p2
…ion test log for hera.
@llpcarson @grantfirl - for your information, the latest version of the 3D tendencies PR for NOAA-GSD/ufs-weather-model. No need to review this one, just wanted to give you a complete set of PRs. |
Sam - could you add a link to the fv3atm (and confirm no ccpp-framework changes) PRs here? Much easier to find everything that way, thanks. Also, I think the changes to rt.sh are not intended to be merged into the authoritative repo? (local changes only?) Could you recheck those? Overall, this looks like a good implementation, with the caveats you noted. |
Done
The rt.sh changes should be in a separate PR. For now, I need them for debugging.
|
Bug fixes to 3D diagnostic tendencies (based on #12)
…(Jet build fix) (NOAA-GSL#12) * Move path from /lfs3 to /lfs4 for NCEP libraries * Update Externals.cfg for changes in UFS_UTILS and EMC_post, and checkout the NCAR fork of ufs-weather-model * Add CODEOWNERS file and PR template to the repo * Remove CODEOWNERS file from top level directory (now in .github directory like in regional_workflow) * Update Externals.cfg hashs for UFS_UTILS, ufs-weather-model, and EMC_post * Update build_forecast.sh for WCOSS The modulefile directories for WCOSS do not have Intel on the end for some reason, so this change is needed for the definition of the target variable. * Add CMAKE_Platform line in build_forecast.sh to correctly build on Jet * Fix for the duplicate ${target} variable in build_forecast.sh * Update hash for NCAR fork of ufs-weather-model to include fix for Jet build * Update hash for NCAR UFS_UTILS fork and for regional_workflow * Update regional_workflow and NCAR:UFS_UTILS/dtc/develop hashes * Updated NCAR fork dtc/develop hash Co-authored-by: BenjaminBlake-NOAA <52074832+BenjaminBlake-NOAA@users.noreply.github.com>
This is the ufs-weather-model pull request for:
Bug fixes are added so the 3D diagnostic tendency output works properly. There is a new
qdiag3d
flag to turn on 3D tracer tendencies. Also, there are now tendencies for the model, ccpp, and total. The later two are for debugging the tendency calculations. Thetimestep_init
andtimestep_final
stages of CCPP are implemented.Fully tested with gfs v16 beta test suite.
This is still a draft pull request because:
The Precision Problem
I can say definitively that double precision floating point is not enough to accumulate tendencies across the orders of magnitude typically found in the atmosphere. This was determined by adding a fourth tendency, now disabled in the code. Every time the ccpp or model tendencies were accumulated, that fourth tendency was accumulated by the same amount. In that case, the tendencies of: temperature had a precision of about 0.1 degrees, water vapor mixing ratio of 1e-5, and wind of .1 meters per second. Those are per-3-hour tendencies from a C768 global model. A higher-resolution run would have much larger imprecision due to the larger number of timesteps.
Those can be viewed as the best possible tendency errors.
Right now, the error in the tendencies of CCPP are about 2.5 times the best possible. It is hard to tell whether it is due to further precision issues (eight times as many additions per timestep) or incorrect tendency logic.
The precision issue could be dealt with using quadruple precision (128 bit) floating-point. That is a part of the Fortran 2008 standard, and it is an optional part of the MPI standard. It may be feasible to implement it, but that could cause portability issues.