Update of ESMF version causes mizuRoute to abort #452
Assignees
Labels
Comments
|
Hi Erik, yes, it is clearly from the esmf function, but do you know what exactly is the problem? is it node id problem (usually starting 0, but does not like 0 any more?)? Let me know if there is anything I should look into! |
|
The ccs_config issue for this is that documents the ESMF updates that result in the problem is here: |
|
Here's some more information on one of the failing cases and what the mesh file looks like: |
|
Here are the other mesh files... |
|
And here's the mesh that has just the small squares around the center point of the HRU's |
|
Hi Erik (@ekluzek), hru_id is in double (I expected id to be int32). This might be problem? Not sure why it is in double (must be from python)..... but it is easy to change a type from double to int32? I wonder the other meshes also have ID in double precision. UPDATE: I went through all the other mesh ID to check the type. all but HDMA amazon meth are in int64. |
|
ah, looking at PET log, ESMF is complaining mesh node id (index?) not computing node.... that is strange (I never expect node index become negative) |
|
Bob Oehmke from ESMF figured out the problem is that elementConn starts at 0 rather than the expected 1. This used to work, but because of potential issues more checking was added, and it now fails. ESMF is going to add an update where starting at 0 will also work. And also add clearer error checking so that it would easier to catch the problem. @nmizukami has updates to the mesh files so they start at 1, so we'll try that out and verify this fixes the problem. |
|
Trying out the 5x5_amazon case on Izumi starting elementConn at 1 works! |
|
We need to move ESMF mesh with 1-index from naoki's directory to cesm data directory. But also ESFM may allow us to use 0-index base MESH in next update?? |
|
ESMF told us that the fix for this went into ESMF 8.6.1. Which is great. However, in terms of CESM this hasn't been brought in as of now. ccs_config has NOT updated to using that version on either Derecho nor Izumi. Derecho uses 8.6.0 and Izumi 8.5.0. There are a couple beta tags of 8.6.1 on Derecho, and a beta tag of 8.7.0 also so those are the only possibilities. On Izumi 8.5.0 is the latest version available, so trying it out would require installing a newer version of ESMF on at least Izumi, as well as using a beta version on Derecho. |
|
FYI: Here's the PR that fixed it in ESMF esmf-org/esmf#147 and the first beta tag with it was 8.6.1.b02 and that is available on Derecho. It does look like there is a 8.6.1 library on Derecho, but I'm not sure what it's compatible with. |
|
The latest CESM is now using ESMF8.6.1 -- which should probably work correctly without updated datasets. We need to confirm that, and if so we could just do that rather than updating datasets. |
|
New datasets are here: /glade/campaign/cgd/tss/people/mizukami/mizuRoute_data/cesm_mizuRoute that need to be copied over into inputdata space and rimported. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
And update of the ESMF version on both Cheyenne and izumi cause mizuRoute to abort in the initialization phase inside of mizuRoute.
The PET file shows the following..
Definition of done:
The text was updated successfully, but these errors were encountered: