Will not port mksurfdata_map and mkmapdata to Derecho

[ekluzek]

Since, mksurfdata_esmf is coming soon with CTSM5.2 and there is a public branch for it. I think porting mksurfdata_map and mkmapdata in CTSM5.1 should NOT be done. If there are people who think we should consider doing that port, please let us know, and let us know why it would be important to you rather than moving to CTSM5.2. And if you really need it we may need your help in actually make it happen.

[ekluzek]

The same for mkprocdata_map, which I suggest we remove at this point.

[olyson]

I have been using mkprocdata_map recently to regrid history files from ne30 to fv0.9x1.25. For example, I needed to run ILAMB on an ne30 simulation and so I needed to regrid all of the monthly history files 1850-2014. It is quite fast. I don't have any other way to do that that I'm aware of. Maybe there are ESDS tools that exist or are being developed to do that? So maybe I would suggest not actually removing it. It seems like we could work on porting it to Derecho either before or after cheyenne goes away?

[wwieder]

@ekluzek I think this is fine for mksurfdata_map and mkmapdata.
Given that @olyson is using mkprocdata_map maybe we should move this, although I'd hope that the AMWG or ESDS already has a tool to translate ne30 history files into gridded output. Has anyone asked? I'll post on zulip.

[wwieder]

@ekluzek & @slevis-lmwg , this also make me wonder how testing for mksurfdata_esmf with CTSM5.2 is looking on Derecho?

[ekluzek]

On @samsrabin suggestion I looked at these for support on Casper and there does seem to be support for that for some of these. It probably wouldn't be hard to get mkprocdata working on Derecho. mkmapdata would be a bigger problem.

We have asked asked about regridding tools before, and the answer has been that there isn't a consistent set of tools that everyone uses. Different people do different things. We could adopt something that someone uses though, and recommend it's use?

Because these tools can possibly be used on Casper I suggest that we leave them in place until CTSM5.2. And we could leave mkprocdata in place since @olyson uses it. I'll look at how hard it is to port it to Derecho for #2276 and if it's easy enough we can do that.

@wwieder we need to update CTSM5.2 to the Derecho tag to have externals that will work on Derecho. So that's still pending.

[mvertens]

@wwieder @ekluzek @olyson @rosiealice @mvdebolskiy - CAM has the ability to output files on a lat/lon grid at run time while running on a non lat/lon grid (i.e. ne30). I think this capability would be fairly straightforward to incorporate into CTSM and would alleviate the need to post process these files. In CAM this is an option - and the same type of option could be introduced into CTSM. I am thinking of incorporating this into the NorESM fork of CTSM and would be happy to do a PR back to CTSM once this is done.

[ekluzek]

@mvertens this sounds really great to me I have to say. The lack of this in CTSM means that people aren't going to run standalone I cases with unstructured SE grids, unless they really have to. But, with this capability I could see it becoming the standard since ne30np4.pg3 is now the standard grid for CAM.

So some questions on details. If you were running at ne30np4.pg3 would it output BOTH on ne30np4.pg3 and say f09 or just the later? Do you have some choice in the grid that it interpolates output to? I wouldn't expect you to add these if they aren't in CAM, but wondering about how it works. I'll also take a look at CAM and see how they've implemented it there.

Thanks for offering this contribution! If you are OK with it and everyone agrees with this I'll create an issue and assign you to it. It feels weird to say that to my former boss, but I would like it to have it's own issue...

[ekluzek]

OK, answering my own questions here are the options that CAM has in it's namelist. This is nicely comprehensive and flexible:

<entry id="interpolate_output" type="logical(10)" category="history"
    group="cam_history_nl" valid_values="">
If interpolate_output(k) = .true., then the k'th history file will be
interpolated to a lat/lon grid before output.
Default: .false.
</entry>

<entry id="interpolate_nlat" type="integer(10)" category="history"
    group="cam_history_nl" valid_values="">
Size of latitude dimension of grid for interpolated output.
If interpolate_nlat and interpolate_nlon are zero, reasonable values
will be chosen by the dycore based on the run resolution.
Default: 0
</entry>

<entry id="interpolate_nlon" type="integer(10)" category="history"
    group="cam_history_nl" valid_values="">
Size of longitude dimension of grid for interpolated output.
If interpolate_nlat and interpolate_nlon are zero, reasonable values
will be chosen by the dycore based on the run resolution.
Default: 0
</entry>

<entry id="interpolate_type" type="integer(10)" category="history"
    group="cam_history_nl" valid_values="0,1">
Selects interpolation method for output on lat/lon grid.
0: Use SE's native high-order method.
1: Use a bilinear method.
Default: 1 (bilinear)
</entry>

<entry id="interpolate_gridtype" type="integer(10)" category="history"
    group="cam_history_nl" valid_values="1,2,3">
Selects output grid type for lat/lon interpolated output.
1: Equally spaced, including poles (FV scalars output grid).
2: Gauss grid (CAM Eulerian).
3: Equally spaced, no poles (FV staggered velocity).
Default: 1
</entry>

[mvertens]

@ekluzek - thanks for your response. Creating an issue and assigning it to me sounds good. Thanks.

[wwieder]

@mvertens agreed, this would be a welcome contribution!

[ekluzek]

OK, I realize this same question applies to the release-cesm2.2 and release-clm5.0 tags we are working on. I'm kind of thinking that we remove them in these older versions, and add a README that says if you need these tools for older versions you use a current ctsm5.1 tag.

[ekluzek]

Looking at the amount of work it would be to port mksurfdata_map, and mkmapdata to Derecho for the cesm2.2 and cesm2.1 tags, which will include updating paths and getting things working. This doesn't seem worth it. As such I'm going to remove ALL of the tools from these tags, and let users know if they need them -- they can used a development tag for it. Everyone let me know if you disagree. Thanks.

[wwieder]

I think this is fine, Erik