-
Notifications
You must be signed in to change notification settings - Fork 7
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
UFS-dev PR#92 #108
UFS-dev PR#92 #108
Conversation
…ng PR#1863) (ufs-community#1844) * Changes to logging and initialization of the CLM Lake Model. * merge ccpp-physics NCAR#91 (UFS-SRW v3.0.0 SciDoc updates) 1. Use ice thickness hice(i) to find the level in the lake where ice is zero. 2. Do not allow lake temperature to be below freezing point if there is no ice. 3. If there is no snow or ice, do not allow surface lake temperature to be below freezing point. These changes fixed the problem with large errors in the energy budget at the beginning of the cold-start run with lakes. 4. Added flag to turn on debug print statements in the CLM lake model. * explicitly turn of frac_ice for flake * t_grnd(i) should be t_grnd(c) ------------------------------------------------------------------- Co-authored-by: Samuel Trahan <samuel.trahan@noaa.gov> Co-authored-by: Grant Firl <grant.firl@noaa.gov>
Expected BL changes: COMPILE | atm_debug_dyn32 | intel | -DAPP=ATM -DDEBUG=ON -D32BIT=ON -DCCPP_SUITES=FV3_HRRR,FV3_GFS_v16,FV3_GFS_v16_csawmg,FV3_GFS_v16_ras,FV3_GFS_v17_p8,FV3_GFS_v15_thompson_mynn_lam3km,FV3_RAP,FV3_RAP_unified_ugwp,FV3_RAP_cires_ugwp,FV3_RAP_flake,FV3_RAP_clm_lake,FV3_RAP_noah,FV3_RAP_sfcdiff,FV3_RAP_noah_sfcdiff_cires_ugwp,FV3_RRFS_v1beta | | fv3 | COMPILE | rrfs_dyn32_phy32 | intel | -DAPP=ATM -DCCPP_SUITES=FV3_RAP,FV3_HRRR -D32BIT=ON -DCCPP_32BIT=ON | | fv3 | COMPILE | rrfs_dyn32_phy32_debug | intel | -DAPP=ATM -DCCPP_SUITES=FV3_RAP,FV3_HRRR -D32BIT=ON -DCCPP_32BIT=ON -DDEBUG=ON | | fv3 | COMPILE | rrfs | gnu | -DAPP=ATM -DCCPP_SUITES=FV3_RAP,FV3_RAP_sfcdiff,FV3_HRRR,FV3_RRFS_v1beta -D32BIT=ON | + hera cheyenne | fv3 | COMPILE | atm_dyn32_debug | gnu | -DAPP=ATM -D32BIT=ON -DDEBUG=ON | + hera cheyenne | fv3 | COMPILE | rrfs_dyn32_phy32 | gnu | -DAPP=ATM -DCCPP_SUITES=FV3_RAP,FV3_HRRR -D32BIT=ON -DCCPP_32BIT=ON | + hera cheyenne | fv3 | COMPILE | atm_dyn32_phy32_debug | gnu | -DAPP=ATM -D32BIT=ON -DCCPP_32BIT=ON -DDEBUG=ON | + hera cheyenne | fv3 | |
@grantfirl Can you remove the old tests under |
I removed everything in the directory, but I don't have permissions to
delete the directory itself. That's weird.
…On Thu, Jan 11, 2024 at 12:19 PM Michael Kavulich ***@***.***> wrote:
@grantfirl <https://github.com/grantfirl> Can you remove the old tests
under
/scratch1/BMC/gmtb/CCPP_regression_testing/NCAR_ufs-weather-model/run_gjf
when you get a chance? I just want to make sure we don't run into disk
space issues while flying through these tests.
—
Reply to this email directly, view it on GitHub
<#108 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGCO5UF3RNSLS6ZIJ4AEE7DYOANIRAVCNFSM6AAAAAA63OCOK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXGYYTIMJZGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@mkavulich This one is ready to start testing to verify failed tests. |
@mkavulich Don't we need to do hera-intel-RT first to verify failed tests? |
Automated RT Failure Notification |
@mkavulich It looks like the baselines were created successfully, and we can use those, but we still need to run RTs against the old baseline. |
Yeah @grantfirl sorry about that, I figured it didn't matter the order in which we did this so long as there were no unexpected failures. I'm still trying to remember/discover the exact process that's happening in the "new baseline" tests...my initial thoughts would be that it creates a new baseline and runs again against to compare against that same baseline, does that sound correct? It's not actually clear from the logs that that's what's happening, but I haven't had a chance to delve deeply in there yet (they are exceedingly hard to parse) |
I'm also not sure why the BL tests are showing a failure. It seems to be some check that is running within the auto-RT on the repository side (rather than the copy staged on disk) that I don't understand. I will keep investigating. |
I guess that the order of RT/BL isn't too important as long as there aren't any unexpected failures in RT, which is why it has typically gone first. You don't want to create new baselines until you are sure that the code is performing as expected. I also found the scripts super confusing and Dustin and I had a similar discussion about whether RTs are run to check against new baselines (basically just testing reproducibility). I think that we came to the conclusion that it was doing another RT after the baseline was recreated, but I don't think that we were ever 100% certain of this. Since the UFS/EMC/EPIC code managers are ok with only the RT/BL tags, we were assuming that this was good enough for us too. |
Automated RT Failure Notification |
@grantfirl It looks like the |
rap_clm_lake_debug failures are expected. It is listed. This is ready to merge when you approve NCAR/ccpp-physics#1034, NCAR/fv3atm#104, and this one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@grantfirl Sorry, forgot to approve this one 😬
How did you want to go about updating the test logs and baseline location? I could go ahead and do it once tests are successful since I think I have write permissions on your fork, but I don't want to commit things to your branch if you're working on it.
I can do that. I'll go ahead and start the merge process so that we can move on to the next one. |
@mkavulich I still can't mv the new baselines into the baselines directory on Hera due to lack of permissions. I've done the rest. If you could mv the new baselines and give it a name of main-20240116, we'll be ready to continue with the next one once I update the branches. |
Identical to ufs-community#1844
Contains changes from #107 until it is merged.