Add option to use global average of terrain standard deviation on surfdata files

[ekluzek]

We talked about this in this mornings CTSM meeting. We'd like to add an option to use the global average of terrain standard deviation on surface datasets. This would be an option that starts at the creation of mapping files in mkmapdata. It then wouldn't run the 1km mapping files and hence would run much much quicker. Downstream from that it would just use a constant value (that we set as the global average).

This should be fairly easy to add in and would make the creation of mapping files much, much easier and faster and not requiring nearly as much memory.

@barlage @swensosc @billsacks

[billsacks]

We discussed two other options at today's CTSM-software meeting, so now we're considering the following three options ((1) is the option discussed two weeks ago; (2) and (3) were options that, in today's discussion, we thought might be better):

1. Use some average value for terrain standard deviation everywhere

2. Skip putting this field on the surface dataset entirely, instead using a different parameterization for subgrid snow cover fraction that doesn't rely on this field

3. Have a lower-resolution version of this file, if we could construct the remapping to give basically the same results from a lower-resolution file. (Note that right now the mapping is done by taking the standard deviation of 1km cells. If we went to a lower-resolution file, we'd presumably have to store the high-resolution standard deviation on that file, maybe in addition to the mean???)

@swensosc - this is becoming higher priority. Is this something you can give some thought to, to determine what would be the best path forward?

[ekluzek]

FYI. OK, I added a fast option to mkmapdata.sh to run skipping the creation of the maps for the 1km file. I was able to send it using the default qcmd, giving it 2 hours of time, and it completed a single point mapping in about three and a half hours. This means the memory requirements are much lower, and if running with more than one processor we could cut the total time down as well.

[swensosc]

std_elev.nmelt.pdf

[ekluzek]

@swensosc comment here. #1198 (comment) recommends as a default that 20 be used. And also suggests that fmax could be set to zero.

I think this should still be done, because it will make creating mapping files very fast. Even with the improvements we are planning in the tool chain doing this is the best option to speed up the process dramatically.

[ekluzek]

We have this in place in subset_data now already.