Closed billsacks closed 5 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.
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.
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.
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):
need to pass -clm_name (this forces the tool to use the CLM naming convention, which differs somewhat from the naming convention used elsewhere for mapping files)
need to pass src & dest names, NOT weight file name. Note that these names should include the mask so that the output name looks right
For the case where we point to the beta snapshot, we will still need to set ESMFBIN_PATH, to override what's set in Mike's script. This refers to this code:
if [ "$lrgfil" = "--netcdf4" ] || [ ${SRC_TYPE[nfile]} = "UGRID" ] || [ $DST_TYPE = "UGRID" ]; then case $hostname in ys | caldera | geyser ) if [ $mpitype = "mpiuni" ]; then MY_ESMF_REGRID=/glade/p/work/svasquez/ESMF620bs18-mpiuni/bin/ESMF_RegridWeightGen else MY_ESMF_REGRID=/glade/p/work/svasquez/ESMF620bs18/bin/ESMF_RegridWeightGen fi ;; ) echo "No support for --netcdf4 or UGRID on machines other than yellowstone/caldera/geyser" exit 5 ;; esac fi
--- TESTING ---
test generation of a global and single-point mapping file in a single submission
test generation of a global and single-point mapping file for Sean Swenson's file -- i.e., the topostats 1km file, which triggers the logic given above (pointing to the beta snapshot in the svasquez directory)
--- 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.