add frac grid input, update and add additional cpld tests

[DeniseWorthen]

Description

• Updates FV3_input_frac to add both benchmark dates and L127 files

• adds additional tests and restart tests. These are:
  c96mx100 12h/12h/24h restart (frac grid T)
  c192mx050 12h/36h/48h restart test (frac grid T/F); the previous restart c192mx050 test is replaced
  c384mx025 12h/12h/24h restart test (frac grid T/F)
  c384mx025 benchmark 12h/12h/24h restart test (frac grid T)
  c384mx025 benchmark_v16 6h/6h/12h restart test (frac grid T, L127)
  c384mx025 benchmark_v16 with waves (frac grid T, L127); no restart test because of waves
  c96mx100 debug test (frac grid T)

• Within these tests, frac_grid_input=T (default) is now used for all tests. This is a change to the control_c384 test, which was still using frac_grid_input=F.

• Removes all instances where MOM6 was using USE_LA_LI2016=True(set using the variable MOM6_REPRO_LA) for regression testing. Using the setting of True prevents restart reproducibility. This is a long-standing issue where the grid decomposition appears in the MOM6 fields after restart if this parameter is set true. It was not resolved when we switched to vertex_shear=F in the update to MOM6 (PR Feature/update mom6 and retain b4b results for 025x025 resolution #290). This setting has only been retained for bmark+wave configurations.

• Removes duplicate entries in the MOM_input_template_100 which produced error messages at run time (no-impact).

Issue(s) addressed

Issue #316
Issue #293
Issue #285
Issue #315 (suite file is added for compile of all cpld tests; model fails past 24hrs).

Dependencies

Requires sync'ing of new input-data-20210107 to all tested platforms. This is identical to the input-data-20201220 directory except that the directory FV3_input_frac has been replaced with the contents of this directory:

/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20201218_frac/FV3_input_frac

co-author: @shansun6

[DeniseWorthen]

Well, no one asked but I think we could drop the control and restart for the non-frac c192,c384. I have no problem w/ that.

I'd be close to saying that we could drop the frac grid cpld_bmark tests too since we're testing that in the v16 configuration (at L127).

[junwang-noaa]

In general the RT tests are targeting for operational models, the number of RT tests may increase during certain period of development. In the coupled model's case, different resolution tests are using different physics schemes and targeting for different applications(s2s, GEFS, GFS), it is different from standalone FV3 case, where we use the same physics configuration for difference resolution tests. I do think we need to clean up those old tests rather than limiting adding new feature tests that may come into next implementations

…

On Tue, Jan 5, 2021 at 1:58 PM Dom Heinzeller ***@***.***> wrote: Somewhat following this discussion. I agree that this is a proliferation of tests that we probably shouldn't do. hera and orion regression testing takes quite long already these days, despite all our efforts to run compile jobs and tests in parallel. We'll be back to 24h parallel regression testing soon ... In any case, given that Dusan approved it, is this ready for creating new baselines on all the platforms? What will the new date tag be (RTPWD)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TJH3LWYRAUCWMZOIHLSYNOOFANCNFSM4VTMVISA> .

[DusanJovic-NOAA]

Not related to this PR, but I think there is a typo in cpld_control_run.IN:

$ diff cpld_bmark_run.IN cpld_control_run.IN

23c17
<   cp  @[INPUTDATA_ROOT]/${FV3_DIR}/ozprdlos_2015_new_sbuvO3_tclm15_nuchem.f77 ./global_o3prdlos.f77
---
>   cp  @[INPUTDATA_ROOT]/${FV3_DIR}/ozprdlos_2015_new_sbuv03_tclm15_nuchem.f77 ./global_o3prdlos.f77

[climbfuji]

@DeniseWorthen should I start creating new baselines?

[DeniseWorthen]

Thanks Dusan, let me fix that. It could have been a stray edit.

Dom--I'm going to start w/ the tests as is in the PR. We can always drop tests. If nothing else this establishes a point in time where we have demonstrated restart repro in multiple configs.

[climbfuji]

Thanks Dusan, let me fix that. It could have been a stray edit.

Dom--I'm going to start w/ the tests as is in the PR. We can always drop tests. If nothing else this establishes a point in time where we have demonstrated restart repro in multiple configs.

Ok, I'll go ahead on gaea, jet, cheyenne as discussed - after you fixed the typo that Dusan pointed out.

[AvichalMehra-NOAA]

👍

…

On Tue, Jan 5, 2021 at 2:34 PM Jun Wang ***@***.***> wrote: In general the RT tests are targeting for operational models, the number of RT tests may increase during certain period of development. In the coupled model's case, different resolution tests are using different physics schemes and targeting for different applications(s2s, GEFS, GFS), it is different from standalone FV3 case, where we use the same physics configuration for difference resolution tests. I do think we need to clean up those old tests rather than limiting adding new feature tests that may come into next implementations On Tue, Jan 5, 2021 at 1:58 PM Dom Heinzeller ***@***.***> wrote: > Somewhat following this discussion. I agree that this is a proliferation > of tests that we probably shouldn't do. hera and orion regression testing > takes quite long already these days, despite all our efforts to run compile > jobs and tests in parallel. We'll be back to 24h parallel regression > testing soon ... > > In any case, given that Dusan approved it, is this ready for creating new > baselines on all the platforms? What will the new date tag be (RTPWD)? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #354 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AI7D6TJH3LWYRAUCWMZOIHLSYNOOFANCNFSM4VTMVISA > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ6ZTFBT4UBXX33HB56RADLSYNSVNANCNFSM4VTMVISA> .

-- Dr. Avichal Mehra Chief, Dynamics and Coupled Modeling Group Modeling and Data Assimilation Branch NOAA/NWS/NCEP/EMC Ph. 301-683-3746 Fax: 301-683-3703 [email protected]

[climbfuji]

We may want to remove some of the tests again, once we have gained enough confidence that the new features have sufficient test coverage and so the same behavior (e.g. restart reproducibility) for different resolutions.

[ShanSunNOAA]

Hi Denise, I like the way you modified my test: better than I could have done. Thanks a lot. Yes, I approve. Shan

…

On Tue, Jan 5, 2021 at 9:37 AM Denise Worthen ***@***.***> wrote: @shansun6 <https://github.com/shansun6> I can't add you as a reviewer but please review. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALORMVVOWNA2XG32GVKJXJ3SYM53JANCNFSM4VTMVISA> .

[DeniseWorthen]

All logs are committed; I will wait for CI to finish and then merge. Thanks for the help, Dom.

[climbfuji]

All logs are committed; I will wait for CI to finish and then merge. Thanks for the help, Dom.

No problem at all. I will update my PRs once this gets merged. We then need to create new baselines (but we don't need new input data).