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.

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

mkmapdata should use shared mapping tools #13

Closed
billsacks opened this issue Dec 16, 2017 · 3 comments
Closed

mkmapdata should use shared mapping tools #13

billsacks opened this issue Dec 16, 2017 · 3 comments
Labels
closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix enhancement new capability or improved behavior of existing capability

Comments

@billsacks
Copy link
Member

Bill Sacks < [email protected] > - 2013-05-07 15:48:42 -0600
Bugzilla Id: 1683
Bugzilla Depends: 1938,
Bugzilla CC: [email protected], [email protected], [email protected], [email protected], [email protected],

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_aave_da$CDATE.nc

You'll want to run

$CESMROOT/tools/mapping/gen_mapping_files/gen_ESMF_mapping_file/create_ESMF_map.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):

  • If the source file is a regional map, use -tsrc regional
  • If the destination file is a regional map, use -tdst regional
  • If you want to run the serial ESMF implementation, use -serial
  • If you need the 64bit offset, use -big
  • If you want to pass any other flags to ESMF, use --pass2esmf $FLAGS

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

    • make sure mapping files are created, with the same name as before
  • 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)

    • make sure mapping files are created, with the same name as before

--- 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 billsacks added this to the clm5 milestone Dec 16, 2017
@billsacks billsacks added the enhancement new capability or improved behavior of existing capability label Dec 16, 2017
@billsacks
Copy link
Member Author

Bill Sacks < [email protected] > - 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
Copy link
Member Author

Erik Kluzek < [email protected] > - 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.

billsacks added a commit that referenced this issue Dec 28, 2017
Truncate small h2osfc values to zero

This replaces the earlier code that only did this truncation in one
particular circumstance.

This seems mainly important to truncate small negative numbers to 0, but
it also seems like a good idea to truncate small positive numbers that
should have been 0.

With some intermediate commits on this branch, I did some careful tests
to ensure that these diffs introduce no more than roundoff-level
changes.
@ekluzek ekluzek modified the milestones: clm5, cmip6 May 17, 2018
@ekluzek ekluzek modified the milestones: cmip6, future Oct 26, 2018
@billsacks billsacks removed this from the future milestone Nov 5, 2018
@ekluzek ekluzek added the closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix label Feb 26, 2019
@ekluzek
Copy link
Collaborator

ekluzek commented Feb 26, 2019

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.

@ekluzek ekluzek closed this as completed Feb 26, 2019
billsacks pushed a commit to billsacks/ctsm that referenced this issue Nov 18, 2019
MiCurry pushed a commit to MiCurry/CTSM that referenced this issue Sep 16, 2021
slevis-lmwg referenced this issue in slevis-lmwg/ctsm Aug 1, 2023
mvertens pushed a commit to mvertens/ctsm that referenced this issue Dec 8, 2023
Fix apply_use_init_interp() use in branch run, as suggested in  ESCOMP#786
jedwards4b added a commit to jedwards4b/ctsm that referenced this issue Feb 6, 2024
ac3e6dd Bump to 0.6.2
612fa61 Merge pull request ESCOMP#13 from jedwards4b/add_fxhash
cd74fd7 Merge pull request ESCOMP#14 from jedwards4b/fix/dir_path
459ee47 merge to main
f456ca0 fix issue with sparse checkout dir path
ad0a976 add support for fxhash variable in .gitmodules

git-subtree-dir: .lib/git-fleximod
git-subtree-split: ac3e6dd
samsrabin pushed a commit to samsrabin/CTSM that referenced this issue Apr 19, 2024
samsrabin pushed a commit to samsrabin/CTSM that referenced this issue Apr 19, 2024
jedwards4b added a commit to jedwards4b/ctsm that referenced this issue Jun 2, 2024
AGonzalezNicolas pushed a commit to HPSCTerrSys/clm5_0 that referenced this issue Jun 27, 2024
Truncate small h2osfc values to zero

This replaces the earlier code that only did this truncation in one
particular circumstance.

This seems mainly important to truncate small negative numbers to 0, but
it also seems like a good idea to truncate small positive numbers that
should have been 0.

With some intermediate commits on this branch, I did some careful tests
to ensure that these diffs introduce no more than roundoff-level
changes.
AGonzalezNicolas pushed a commit to HPSCTerrSys/clm5_0 that referenced this issue Jul 5, 2024
Truncate small h2osfc values to zero

This replaces the earlier code that only did this truncation in one
particular circumstance.

This seems mainly important to truncate small negative numbers to 0, but
it also seems like a good idea to truncate small positive numbers that
should have been 0.

With some intermediate commits on this branch, I did some careful tests
to ensure that these diffs introduce no more than roundoff-level
changes.
ekluzek pushed a commit to ekluzek/CTSM that referenced this issue Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: wontfix We won't fix this issue, because it would be too difficult and/or isn't important enough to fix enhancement new capability or improved behavior of existing capability
Projects
None yet
Development

No branches or pull requests

2 participants