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
Issue with MSKF when used with aercu_opt = 1 or 2 #1873
Assignees
Comments
|
@sael9740 I will take a look next week. Thanks for finding this. |
|
@sael9740 I tend to agree with you on your proposed fix to initialize qsatu in the loop you identified. Did you look at the model output with and without this fix to see if there is much impact? |
Is setting it to zero the correct thing to do? Or should it be initialized some other way here?
Assuming that we initialize qsat to zero it looks like it does have a significant impact in some cases. FYI - I typically do a three-way comparison of:
This allows me to understand how much of an impact the changes have relative to the differences that occur due to simple floating-point error propagation, which for our purposes with GPU-WRF are extremely important but I'm explaining this here so that you can understand the plot I'm attaching:
The top row plots the fields for each run and the bottom row plots the differences between each pair. I'm seeing that the differences due to the code modification (bottom center plot) are notably larger than the differences between the |
|
@sael9740 I contacted the code contributor, and he suggested to initialize qsatu after line 4365 in v4.5 as Can you see if this works for bit-for-bit results? I think it should. Thanks! |
|
@weiwangncar - I just checked and it looks like adding
This does produce different results than what we initially proposed for initializing Lines 4424 to 5369 in 21c7214
and the starting index K for the updraft loopLines 4741 to 5026 in 21c7214
can be different for different iterations of the usl loop. Therefore by initializing QSATu prior to the ust loop the assignments inLines 5035 to 5067 in 21c7214
may be using some QSATu values that were initialized in a previous iteration of the usl loop.
My question now though is that if this is the contributor's intention for Lines 4717 to 4739 in 21c7214
|
|
@sael9740 The idea here is that the author may want to do further development of the scheme using qsatu without aerosol, and the use of qsatu may go outside the cloud layer (as you've found out). The variables aqnewlq and aqnewic are strictly in-cloud variables. |
|
@weiwangncar - That makes sense. Thanks for the explanation! Should I create a pull request? |
|
@sael9740 Yes, please! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
3 participants
While working with the MSKF/Morrison AA combo, I noticed that identical runs (same build, same arch, same number of MPI ranks, etc.) were not producing bit for bit results like I typically expect. This seemed to be the case for
aercu_opt = 1andaercu_opt = 2but not foraercu_opt = 0. When digging deeper I noticed thatQSATuis never initialized at the lower levels even though it is used later on in calculations for other variables:QSATu initialization
QSATu used to calculate su, QSATZM and gamhat
I am thinking that we need to add a
QSATu(KQ) = ??in the following loop to ensure it is initialized at the lower levels belowNK=K:WRF/phys/module_cu_mskf.F
Lines 4717 to 4739 in 21c7214
I confirmed that adding a
QSATu(KQ) = 0.0here produces B4B results between runs but I'm wondering if the NCAR physics folks can help with what exactly this should be initialized to at the lower levels?Steps to reproduce the behavior:
@weiwangncar , @dudhia
The text was updated successfully, but these errors were encountered: