Add coupled IAU RT test#1916
Conversation
|
The full RT passed except the missing baseline for the new test. The RT log is at: /scratch1/NCEPDEV/nems/Jun.Wang/nems/vlab/20230817/ufs-weather-model/tests/logs |
|
@jiandewang would you please check if the mom6 output from the IAU test at: /scratch1/NCEPDEV/stmp2/Jun.Wang/FV3_RT/rt_248142/cpld_control_gfsv17_iau_intel ? Thanks |
@junwang-noaa I had a quick look on ocean output, nothing strange |
|
@jiandewang @NeilBarton-NOAA - This PR is testing the IAU capability which includes wanting the averaging buckets to be zerod out at FHR=0 when we have FHROT=3. Can you confirm if the ocean/ice models are correctly doing this zero-ing out or if this remain open issues? |
@JessicaMeixner-NOAA I am not quite understanding what you want me to check. All I see is there are two ocean outout files: |
what is "wanting the averaging buckets to be zerod out at FHR=0 when we have FHROT=3." ? |
I guess this test is on FV3 side it is doing this kind of IAU but not on ocean side, @junwang-noaa can you confirm on this ? |
|
@junwang-noaa For CICE, my initial read is that this is doing what you want for the CICE history files. In your run, in I will do a test and see if the fields in the history files appear to be 3 and 6 hour averages as expected. |
|
That's great news @DeniseWorthen @jiandewang we're basically expecting to see what @DeniseWorthen mentioned. FHROT means that we change when we start the forecast relative to the forecast hour 0. We can hop on a quick call tomorrow tand I can try to explain more if needed. |
now I know what's your purpose. But for ocean all I see is 12z and 18z output. I think diag_table doesn't have this capability but ice has a way to control that. |
|
@DeniseWorthen Thanks for confirmation. I think ice is OK. We do not expect users to use any averaged fields in the first ice output iceh_06h.2021-03-22-43200.nc, which is corresponding to atm f00 at 12z cycle. The next history file iceh_06h.2021-03-22-64800.nc has correct 6 hour average. |
|
@jiandewang if I understand correct, the ocn files should also doing the same thing as ice does. But please check the SST file: /scratch1/NCEPDEV/stmp2/Jun.Wang/FV3_RT/rt_248142/cpld_control_gfsv17_iau_intel/SST_2021_03_23.nc which is a daily mean. I assume we will not output it in marine DA (@guillaumevernieres) step, but will be output in GFSv17 forecast and this daily mean starts from the initial forecast time (start time), which is 6 hourly before the current cycle. E.g. in this case, the SST mean is from 2023062206- 2023062318, while this is a 12Z cycle run and we need it to be 2023062212-2023022306. |
|
@JessicaMeixner-NOAA would you please confirm the wave fields coming out correctly? Thanks |
|
The wave output is as requested which is instantaneous point and gridded files every 3 hours. |
|
@jiandewang @junwang-noaa The I can't remember how the 3-d files are named. Is the timestamp the end of the averaging period, so that |
|
@DeniseWorthen you are right, this setting only run 18hr so SST file has all missing value. For 6hr 3D the file name timestamp is using end of time. |
|
@jiandewang Thanks for the clarification. In that case, I am not confident that we're getting the expected values in the ocean file but I can't yet be entirely sure. What I did was write mediator history file 1-hour averages, averaged them over the intervals and compared that to what the model has for the same interval. For the ice model, I saw differences O~10-8 but I'm seeing differences more like O~10-1 w/ the MOM6 file for SST. |
|
@DeniseWorthen @jiandewang Thanks. I think the ocn file is in the mid-time. Please see ocn output from 24 hr forecast with a cold start: |
sorry my bad. ocn file is the middle time. In g-w Prototype and HR runs we rename them to ending time in the script. In rt.sh we don't do this renaming step. I mixed rt.sh and g-w. |
|
@jiandewang Ok, my brain isn't working today! What hours are used to create the ocn output that is labeled "18"? |
19z-24z |
zach1221
added
No Baseline Change
|
My first test run failed on Hera for the new test because of missing baselines. Do we need to change the directories in the cpld_control_run.IN file so it points to the new locations for the new input data in input-data-20221101? Currently still points to Jun's scratch directory. |
|
@zach1221 Yes, assuming the file has been added to the inputdata on all platforms, @junwang-noaa needs to make that update in |
Yes, the new input data has been distributed across the platforms. Except for wcoss2 I guess. |
Increment files were rsynced ok acorss all RDHPCS. |
|
@zach1221 Jun asked me to update the directory in the PR. Can you please try to generate a baseline for the new test now? Hopefully I got it right, but I did not test first. |
Ok, thanks. I wasn't certain what it should be, so was testing a change on my end. I'll try yours and let you know how it goes. |
|
@junwang-noaa we're now finished with testing. If you're able to close the two unresolved conversations, then we can begin the merging process. |
|
Done |
|
@junwang-noaa I meant to ask---I know at some point you were testing an updated FMS in relation to this PR? Is an updated FMS required to have the IAU working properly for MOM6 output? |
|
That's right. I am waiting for an FMS release so that we can get correct MOM6 output in IAU configuration. It may take some time, I am still checking the timeline of the FMS release |
10 participants
PR Author Checklist:
Description
A coupled IAU RT test cpld_control_gfsv17_iau is created for GFSV17 testing.
Linked Issues and Pull Requests
Associated UFSWM Issue to close
Subcomponent Pull Requests
None
Blocking Dependencies
None
Subcomponents involved:
Anticipated Changes
Input data
Regression Tests:
Tests effected by changes in this PR:
Libraries
Code Managers Log
Testing Log: