ESMCI / cime

Common Infrastructure for Modeling the Earth
http://esmci.github.io/cime
Other
161 stars 206 forks source link

enhancement request and offer: high resolution SST data sets in CAM #1798

Closed kdraeder closed 6 months ago

kdraeder commented 7 years ago

I (with help from Bob Tomas and others) have developed domain and mapping files between daily, 1/4 degree, AVHRR SSTs and a 1 degree CAM-FV from CESM2_0_beta05, including CISM1 (20 km) and MOSART.
I'd like this to become available as a supported DOCN resolution, for use with DART, CAPT, and other short forecast CAM applications.
It would be great if it could be generalized to CAM-SE and other resolutions of CAM. Thanks, Kevin

kdraeder commented 6 years ago

@mvertens This request has a new motivation. It will be highly desirable to use this high resolution SST set in the long reanalysis we are planning (with Yaga Richter and Joe Tribbia) for the coming year. It will generate CAM6 ensemble forcing files for use by other CESM2 components, especially those doing data assimilation with DART.

I'm hoping that my implementation in CESM2_0_beta05 will either be useful, or unnecessary in CESM2_0_0, but have not tested it yet.

kdraeder commented 6 years ago

@mvertens Can you recommend a path forward for this? Should I contact someone else?

jedwards4b commented 6 years ago

@kdraeder Do you have something that you could submit as a PR or does this require code development on our part?

kdraeder commented 6 years ago

@jedwards4b In CESM2_0_beta05 it was mostly (all?) xml file changes. It all worked there, but probably not in the most standardized way. I'll review what I did and try to work up a PR for it. Thanks for following up on this!

kdraeder commented 6 years ago

@jedwards4b

One question to answer before anyone does significant work is how much of the development that I did when implementing this as a 'user-defined grid' would transfer to making it a standard grid. Is there a well-established procedure for installing a new standard grid, which starts from scratch, or is it ad hoc and my pieces will be a good starting point? Assuming that it's the latter . . .

I've looked through the CESM2_0 user-defined grid documentation, http://esmci.github.io/cime/users_guide/grids.html It seems to be fundamentally the same as for CESM1_2, which are the instructions I followed for my cesm2_0_beta05 development. The main difference is that instruction 8 from 1_2 is missing. I hope that the mapping files will be made automatically.

If these instructions are up to date, then a significant amount of work has been done. Additional work might include extending my implementation for CAM-FV 1 and 2 degree grids (LND = ATM) to others that would benefit from hi-res SSTs: various resolutions of CAM-SE, MPAS, LND not = ATM, ...? There might be work involved with making this a standard option, that wasn't necessary for implementing a user-defined grid. I did not test the new grid with all data components (instruction 8).

There were several things in the instructions that didn't work in CESM2_0_beta05 as advertised in 1_2. Some of those might have been fixed since then, but we won't really know until we do it.

There was some work converting the AVHRR SST data files into the form needed by CESM, but that's not part of CIME. I have some that may be useful for testing. I don't know whether that will be easier or harder than under cesm2_0_beta05.

kdraeder commented 6 years ago

@jedwards4b I'm trying to use my hi-res SST pieces in CESM2_0_0 by telling it to use a user defined grid: create_newcase .... --user-grid \ --gridfile $my_config_grid.xml \ --res a%0.9x1.25_l%0.9x1.25_oi%d.25x.25_r%r05_m%d.25x.25g%null%null

It complains that "No variable GRIDS_SPEC_FILE found in case"

I see that GRIDS_SPEC_FILE is defined in config/cesm/config_files.xml and is supposed to be set in cime/scripts/lib/CIME/case/case.py:def set_value

But the search for that variable is in the following (self._files): <CIME.XML.env_case.EnvCase object at 0x2aaab0238110> <CIME.XML.env_run.EnvRun object at 0x2aaab0241790> <CIME.XML.env_build.EnvBuild object at 0x2aaaaecc3f90> <CIME.XML.env_mach_pes.EnvMachPes object at 0x2aaaaecc3990> <CIME.XML.env_batch.EnvBatch object at 0x2aaaaecd7290> <CIME.XML.env_mach_specific.EnvMachSpecific object at 0x2aaaaecd7410> <CIME.XML.env_archive.EnvArchive object at 0x2aaaaecd7650>

There's nothing in that list referring to config_files.xml, where GRIDS_SPEC_FILE is defined, so I think that the search is misguided.
Config_files.xml is mentioned in _get_component_config_data, but I'm not comfortable trying to use entities from that function to look for GRIDS_SPEC_FILE. Any suggestions?

jedwards4b commented 6 years ago

At first glance this looks like a bug in the --user-grid feature of create_newcase If you provide the full path to your gridfile I should be able to reproduce and address this problem.

kdraeder commented 6 years ago

The one I'm trying to use is /glade/work/raeder/Models/CAM_init/SST/config_grids+fv1+2deg_oi0.25_gland20.xml It's a merge of the one I developed for beta05 and the one in CESM2_0. There are parts I'm uncertain about; the grid for the stub GLC and the mask for the 0.25 degree ocean.

jedwards4b commented 6 years ago

@kdraeder I don't have permission to read that file.

kdraeder commented 6 years ago

I changed the permissions on that path to 744.

jedwards4b commented 6 years ago

No you didn't

ls -ltr /glade/work/raeder/
total 68
drwxr-xr-x  16 raeder p86850054  4096 Mar 12  2015 cases
drwxr-xr-x  48 raeder p86850054  4096 Nov 18  2015 Bf_ptmp
drwxr-xr-x   3 raeder p86850054  4096 Sep 12  2017 Git
drwxr-xr-x   2 raeder image      4096 Jul 11 11:57 Diag
drwxr--r-- 155 raeder p86850054 16384 Jul 13 13:09 Models
drwxr-xr-x 302 raeder image     16384 Jul 23 13:01 Exp
gold2718 commented 6 years ago

@kdraeder did what he said but it is the wrong action. For directories and executable files, the permissions should be 755. Plain files can be 744.

kdraeder commented 6 years ago

Doh! Sorry about that. The path seems to be 755 now.

jedwards4b commented 6 years ago

First you have several syntax errors in your config_grids file - use the xmllint program to find and fix them:

xmllint --noout --schema $CIMEROOT/config/xml_schemas/config_grids_v2.xsd $myconfig_grids.xml
jedwards4b commented 6 years ago

@kdraeder I don't have read permission for any of your gridmaps.

kdraeder commented 6 years ago

The config file passes xmllint now, I updated path names to use the new /glade, and I changed the permissions on the gridmaps paths to 755

jedwards4b commented 6 years ago

ls -ltr /glade/p/work/raeder/Exp/GWD_TMS_CLUBB/mapping/gridmaps/map_d.25x.25_TO_fv0.9x1.25_blin.160303.nc ls: cannot access /glade/p/work/raeder/Exp/GWD_TMS_CLUBB/mapping/gridmaps/map_d.25x.25_TO_fv0.9x1.25_blin.160303.nc: No such file or directory

kdraeder commented 6 years ago

This morning I changed all of the paths in my config_grids file from the old /glade/p/work to /glade/work, which is where the files live now. Are you using a copy of the config_grids from ealier?

jedwards4b commented 6 years ago

Okay - In case.py make the following change:

--- a/scripts/lib/CIME/case/case.py
+++ b/scripts/lib/CIME/case/case.py
@@ -776,8 +776,8 @@ class Case(object):
         #--------------------------------------------
         # grid
         #--------------------------------------------
-        if user_grid is True and gridfile is not None:
-            self.set_value("GRIDS_SPEC_FILE", gridfile)

in your config_grids xml file you need to remove spaces preceding full paths - that is

<file grid="atm|lnd" mask="d.25x.25"> /glade/
should be
<file grid="atm|lnd" mask="d.25x.25">/glade/

and finally you need to refer to the grid by its alias and not the full name - that is --res f09_d025

with that I think it should work.

kdraeder commented 5 years ago

@jedwards4b @gold2718 @jgfouca

It looks like the only change in CIME is to providenew entries into

$cimeroot/config/cesm/config_grids.xml.

These refer to new domain and mapping files, which are currently in my /glade directories. The supported versions of these files are in places like

   /glade/p/cesm/cseg/ 
   (or https://svn-ccsm-inputdata.cgd.ucar.edu/trunk/)
      mapping/gen_domain/map_gx1v4_to_1x1.25_aave_da_060511
      inputdata/share/domains/
      inputdata/ocn/docn7/
      inputdata/ice/cice/

I don't know the exact locations where my new files should go.

I'm wondering which of 2 strategies is best:

  1. Have my new files included in those repositories first, so that the new config_grids.xml file has the correct paths in it.
  2. Push a config_grids.xml file with paths pointing to my directories, until we're satisfied with it. Then import the files to the data directories, change the path names in config_grids.xml, test, and commit it again.

Thanks for any guidance.

Kevin

kdraeder commented 5 years ago

One more piece; the SST data files. The supported files (climatological, monthly means) also live in the CESM data repository. Should the 1/4 degree AVHRR SST files also live there? They're ~ 3 Gb/year, uncompressed. Or should a single year be there for testing purposes?

kdraeder commented 5 years ago

@jedwards4b @gold2718 @jgfouca Another piece that needs to be updated to recognize the new ocean resolution: components/clm/bld/namelist_files/namelist_definition_clm4_5.xml

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] commented 1 year ago

This issue was closed because it has been stalled for 5 days with no activity.

jgfouca commented 1 year ago

@jedwards4b , are you OK with letting this issue be closed as stale?

github-actions[bot] commented 10 months ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

jedwards4b commented 10 months ago

@kdraeder Is this task complete?

kdraeder commented 9 months ago

It's not complete.
There are several unanswered questions that prevented me from pushing it forward. At this point (cheyenne disappearing, more NUOPC infrastructure to fit into, ...) those questions may need to be reframed and it will take some work to describe the status of this issue. I won't be able to work on it until late December.

github-actions[bot] commented 6 months ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] commented 6 months ago

This issue was closed because it has been stalled for 5 days with no activity.