Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Revising oro data with full lakes only #388

Closed
ShanSunNOAA opened this issue Jan 21, 2021 · 43 comments · Fixed by #537
Closed

Revising oro data with full lakes only #388

ShanSunNOAA opened this issue Jan 21, 2021 · 43 comments · Fixed by #537
Assignees
@DeniseWorthen
Labels
enhancement New feature or request

Comments

@ShanSunNOAA
Copy link
Collaborator

We propose to ignore fractional lakes in the oro data until these small water bodies can be initialized realistically. This will change results in all tests that use oro data under "input-data-.../FV3_input_frac/".
@ShanSunNOAA ShanSunNOAA added the enhancement New feature or request label Jan 21, 2021
@rgrumbine
Copy link

What is needed for realistic initialization?

@ShanSunNOAA
Copy link
Collaborator Author

We need to have at least the surface temperature, ice temperature and ice coverage at those smaller lakes/rivers during the 7 year period (Apr 2011 - Mar 2018) that the Prototype 6 test is running, in order to initialize FV3 properly. Since these lakes/rivers don't exist in CFSR, the nearest neighbor method, while interpolating CFSR to FV3 grid, ended up assigning a water type value far away to these small lakes/rivers in FV3. No wonder these inappropriate initial conditions on lakes/rivers backfired.

Thanks, Bob!

@ShanSunNOAA
Copy link
Collaborator Author

A set of oro_data using a matching coastline with the ocean model and full lakes are available at
/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/. Its corresponding sfc_data and gfs_data for Oct 3 2016 are available in the same dir. These data can be used for both frac_grid=T or F.

@rgrumbine
Copy link

Inland water temperatures are available on a climatological basis from the NARR (Mesinger et al. 2006) used to force FLAKE (Yihua Wu et al. 201N) (iirc 4 km), and, daily, the RTG High Resolution SST analysis to 2020 (5 arcmin grid).

Ice/no ice mask is available from the IMS snow/ice analysis on a 4 km (or, at worst) 24 km polar stereographic grid.

Ice surface temperature could be initialized to local T2M as a first guess, with some inspection that it did not evolve too rapidly in the next day.

@junwang-noaa
Copy link
Collaborator

junwang-noaa commented Jan 27, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

20130401 ICs at C384 are under /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/BM_IC/. What resolution do you need? Thanks!

@junwang-noaa
Copy link
Collaborator

junwang-noaa commented Jan 28, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

Hi Bob,

Thanks for all the info on initializing the small water bodies that don't exist in CFSR. While we are putting on the final touch on Prototype 6, which emphasizes on GFSv16, I think it'd make sense to pay attention to small lakes/rivers when the flake model is active.

Best,
Shan

@rgrumbine
Copy link

What prototype will include flake?

@ShanSunNOAA
Copy link
Collaborator Author

A new land model will be in Prototype 7. Maybe flake will be a part of it?

@ShanSunNOAA
Copy link
Collaborator Author

@junwang-noaa Could you copy data from "/scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/" again, as I found an error in the description for land_frac? Sorry about that.

BTW, ICs for C96_L127 is added under /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/BM_IC/2013040100/gfs/. Let me know if you have questions. Thanks.

@SMoorthi-emc
Copy link
Contributor

SMoorthi-emc commented Jan 28, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

@SMoorthi-emc

I got sfc data from CFSR (/scratch2/BMC/gsd-hpcs/Shan.Sun/cfs2fv3ic/2013100100/gfs). It is mapped onto FV3 at /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/BM_IC/2013100100/gfs/C384_L127/INPUT/, using the oro data at /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5/input-data-20210115_frac/FV3_input_frac/C384_l127.mx025_frac/.

If I understand it correctly, "global_chgres" would interpolate nearest water temperature onto lake, as it has 3 surface types (land, water and ice) and doesn't distinguish lake from ocean.

Let me know if I am not clear. Thanks,
Shan

@DeniseWorthen
Copy link
Collaborator

@shansun6 I will be re-generating the mapped mask file for c96 after I fix an issue with the 1-deg MOM6 ocean mask (MOM Issue #47). I do not anticipate that the other mapped masks will change but I wanted to give you a heads up that the c96 mapped ocean mask will change.

@junwang-noaa
Copy link
Collaborator

@DeniseWorthen @shansun6 So I will wait to update the oro/fv3 ICs data in new input directory input_data_20210128.

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Jan 29, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

@junwang-noaa Sure. Will let you know when the updated oro data is ready. sfc data will need to be updated accordingly as well.

@DeniseWorthen
Copy link
Collaborator

@shansun6 I've regenerated the mapped ocean mask for the c96mx100 case after fixing the single point in the MOM6 grid that turns to ocean at run time. The mapped ocean mask file is identical (this is on tile4). I'm surprised it didn't change but I wonder if it is because is a single grid point between to land points. In any case, you can safely use the previous mapped ocean masks.

@jiandewang
Copy link
Collaborator

@DeniseWorthen can you check the grid index you used ? it should be i=88,j=132, not j=133 as you mentioned earlier.

@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Feb 1, 2021 •
edited
Loading

The topo-edits file gives the changed grid point at i=88,j=132. When reading the mask file in the GRIDGEN repo to create the first required file (tripole.mx100.nc), this point needs to be indexed by 1 in both directions in order to create a mask which is identical to that created by MOM6 at run time. The following is the same region as shown in the MOM6 issue #47 after inserting the fix in the GRIDGEN code. The fix is to change the mask at i=88+1,j=132+1 from a mask=0 to mask=1. Taking the difference of this field with the ocean_geometry field which is generated at run time shows they are identical.

Screen Shot 2021-02-01 at 6 05 05 PM

This is the original mapped ocean mask on tile4 with the lat/lon where the ocean mask is modified at run time (black dot):

land_frac_ori

And using the new mapped ocean mask:

land_frac_new

@DeniseWorthen
Copy link
Collaborator

I have checked this again and the mapped ocean mask at C96 DOES change when the ocean grid point changes. I will post new figures.

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Feb 22, 2021 via email

@DeniseWorthen
Copy link
Collaborator

These figures show the changed ocean point for mx100 (land->ocean) and the masked ocean mask for the original case (original files provided to Shan in directory /scratch2/NCEPDEV/stmp1/Denise.Worthen/ForShan/mapped_omask_fix_mx100 in Aug2020)
and the same field after fixing the ocean single point. The two files which have changed from the previous version are C192.mx100.tile4.nc and C96.mx100.tile4.nc. All other mapped ocean mask files are bit identical.

Original:
mapped_omask_fix_mx100_C96 mx100 tile4 nc

New:
grids-20210223_C96 mx100 tile4 nc

@junwang-noaa
Copy link
Collaborator

junwang-noaa commented Feb 23, 2021 via email

@DeniseWorthen
Copy link
Collaborator

I'm not sure I understand your question. When we originally made the mapped ocean masks, the ocean mask we used contained land at a certain point. That was fixed (because at run time MOM6 actually changes that point from land->ocean). The two figures show the new ocean mask mapped to the tile4 of FV3.

One thing that is a little confusing is that these are mapped ocean mask---so the ocean is 1 and the land is 0. So the ocean mask at that point (mapped to tile4) is higher (more watery) in the new case.

@junwang-noaa
Copy link
Collaborator

junwang-noaa commented Feb 23, 2021 via email

@DeniseWorthen
Copy link
Collaborator

The C96.mx100.tile4 has 4 points which are different. The C192.mx100.tile4 has 6 points which are different.

@junwang-noaa
Copy link
Collaborator

junwang-noaa commented Feb 23, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Feb 23, 2021 via email

@DeniseWorthen
Copy link
Collaborator

Shan,

We are not currently testing a C192mx100 configuration, correct.

The mapped ocean mask files are here at /scratch2/NCEPDEV/climate/Denise.Worthen/grids-20210223

Thanks.

@junwang-noaa
Copy link
Collaborator

@shansun6 Is there any progress on this issue? Thanks

@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Apr 16, 2021 •
edited
Loading

@shansun6 I've been looking at the directories in this location: /scratch2/BMC/gsd-fv3-dev/FV3-MOM6-CICE5. I'm very confused what is what. Can you tell me which of these directories:

a) contain the atm input (ICS, oro) that are being used in P6
b) contain the atm input for 20161003 for c96 and c192 (L64) which use the corrected mapped ocean mask for the C96 case?

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Apr 16, 2021 via email

@DeniseWorthen
Copy link
Collaborator

Hi Shan,

We are going to be updating to a new date, but at this point I'd like to be able to finally switch MOM6 over to using the mesh file. I can't do that in the RTs unless we have the ATM files which used the corrected mapped ocean mask for C96mx100. I think you've probably generated them?

Since making the update for the P6 ICs will require a new inputdata directory in the RTs and a new baseline, I thought it would be a chance to get the mommesh switched over.

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Apr 18, 2021 via email

@DeniseWorthen
Copy link
Collaborator

Hi Shan,

Thanks. I want to be careful here since it seems like there are a lot of changes floating around. I see your readme and that is clear. What I'm not sure about is whether the L127 input in that directory are also 20161003 or if the L127 is now 20181001?

If the dates differ between L64 and L127, then I will create a subdir in the baseline input data to separate them. I think in the future we need to add a date-stamp to the file name so that it is clear what is what.

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Apr 19, 2021 via email

@ShanSunNOAA
Copy link
Collaborator Author

ShanSunNOAA commented Apr 20, 2021 via email

@DeniseWorthen
Copy link
Collaborator

Hi Shan,

I think I've got it all now. I've rsync'd what you had in the lakeint_p6/FV3_input_frac directory and then moved the L64 and L127 to a subdirectory 20161003. I think that will prevent confusion when we switch to 20181001. I'll make the required changes in the RT scripts and test.

@DeniseWorthen DeniseWorthen mentioned this issue Apr 20, 2021
Merged
13 tasks
@DeniseWorthen
Copy link
Collaborator

After looking at the scripts I realized I can't use a dated subdirectory because the fixed files (oro data) is used by both the regular regression tests and the benchmark regression test and they have different SMONTH,SDAY,SYEAR.

@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Apr 21, 2021 •
edited
Loading

Hi Shan,

The new C96L64 input fails in the C96 tests with the same zlvl error discussed in this comment:

In the debug tests:

181: fv3.exe            000000000E87DA0C  icepack_atmo_mp_a         250  icepack_atmo.F90
181: fv3.exe            000000000E882FBF  icepack_atmo_mp_i         952  icepack_atmo.F90

@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Apr 21, 2021 •
edited
Loading

I verified that the c96L64 tests fail with the same error if I switch the use_mommesh flag back to false.

@DeniseWorthen DeniseWorthen self-assigned this Apr 23, 2021
@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Apr 28, 2021 •
edited
Loading

The issue is that ATM is exporting a large negative value of inst_height_lowest to ICE, as shown in the following test cases.

  1. The current develop branch using the current input data for C96,mx100,L64. This code runs.
  2. The same code using the updated input data for C96,mx100,L64. This code crashes.
  3. Case (2) but run in a sequential run sequence. In this case, the first values sent to ICE will be after the ATM has taken 1 timestep. This code is runs.

For 1) and 2), a mediator history write was inserted in the run sequence as so:

runSeq::
@900
   MED med_phases_prep_ocn_avg
   MED -> OCN :remapMethod=redist
   OCN
   @900
     MED med_phases_prep_atm
     MED med_phases_prep_ice
     MED med_phases_history_write
...

The history write is prior to the ATM running, so the fields present in the first history file will be the field that is read in by ATM at start up. Since the ATM and ICE are running concurrently, this field is the field sent to ICE at startup. The value of atmImp_Sa_z is the inst_height_lowest value exported by the ATM.

For Case 1; negative height values in 3 locations along the Antarctic Pennisula, only one of which is in the ATM's fractional ocean.

ori_input

For Case 2; large negative height value (-11.32) in the Ross Sea.

new_input

Checking the Case 1 (existing input data) for negative height values exported on other tiles shows that tiles 3 and 5 also contain negative height values over ATM's fractional ocean. When mapped to the ICE however, the field Sa_z field has a minimum value of 0.0. In Case 2 (updated input) however, 12 points appear with negative height when mapped to the ICE. These 12 points are the mapped locations of the single -11.32 value from the ATM in the Ros Sea. This causes a seg fault in the ICE when it attempts to calculate log(zlvl/zref) where zlvl = imported height and zref=10.0.

For Case 3: In sequential run sequence, the ATM creates all positive, smooth values for height_lowest after running one timestep and these are the height_lowest values sent to ICE for the first timestep. This is why the sequential run sequence works even with the new input data.

seqeuntial

A second test imposing a minimum value of inst_height_lowest of 1.0 in the atmos_model.F90 also allowed Case 2 to run to completion:

diff --git a/atmos_model.F90 b/atmos_model.F90
index e5eec4e..7f78893 100644
--- a/atmos_model.F90
+++ b/atmos_model.F90
@@ -2599,7 +2599,7 @@ end subroutine atmos_data_type_chksum
           nb = Atm_block%blkno(i,j)
           ix = Atm_block%ixp(i,j)
           if (associated(DYCORE_Data(nb)%coupling%z_bot)) then
-            exportData(i,j,idx) = DYCORE_Data(nb)%coupling%z_bot(ix)
+            exportData(i,j,idx) = max(DYCORE_Data(nb)%coupling%z_bot(ix),one)
           else
             exportData(i,j,idx) = zero
           endif

This was referenced Apr 28, 2021
Closed
Closed
@DeniseWorthen DeniseWorthen mentioned this issue May 8, 2021
Closed
epic-cicd-jenkins pushed a commit that referenced this issue Apr 17, 2023
@danielabdi-noaa
Convert machine scripts to yaml format. (#388)
cc96304 
* Make machine files yaml.

* Remove redundant SR_WX dir

* Remove some duplicate derived types.

* Convert constants to yaml.

* Bug fix GFDL grid.

* Bug fix machine lower/upper case.

* Fix unittest to capture exit code.

* Gaea lmod setup fix with tcsh.

* Add missing gaea commands.

* Remove obsolete module-setup scripts.

* Fix linux modulefile name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DeniseWorthen DeniseWorthen

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update input data consistent with P6 DeniseWorthen/ufs-weather-model
6 participants
@jiandewang @rgrumbine @junwang-noaa @DeniseWorthen @SMoorthi-emc @ShanSunNOAA