Closed ekluzek closed 4 years ago
I'm not completely sure if this still is a useful tool or not. It should be easy to fix. But, we should consider if we still want to keep it. The alternative would be for people to use their own tools to do this function.
I was about to make the same comment. Mariana and I put this tool in place a long time ago, and I'm not sure if anyone has ever actually used it. Arguably, it may become more important if CAM starts using unstructured grids more commonly. But at the same time, there are probably better tools available for doing this now.
FYI, I've used this in the past (not lately though) to regrid individual CLM SE history files, in part because it's pretty fast compared to other methods I've tried (e.g., NCL). However, as has been mentioned, if it goes away, I'm sure there are other tools available.
I asked Adam Herrington and Patrick Callaghan about they don't have any robust solution either. So I suppose we should keep it around for at least now. I put this as a discussion point for Thursday.
I also don't have anything general enough that CLM could use ... the problem is that (AKAIK) the connectivity files (SCRIP or ESMF files) cannot be created easily on the fly. Another issue is that the lat-lon arrays in the CLM output set points over ocean to missing values. So generating a weights file requires grabbing those coordinates from a grid or domain file as well.
You could look into adapting the se-dycore module cam/src/dynamics/se/interp_mod.F90 that interpolates to a lat-lon grid during run-time. This is invoked in user_nl_cam:
interpolate_output = .true.
interpolate_nlat = 192
interpolate_nlon = 288
Which in this example would dump out i/o on the f09 grid.
Adam
On Mon, Aug 31, 2020 at 1:44 PM Patrick Callaghan <patc@ucar.edu> wrote:
Hi Erik,
I wrote a plugin for the VISIT program, which is what I use to look at things.
It is not widely used and there has been no interest in using it, so it is just a
thing I do. I had a prototype to adapt this plugin for a simple viewer like ncview,
but I have not had time to work on it. I think that there are a number of people
working on display programs in python, but I have not seen any robust working
versions yet.
--> Patrick
OK, the underlying problem is that the build requires NetCDF library to be built with the NetCDF4 interface. So we'll just support this on cheyenne and drop testing it on CGD machines.
Brief summary of bug
mkprocdata test is failing on izumi with a build problem.
General bug information
CTSM version you are using: ctsm1.0.dev108-3-g19349614 release-cesm2.2 branch Does this bug cause significantly incorrect results in the model's science? N
Configurations affected: just mkprocdata on izumi
Important output or errors that show the problem