Output PUMAS variables on trop_cld_lev when possible

[nusbaume]

What is the feature/what would you like to discuss?

Many PUMAS variables only have values in the lower atmosphere, as specified by trop_cld_lev. However, many variables also still seem to be output on the full range of model levels. This could result in CAM history files being larger than they actually need to be, which results in wasted disk space.

Given this, it might be good to go through the PUMAS/CAM interface and make sure that the variables that are output on the full number of model levels do so because they have to (e.g. they are pbuf variables), and otherwise to output them using the trop_cld_lev coordinate.

Is there anyone in particular you want to be part of this conversation?

@cacraigucar @katc

Will this change (regression test) answers?

I Don't Know

Will you be implementing this enhancement yourself?

Any CAM SE can do this

[adamrher]

FYI, @bstephens82 @PeterHjortLauritzen @JulioTBacmeister and I are currently revisiting this trop_cld_lev value scientifically, which is invoked in clubb_intr and micro_pumas_cam via:

use ref_pres,       only: top_lev=>trop_cloud_top_lev

These are the only places where it's at. it's in macrop_driver too (pre-CAM6 macro driver) which to me suggests it is historically used for the macrophysics and microphysics only ... (oddly, ZM has a different variable determining how high it can go).

So just providing some context. I think I agree with your proposal to just output variables on a "macro/micro grid" only up to trop_cld_lev. Won't this be confusing to users? They would have to specify of subset of hyam/hybm/PMID/Z3 if they wanted to plot it with the appropriate vertical coordinates.

[nusbaume]

Interesting! I was also assuming that this vertical coordinate was only really used for microphysics, but if its used in CLUBB as well then it might also help to output those variables on the trop_cld_lev coordinate in addition to the PUMAS quantities.

I also do agree that it could cause some issues with model diagnostics and analyses to have multiple vertical level options, but if that becomes a major issue then we can always also output extra hyam/hybm quantities that are subset in the same way. Plus given that PR #632 is going to be doing this already I think the cat may already be out of the bag.

Finally, I know users are constantly having disk space issues, so any chance we have to reduce the writing of nothing but zeros to disk would probably be good IMO.

[adamrher]

I guess with the new L58/L93 grids we should be eye'ing reducing disk space wherever we can. I suppose it can't hurt to open a separate issue for clubb vars, slated for completion sometime in 2023 (the current clubb PR is already rather big so I don't know we should pile on top of that one).

So if we call this new grid "tlev", then we have lev, ilev and tlev, and three corresponding hya/hyb pairs. I think that would be enough.

[nusbaume]

Just an FYI that the CLUBB equivalent of this issue can now be found here: #716

[Katetc]

If we are cleaning up PUMAS variable dimensions, I would like to make a note to take a closer look at bergso_grid, which is now treated very uniquely in micro_pumas_cam after the ddt is implemented. I (almost) understand why it is currently that way, but I think we (maybe I) should look at the possibility of adjusting the array dimensions so that it doesn't have to be going forward. This may require changing the array dimensions for the variable in the actual PUMAS code as well.

[cacraigucar]

If we are cleaning up PUMAS variable dimensions, I would like to make a note to take a closer look at bergso_grid, which is now treated very uniquely in micro_pumas_cam after the ddt is implemented. I (almost) understand why it is currently that way, but I think we (maybe I) should look at the possibility of adjusting the array dimensions so that it doesn't have to be going forward. This may require changing the array dimensions for the variable in the actual PUMAS code as well.

Before working on this, I would suggest that @Katetc and @cacraigucar discuss possible solutions as there might be a better modification than to change dimensions inside of PUMAS (I don't have one right now, but I think a discussion would be appropriate). I too struggled with understanding the reason for needing this allocate, but realized that I needed it to get the code to run.