Adding a regression test "cpld_bmark_wave_frac" #326
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pld_bmark_wave". A temporary data path is inserted in rt.sh, until the data is copied over to the default dir.
|
Why is the PR created? There's already #322 |
|
@shansun6 Just to be sure I understand what is what. In the directory /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac you:
|
|
Hi Denise,
You are right with both (1) and (2), except other subdirectories are
identical in terms of passing the fractional regression test (we have just
1 cpld_controlfrac_c384), with some cleanup. So I'd suggest taking the
whole dir
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac/
It is much bigger in size than the earlier one, as it contains 8 cases BM
IC at L64 as well as L127. Let me know if you have any questions.
Shan
…On Fri, Dec 11, 2020 at 6:04 AM Denise Worthen ***@***.***> wrote:
@shansun6 <https://github.com/shansun6> Just to be sure I understand what
is what.
In the directory
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac
you:
1.
added directories C96_l127.mx100_frac and BM_IC. All other
subdirectories are identical to current input-data-20201201 in the baseline
2.
In your FV3_input_frac/BM_IC, you've added frac grid ICs for the 8
dates we carry in the RT system.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#326 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVV34KA2YMV5ELZTD7LSUIKGJANCNFSM4UVWRQLA>
.
|
|
The directory contains BM_IC for L127 also? I don't see that--can you give me file path as an example? |
|
Here it is:
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac/BM_IC/2012010100/gfs/...
It made it easy to modify cpld_bmark_run.IN:
BM_IC=BM_IC/${SYEAR}${SMONTH}${SDAY}${SHOUR}
if [ ${FRAC_GRID_INPUT} = .F. ]; then
FV3_IC=${BM_IC}/gfs/@[ATMRES]/INPUT
elif [ @[NPZ] == 127 ]; then
FV3_IC=FV3_input_frac/${BM_IC}/gfs/@[ATMRES]_L@[NPZ]/INPUT
else
FV3_IC=FV3_input_frac/${BM_IC}/gfs/@[ATMRES]/INPUT
fi
unless you have a better way?
Thanks,
Shan
…On Fri, Dec 11, 2020 at 9:07 AM Denise Worthen ***@***.***> wrote:
The directory contains BM_IC for L127 also? I don't see that--can you give
me file path as an example?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#326 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVXYC3Y64LK2OIOZPTDSUI7UVANCNFSM4UVWRQLA>
.
|
|
No, that's fine. Stupid mistake on my end. |
|
Shan--should I expect that the input data in your staged directory (/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/) will pass the current coupled RTs for L64? |
|
Yes, my data will pass the current RT test for L64. There is only
one: cpld_controlfrac_c384. Let me confirm it now. Will send you the path
tonight.
Shan
…On Thu, Dec 17, 2020 at 4:43 PM Denise Worthen ***@***.***> wrote:
Shan--should I expect that the input data in your staged directory
(/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/) will
pass the current coupled RTs for L64?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#326 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVT55XX2YTQXUTY4UB3SVKJQ5ANCNFSM4UVWRQLA>
.
|
|
Hi Denise,
I have tested "cpld_controlfrac_c384" using today's version of
ufs-weather-model with the only change of
INPUTDATA_ROOT=/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/
the test has passed the regression test successfully, see details in
/scratch1/BMC/gsd-fv3-dev/sun/tst_frac_data/tests/log_hera.intel/rt_001_cpld_controlfrac_c384_prod.log
/scratch2/BMC/gsd-fv3-dev/Shan.Sun/FV3_RT/rt_256711/cpld_controlfrac_c384_prod/.
Let me know if you have any questions.
Shan
On Thu, Dec 17, 2020 at 4:55 PM Shan Sun - NOAA Federal <[email protected]>
wrote:
… Yes, my data will pass the current RT test for L64. There is only
one: cpld_controlfrac_c384. Let me confirm it now. Will send you the path
tonight.
Shan
On Thu, Dec 17, 2020 at 4:43 PM Denise Worthen ***@***.***>
wrote:
> Shan--should I expect that the input data in your staged directory
> (/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/) will
> pass the current coupled RTs for L64?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#326 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ALORMVT55XX2YTQXUTY4UB3SVKJQ5ANCNFSM4UVWRQLA>
> .
>
|
|
Hi Shan, I'm still trying to work through this. I just want to be sure I understand when something changes or doesn't change. In the current RTs and current input data, these tests use "frac_grid_input=F": all benchmark tests The remaining tests use "frac_grid_input=T". You have now generated the frac grid input for the benchmark dates, both L64 and L127. This allows us to update the tests to use frac_grid_input=T for all tests with frac_grid=T,F (we are replacing the c96mx025 restart test). The existing L64, frac_grid input at C96,C192 and C384 has changed. The change means that only the c384 frac_grid=T test reproduces the current baseline, as you say (I verified this also in my tests). The L64 frac_grid input for C96,192 (frac_grid=F) don't reproduce the current input in my tests at least. Can you remind me what the clean up was? |
|
Hi Denise,
Let me look at the difference in the case of frac_grid=F and get back to
you. I suspect that it is related to slmsk changes.
The clean up was to make slmsk in oro_data and sfc_data identical on warm
tiles, except on tiles 3 & 6 where slmsk can be 2 in sfc_data.
Between these 2 datasets,
(1)
/scratch1/NCEPDEV/nems/emc.nemspara/RT/NEMSfv3gfs/input-data-20201201/FV3_input_frac/C96.mx100_frac
where on tiles without ice, e.g., slmsk=floor(land_frac) in
oro_data.tile5.nc, which differs from slmsk=*nint*(land_frac) in
sfc_data.tile5.nc.
(2)
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac/C96.mx100_frac/
where both slmsk records are set to be slmsk=*floor*(land_frac).
I think slmsk in the oro_data is not used. It is slmsk in sfc_data that is
read in. From dataset (1) to (2), slmsk has changed from nint(land_frac)
to floor(land_frac). This only happens when frac_grid=F, since slmsk is
derived from land_frac in FV3GFS_io.F90 when frac_grid=T. I will confirm
the difference is only along edges.
Another way is to use slmsk=nint(land_frac) in both oro_data and sfc_data
in (2). We went back and forth from nint and floor, where each has its own
advantages: nint should be more accurate and floor has a smaller land
print. Again this only affects frac_grid=F. Any suggestions?
Shan
…On Fri, Dec 18, 2020 at 7:45 AM Denise Worthen ***@***.***> wrote:
Hi Shan, I'm still trying to work through this. I just want to be sure I
understand when something changes or doesn't change.
In the current RTs and current input data, these tests use
"frac_grid_input=F":
all benchmark tests
cpld_control_c384
c96mx025 (restart test)
The remaining tests use "frac_grid_input=T".
You have now generated the frac grid input for the benchmark dates, both
L64 and L127.
You have also generated the control date L127 frac grid input for
C96mx100, C192mx050. The C384mx025_L127 already existed.
This allows us to update the tests to use frac_grid_input=T for all tests
with frac_grid=T,F (we are replacing the c96mx025 restart test).
The existing L64, frac_grid input at C96,C192 and C384 has changed. The
change means that only the c384 frac_grid=T test reproduces the current
baseline, as you say (I verified this also in my tests).
The L64 frac_grid input for C96,192 (frac_grid=F) don't reproduce the
current input in my tests at least. Can you remind me what the clean up was?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#326 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVSR5WJFYJUEVFTOL5LSVNTHZANCNFSM4UVWRQLA>
.
|
|
Hi Denise,
After thinking about it, I would like to use slmsk=*nint*(land_frac) in
both oro_data and sfc_data. This is reflected in the newly created data dir
of
INPUTDATA_ROOT=/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201218_frac/FV3_input_frac
With the above data, the model output would be bitwise identical when
frac_grid_input=T for both frac_grid=F and frac_grid=T with those using the
default data of
INPUTDATA_ROOT=${INPUTDATA_ROOT:-$DISKNM/NEMSfv3gfs/input-data-20201201/}
Comparing the contents under /FV3_input_frac/ in the above two paths, the
first one has
(1) consistent definition of slmsk between oro_data and sfc_data, although
the earlier one is not used by FV3 at the moment;
(2) "inland" record in oro_data is removed as it is an intermediate
variable when creating lake_frac.
Thus I'd recommend using /FV3_input_frac/ from the blue path above when a
new INPUTDATA_ROOT dir is to be created next time.
Let me know if you have any questions. Thanks,
Shan
On Fri, Dec 18, 2020 at 10:22 AM Shan Sun - NOAA Federal <[email protected]>
wrote:
… Hi Denise,
Let me look at the difference in the case of frac_grid=F and get back to
you. I suspect that it is related to slmsk changes.
The clean up was to make slmsk in oro_data and sfc_data identical on warm
tiles, except on tiles 3 & 6 where slmsk can be 2 in sfc_data.
Between these 2 datasets,
(1)
/scratch1/NCEPDEV/nems/emc.nemspara/RT/NEMSfv3gfs/input-data-20201201/FV3_input_frac/C96.mx100_frac
where on tiles without ice, e.g., slmsk=floor(land_frac) in
oro_data.tile5.nc, which differs from slmsk=*nint*(land_frac) in
sfc_data.tile5.nc.
(2)
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac/C96.mx100_frac/
where both slmsk records are set to be slmsk=*floor*(land_frac).
I think slmsk in the oro_data is not used. It is slmsk in sfc_data that is
read in. From dataset (1) to (2), slmsk has changed from nint(land_frac)
to floor(land_frac). This only happens when frac_grid=F, since slmsk is
derived from land_frac in FV3GFS_io.F90 when frac_grid=T. I will confirm
the difference is only along edges.
Another way is to use slmsk=nint(land_frac) in both oro_data and sfc_data
in (2). We went back and forth from nint and floor, where each has its own
advantages: nint should be more accurate and floor has a smaller land
print. Again this only affects frac_grid=F. Any suggestions?
Shan
On Fri, Dec 18, 2020 at 7:45 AM Denise Worthen ***@***.***>
wrote:
> Hi Shan, I'm still trying to work through this. I just want to be sure I
> understand when something changes or doesn't change.
>
> In the current RTs and current input data, these tests use
> "frac_grid_input=F":
>
> all benchmark tests
> cpld_control_c384
> c96mx025 (restart test)
>
> The remaining tests use "frac_grid_input=T".
>
> You have now generated the frac grid input for the benchmark dates, both
> L64 and L127.
> You have also generated the control date L127 frac grid input for
> C96mx100, C192mx050. The C384mx025_L127 already existed.
>
> This allows us to update the tests to use frac_grid_input=T for all tests
> with frac_grid=T,F (we are replacing the c96mx025 restart test).
>
> The existing L64, frac_grid input at C96,C192 and C384 has changed. The
> change means that only the c384 frac_grid=T test reproduces the current
> baseline, as you say (I verified this also in my tests).
>
> The L64 frac_grid input for C96,192 (frac_grid=F) don't reproduce the
> current input in my tests at least. Can you remind me what the clean up was?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#326 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ALORMVSR5WJFYJUEVFTOL5LSVNTHZANCNFSM4UVWRQLA>
> .
>
|
|
Hi Shan, I've added your bmark wave frac grid test to my updateinput branch. It identical to what you had except I changed the name (from _frac at the end to bmarkfrac). It will be using a new input data directory (input-data-20210107). Can you point me to your gfsv16 test that runs for 24 hours? I will add that also. |
|
Hi Denise,
Thanks for doing this. My branch is here:
git clone -b test_v16_20201226 --recursive
https://github.com/shansun6/ufs-weather-model
The conf file is rt_bm.conf, which points to this 1day test of
"cpld_bmark_v16". Let me know if you have any questions.
Thanks for your help,
Shan
…On Mon, Jan 4, 2021 at 11:02 AM Denise Worthen ***@***.***> wrote:
Hi Shan,
I've added your bmark wave frac grid test to my updateinput branch
<https://github.com/DeniseWorthen/ufs-weather-model/tree/feature/updateinput>.
It identical to what you had except I changed the name (from _frac at the
end to bmarkfrac). It will be using a new input data directory
(input-data-20210107).
Can you point me to your gfsv16 test that runs for 24 hours? I will add
that also.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#326 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVSWXZP6DSMIPT2NMW3SYH7BNANCNFSM4UVWRQLA>
.
|
|
Closing; Test was committed in PR #354 |
pjpegion
pushed a commit
to NOAA-PSL/ufs-weather-model.p7b
that referenced
this pull request
Jul 20, 2021
* update ccpp physics to gcycle_fix_p7b branch * point ccpp/phyics to release/P7b branch Co-authored-by: Jun Wang <[email protected]>
epic-cicd-jenkins
pushed a commit
that referenced
this pull request
Apr 17, 2023
…heyenne, as well as fix workflow generation on Cheyenne (#378) ## DESCRIPTION OF CHANGES: A fix was applied to the release branch for the Cheyenne workflow and automated testing in #343, this PR applies the same to develop. ## TESTS CONDUCTED: Workflow built and ran on Cheyenne; the following tests were run and all passed: - grid_RRFS_CONUS_13km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v15p2 - grid_RRFS_CONUS_25km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v15p2 - grid_RRFS_CONUS_3km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v15p2 ## ISSUE (optional): Fully resolves #326
epic-cicd-jenkins
pushed a commit
that referenced
this pull request
Apr 17, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a benchmark regression test for C384L64, based on "cpld_bmark_wave", where rt.sh points to a temporary data dir /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201201_frac/FV3_input_frac/, until these data are copied to the default path.
This refers to Issue #285.