ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
310 stars 315 forks source link

mkmapdata should use shared mapping tools #13

Closed billsacks closed 5 years ago

billsacks commented 6 years ago

Bill Sacks < sacks@ucar.edu > - 2013-05-07 15:48:42 -0600 Bugzilla Id: 1683 Bugzilla Depends: 1938, Bugzilla CC: anthony.p.craig@gmail.com, erik@ucar.edu, mlevy@ucar.edu, rfisher@ucar.edu, sacks@ucar.edu,

Mike Levy suggested that CLM's mkmapdata tool should use the shared mapping tools, and in particular tools/mapping/gen_mapping_files/gen_ESMF_mapping_file/create_ESMF_map.sh -- rather than directly calling the ESMF tool. The main reason for this is that the shared tool can provide an insulating layer, requiring less maintenance of the CLM tool if the version or interface of the ESMF tool changes in the future.

We wanted to get this into the cesm1.2 release, but time limitations prevented doing so.

Here are some notes on what needs to be done to accomplish this:

First, some notes from Mike Levy:

I've created

https://svn-ccsm-models.cgd.ucar.edu/tools/mapping/trunk_tags/mapping_130410

with all of the changes we talked about (and more). To generate the file

map${grid}${lmask}to${res}_nomask_aaveda$CDATE.nc

You'll want to run

$CESMROOT/tools/mapping/gen_mapping_files/gen_ESMF_mapping_file/create_ESMFmap.sh -fsrc [file corresponding to ${grid}] -nsrc ${grid}${lmask} -fdst [file corresponding to ${res}] -ndst ${res}_nomask -map aave --clm_name

You can add the following (see the README file in gen_ESMF_mapping_file for more options):

This should work on yellowstone, caldera, and geyser. It may even work on jaguar, but as I said I've never tried.

Now, my notes (some of this repeats what Mike said):

--- TESTING ---

--- DEALING WITH THE LOGIC POINTING TO THE BETA SNAPSHOT CODE ---

Once the 6.2.0 release is made for the ESMF tool, we can remove the explicit setting of ESMFBIN_PATH in the CLM mkmapdata.sh -- i.e., we can remove the above logic, as long as the shared mapping tools point to the new 6.2.0 release. At that point, all of stuff related to 'hostname' in mkmapdata.sh can go away, I think.

Since we're no longer trying to get this done for the cesm1.2 release, it's probably worth waiting until the shared mapping tool can be updated to 6.2.0 before making any of the changes suggested in this bug report -- since at that point, mkmapdata.sh can become simpler, no longer requiring any knowledge of the host or any paths to the esmf tool.

billsacks commented 6 years ago

Bill Sacks < sacks@ucar.edu > - 2013-12-17 11:17:03 -0700

Un-assigning myself from this... I was only assigned to this because it came up in the course of my work a few months ago, but it's not currently relevant for me.

billsacks commented 6 years ago

Erik Kluzek < erik@ucar.edu > - 2014-02-28 11:41:34 -0700

The ESMF6.3.0 release is out, and hence we could do this once the ESMF6.3.0 is built on the yellowstone system (which I've asked CISL to do). We can then use

--pass2esmf "--netcdf4"

to turn netcdf4 on. And

--pass2esmf "--src_meshname UGRID --dst_meshname UGRID"

to use the UGRID in place of SCRIP. The ESMF6.3.0 release includes the ability to do --netcdf4 and use UGRID meshname.

ekluzek commented 5 years ago

Because of our plans of moving to ocgis for doing the regridding, I'm closing this task. Once, the development using ocgis is done, we should then look at updating cime/tools/mapping to use those developments.

643 and #645 now replace this task.