RUC LSM precision workaround#163
Conversation
…sue during DEBUG=ON)
tanyasmirnova
left a comment
There was a problem hiding this comment.
@SamuelTrahanNOAA Sam, will be be more appropriate to put this workaround into lsm_ruc.F90? There is a sanity check on snow in there, and I guess it did not cover this situation when snow < 1.e-20
I looked for that before, but I couldn't find it. Can you tell me where the sanity checks reside? Also, can you please put your comment on the community PR as well? It will probably get more widespread review there. |
|
@SamuelTrahanNOAA Please, look for a comment "!> -- sanity checks on sneqv and snowh" in lsm_ruc.F90 |
I put it here, and I'm testing the change now with the gnu compiler: |
|
@SamuelTrahanNOAA Looks good. Thank you! |
|
@SamuelTrahanNOAA actually, we should add this workaround also to snow on ice. Please, look for another comment "sanity chack on sneqv' around line 1402. |
|
That means the fix is now: |
|
@SamuelTrahanNOAA This will do it, although ice variables are in the different section of lsm_ruc.F90 after the land part. |
I put this at the end of the sanity checks, in case the other sanity checks result in subnormal numbers. Edit: I've updated the comment in the code to explain that. |
…to "snow on ice" as well
The module_sf_ruclsm has comparisons to zero, which break the code when numbers are very close to 0, such as 1e-322. This happens with the gfortran compiler when compled -DDEBUG=ON since the option to truncate subnormal numbers is turned off.
My fix is truncate subnormal numbers manually, for the two variables that cause trouble.
Another possible fix is to remove all comparisons to zero and all equality comparisons from the ruclsm. However, I don't know why the developer used that method of comparing, nor what the appropriate epsilons are for the comparisons. Ultimately, this would require changing many more lines of code than my approach.
This is a copy of the community PR, with a different destination (RRFS_dev)
ufs-community#6