360x720 mapping directory name disagrees with resolution name

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-04-13 05:16:34 -0600
Bugzilla Id: 1662
Bugzilla CC: bugzillaMuszala@gmail.com, erik@ucar.edu, mvertens@ucar.edu, rfisher@ucar.edu, sacks@ucar.edu,

Recently, the 360x720 resolution was renamed to 360x720cru. However, the directory in inputdata/lnd/clm2/mappingdata/maps is still named 360x720. This (a) could cause confusion, and more importantly (b) messes up the tools we have to post-process files created by mkmapdata (automatically creating xml entries and moving files into the correct location).

I'm not sure what the correct solution is:

(1) Live with it? It seems like we'll always be tripping up on this, having to correct the automated mkmapdata post-processing scripts.

(2) Fix the mkmapdata post-processing tools so they give special handling to this grid?

(3) Rename the mapping directory in inputdata? But that will break any older tags.

(4) Rename the mapping directory in inputdata, and make a sym link in yellowstone's inputdata (360x720 -> 360x720cru) so that old tags will at least continue to work there. This is probably my preference.

Note that a renaming of the inputdata directory will require (a) changing paths in the namelist defaults files, and (b) require running some CESM tests and tools tests at 360x720cru resolution, to make sure all necessary paths have been changed correctly. These tests should be done BEFORE making the sym link suggested in (4).

Because this might be a pain, I think it can wait until after the release.

[billsacks]

Erik Kluzek < erik@ucar.edu > - 2013-04-13 09:08:57 -0600

Hi Bill

I propose another solution entirely, that isn't too hard.

Create a new directory called 360x720cru, and put a copy of the mapping files in there. In svn you can do this with "svn copy" so the repo. doesn't increase in size. On disk we'll have both copies around, but that's OK. This means there is no special handling for this grid, and we just have dual copies of the directory on disk. We need the old version around because of previous versions of the model, and the new for ones going forward.

So

inputdata/lnd/clm2/mappingdata/maps/360x720 -- will continue to exist for old tags

inputdata/lnd/clm2/mappingdata/maps/360x720cru -- will exist for new tags going forward.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-04-13 13:53:02 -0600

I agree with Erik's solution.

However, in the interest in getting my tools tag made this weekend -- and in the interest of not having this work take over my weekend -- I am not going to make this change as part of this tag. I'm worried that, what seems simple on the surface will actually take some time to get right. To test it properly, I think we should first rename (NOT copy) the inputdata directory and make all necessary changes in the xml files, then run the full test suite to make sure everything necessary has been changed in the xml files, then finally do the copy for the sake of old tags.

My feeling is that this isn't critical to fix immediately, because everything works as is right now. It will only become a problem when we are adding new standard mapping files.

Thus I propose that this be deferred until after the release freeze.

[billsacks]

Mariana Vertenstein < mvertens@ucar.edu > - 2013-04-13 20:15:28 -0600

Bill - I agree with your proposal. The key point is to make the release freeze. I had run over this issue with Erik before I checked this in - and it seemed okay. We can sort this all out later - as long as it is working now.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-12-17 11:16:21 -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.

[ekluzek]

This is no longer an issue in the latest CTSM especially with ctsm5.2.0. Closing as wontfix, but it's no longer a problem either so doesn't matter.