search

m2lines / convection-parameterization-in-CAM

Deployment of the convection parameterization scheme (previously from within SAM) deployed into the CAM model
MIT License
3 stars 2 forks source link

Refine parameterisation and add CAM interface #44

Closed jatkinson1000 closed 3 months ago

jatkinson1000 commented 1 year ago

This PR seeks to add an interface to the code parameterisation for the CAM model (part of CESM).

To do so we need to:

The above points will be expanded as we work through this PR.

May address #18

  1. Regridding by averaging over the overlapping parts of grid cells to improve conservation.

  2. Lines 30-158 in cloud.f90 convert q and t from SAM into temperature tabs and cloud liquid + cloud ice qn. Note that cloud.f90 allows for qp being non-zero, but qp is zero in the parameterisation.
    Calculate water vapor as qv = q - qn.
    Convert qn into cloud liquid qcc and cloud ice qii using code in statistics.f90.
    Convert changes in qv, qcc and qii to tendencies ptend%q(:,:,1), ptend%q(:,:,ixcldliq) and ptend%q(:,:,ixcldice) by dividing by the timestep dtn.

  3. Use q and t converted to tabs as above in [1.], then calculate change in temperature and convert to dry static energy tendency by multiplying by cp and dividing by the dtn.

jatkinson1000 commented 1 year ago

Extracted SAM sounding file and written script to convert to netCDF.

Questions for meeting:

paogorman commented 1 year ago
  • altitude in pressure and density soundings are different, is this correct or is one canonical? grd and pressure seem to match.

Yes, the altitude in the pressure sounding file is correct (the density sounding file has the same z but it is rounded).

  • Do we want to flip the data so altitude in ascending order?

Yes, the data should be flipped.

Yes, that is the right z file. @jatkinson1000 I said in the meeting that you should just use the z in the pressure file, but it would be clearer to use the 'grd' file given that we then don't need the pressure file as discussed below.

With regard to the pressure file: this provides tabs0 and pres0 which are initial temperatures and pressure profiles. We don't use these in nn_convection_flux.f90. So I don't think we need the pressure file as long as we use the grd file to get z. (edit: as pointed out below, we do need the pressures for use in interpolation)

nn_convection_flux.f90 does use pres in a part of the code controlled by rf_uses_rh. But pres is the current pressure and not the initial pressure. Therefore, if we wanted to implement the rf_uses_rh option, it would have to happen in the SAM-CAM interface using the actual pressure from CAM. My advice is to just remove the rf_uses_rh option ( and it looks like you already removed it!)

jatkinson1000 commented 1 year ago

Thanks @paogorman, these should now be implemented in the latest commit (bumped script to v1.1).

jatkinson1000 commented 1 year ago

Added routines to read sounding variables in from NetCDF to CAM interface. Note: The sounding has more levels (48) than are required by the parameterisation (nrf = 30). For now I read in the entire sounding as the parameterisation selects only the lowest nrf cells. Users should be aware in the future to keep things consistent if developing a new NN from a new grid configuration. I think this follows the element of least surprise as all that is required is to change nrf in the code and regenerate SAM_sounding.nc using the included tool from the appropriate simulation files.

jatkinson1000 commented 1 year ago

Interpolation

@paogorman:

paogorman commented 1 year ago
  • I will look at generating a presi variable, but this would require the input files used in the runs that generated the NN. Could this be done running SAMSON with the following as a 'case': SAMSON_NN/rf_production?

I'm not sure which run this was, but any of the runs we did in this line of work should work as long as it is a cold start (because we want to get the initial profiles). I've attached a sounding from one of the cold-start runs I did:

sounding_z_pres0_presi0_tabs0.txt

I think you can just use this file. But it would be good to confirm it is consistent with the previous sounding file and the relation of presi and pres in pressz.f90.

  • Do you know which variables are stored at cell centres and which at cell edges in SAM and CAM? I believe both are Arakawa-C, so presumably scalars (and hence everything we use) are at cell centres?

For SAM, yes static energy (t), moisture and tendencies are at the mid levels (i.e. cell centres). The fluxes are at the interfaces, but you are not interpolating those in the current approach.

For CAM I don't think it should be tied to Arakawa C in particular since CAM has a few different dynamical cores. The figure in this documentation suggests T and q are at midlevels: https://ncar.github.io/CAM/doc/build/html/cam6_scientific_guide/dynamics.html#generalized-terrain-following-vertical-coordinates It would be good to double check this yourself or with Judith.

  • For surface pressure is there a specific value that provides this, or do you mean the bottom element of the column pressure? And is the bottom cell centre sufficcient, or does it need to be the boundary value (i.e. presi(1) not pres(1))?

For SAM I would use the bottom element of presi.

For CAM, I think you could use the bottom element of pint or the ps element of phys_state which presumably should be the same. It would be good to check they are the same.

  • I'm still exploring the CAM code, but do you know the array structure of the CAM variables? Your document says e.g. state%q(:,:,1), but should this be state%q(:,:,k,1) - i.e. a lat, lon, alt/pres grid/indexing system?

The arrays in physpkg have already been reshaped to only have a column index instead of separate lat/lon indices (this was done in dp_coupling.f90 which comes in different forms for the different CAM dynamical cores). That was the reason we needed our interface to accept both 2d or 3d arrays so it worked for both cam and sam.

  • You say in the above comment that we no longer need pres0, but do we not require it to do the interpolation, unless I misunderstand? If so I'll write it back in.

Yes, you're right! I'd forgotten why we needed pres0.

paogorman commented 1 year ago

A couple of other resources:

1) A guide to coupling a column physics parameterization to CAM: cam_physics_interface_guide.pdf I think this is well worth reading even if it is a bit older.

2) Parts of what we are trying to do here in terms of coupling SAM to CAM was previously done in the spcam part of cesm: my_cesm_sandbox/components/cam/src/physics/spcam/crm_physics.F90 my_cesm_sandbox/components/cam/src/physics/spcam/crm/crmx_crm_module.F90 It is good to be aware of this, but spcam is implemented in a sufficiently different way to what is needed for the NN scheme that I'm not sure how useful it will be in the end.

jatkinson1000 commented 1 year ago

Updated sounding code to read in pres and presi for interpolation. Normalised SAM pres by presi(1) for $\sigma$ coordinate.

Need to know the details of CAM pressure (and other variables) before we can properly look at doing an interpolation - this should be addressed in discussions with Judith/Wayne on Friday.

@paogorman Thanks for the replies - the physics guide is very useful, and what I had been struggling to find! Just to be absolutely clear on CAM array shapes: state%q(i,j,1) implies the first q-state in column i and a pressure level of j. Is that correct? Hopefully this will become explicitly clear after discussing CAM/CESM with Judith/Wayne on Friday.

paogorman commented 1 year ago

Just to be absolutely clear on CAM array shapes: state%q(i,j,1) implies the first q-state in column i and a pressure level of j. Is that correct?

Yes, that's right. Btw, I believe "1" here refers to water vapor. The q array also contains cloud ice and liquid.

jatkinson1000 commented 1 year ago

Paul remarks - for regridding set tendencies on the CAM grid for anything above the SAM grid to 0.0

jatkinson1000 commented 1 year ago

Questions:

paogorman commented 1 year ago

-It's easy to flatten arrays (reshape), but not to add an axis (allocate). Therefore adjust the NN to work on 2D data and refactor SAM interface to flatten inputs?

I think that is ok if necessary. (Could it be avoided using a pointer?) Using 2D arrays will probably slow down the NN parameterization when running in SAM, but perhaps that's not a large penalty.

-Can we do away with tabs_i and q_i as inputs and make them the same as t and q for CAM?

We should keep them so that we can run the same NN parameterization in SAM, but they can be set equal to t and q in the CAM specific interface to the neural net parameterization.

-Do we need to zero precipitation in the routine (based on nstatis in SAM)? Or is CAM handling this for us in physbc?

This bit of code is not needed for CAM and would not make sense (there is no nstatis in CAM). But the code would be needed for running the parameterization in SAM. So I suggest we remove it and later add a lightweight interface for running in SAM that takes care of this.

-should dtn be set to the CAM physics timestep (for now, do we anticipate subcycling the routine later at all?)?

Again it is fine to set dtn to dt for CAM, but dtn should be kept for when running in SAM to avoid confusion. Yes, there is a good chance we will need subcycling in CAM.

jatkinson1000 commented 1 year ago

Thanks @paogorman , these were notes to myself for tomorrow but already answered! As such I'll qualify - I wasn't suggesting we remove anything from the core routines, but was asking in terms of the CAM interface. So setting tabs_i and q_i as a copy of tabs and q is good, nstatis I will make a dummy in terms of the CAM interfacing, and dtn is set to the CAM physics timestep, with the possibility of subcycling in the interface being added at a later point. A follow up question/discussion for tomorrow would be about the treatment of precipitation in CAM.

jatkinson1000 commented 1 year ago

For precipitation follow what ZM is doing. Create a variable yog_precip (and yog_snow = 0.0) We may need to interface this with a land model at a later date, but worry about this down the line.

paogorman commented 1 year ago

To follow cam convention, I think these would be precip_yog, snow_yog

jatkinson1000 commented 12 months ago

Calculation of tabs, qn, and qv from SAM t and q implemented (testing required). Questions around use of if(domicroscaling) and assumption that qp == 0.0.

Next steps are to:

CAM interfacing is ongoing:

dorchard commented 11 months ago

We will bring the cp (specific heat of dry air) value from SAM (it does exist in some other places in CAM but not readily available to us at this point, not also that cp tends to refer to moist air in CAM I noticed).

jatkinson1000 commented 11 months ago

Latest commits allow conversion from SAM t, and q into tabs, qv, qc, qi. This allows conversion of the NN outputs into the form wanted by CAM provided we:

Ongoing:

Tests:

jatkinson1000 commented 10 months ago

The code has now been modified to work for CESM v2.1.5 on Derecho (seems to have successfully run for 4 iterations) with instructions in the CAM_mods README.

Continuing now with integration into CAM in terms of passing through variables, and implementing some tests/checks on the variable conversion and re-gridding routines.

jatkinson1000 commented 10 months ago

We want to run the ZM scheme to generate ZM tendencies as outputs, even when using YOG as the deep convection scheme.

Need to be careful about doing this in a way that allows calling convect_deep_tend before/after convect_deep_tend_yog but without 'double operating' on any variables. May require creating copies, or, more likely, returning copies, or, if lucky, nothing.

jatkinson1000 commented 9 months ago

For records and own clarity the interface process is as follows:

@paogorman order of interpolation/variable conversion steps could be swapped, but this seems to me to be the most sensible order that is likely to minimise numerical error, do you agree?

@paogorman To update t we need to formulate some form of t at the start of the timestep from CAM data. I think we discussed this, but can't see it in my notes above. Did we say using cp*tabs or s do you recall?

paogorman commented 9 months ago
  • [ ] t, tabs, and q_i out of CAM

Should this be 'tabs', 'q_v', 'q_c', 'q_i'? (where tabs means absolute temperature which is state%t(:,:) in CAM. See below for how (SAM) t is calculated.

@paogorman order of interpolation/variable conversion steps could be swapped, but this seems to me to be the most sensible order that is likely to minimise numerical error, do you agree?

With the proposed order, you are first interpolating SAM variables from cam to sam grid, and then interpolating CAM variables from sam to cam grid. I would have thought it would be better to do the interpolation on the sam variables both times (so switch the order).

@paogorman To update t we need to formulate some form of t at the start of the timestep from CAM data. I think we discussed this, but can't see it in my notes above. Did we say using cp*tabs or s do you recall?

You could calculate t (meaning liquid-ice static energy /cp) based on line 479 of diagnose.f90 in the SAMson code:

omn  = max(0.,min(1.,(tabs(i,j,k)-tbgmin)*a_bg))
 omp  = max(0.,min(1.,(tabs(i,j,k)-tprmin)*a_pr))
tabs(i,j,k) = t(i,j,k)-gamaz(k)+ &
          (fac_cond+(1.-omn)*fac_fus)*qn(i,j,k)

Note this is written as an expression for tabs but you can just move things around to get an expression for t. Note I set qp to zero because we are not using qp. Note that qn is sum of cloud water + cloud ice which is available from CAM.

jatkinson1000 commented 9 months ago

Thanks @paogorman

Yes, in my mind _i was a subscript where i is one of i, c, v - I should have clarified this given 'i is one of i'.

My thoughts were that it would be better to convert variables on their 'native' grid before interpolating. Interpolating first could introduce noise that would then be amplified by a conversion? Happy to do either - it probably doesn't matter too much, and the conversion/interpolation procedures are generic subroutines, so it should be easy enough to swap them.

Thanks for the reference to diagnose.f90 - that's what I was missing!

paogorman commented 9 months ago

Yes, that was a good question about how to calculate t. It is not something that is done in SAMson except for the initialization, but there is no cloud at that point. Fortunately I think you can use the code from diagnose.f90.

Regarding the interpolation/conversion order: I would first try the interpolation on the SAM variables both times for consistency. Being consistent is important because (to the extent possible) we want the case with no change in SAM variables from the ML routine to give no change in CAM variables. That makes me wonder if our interpolation will be reversible in this sense - probably not.

jatkinson1000 commented 9 months ago

Regarding variable interpolation, whilst writing tests I realise that, particularly for SAM -> CAM conversion it makes sense to operate on the SAM gridded data as discussed above. This is because we make use of certain values defined on the SAM grid (e.g. gamaz(k)) which would need to be interpolated should we use a different grid.

jatkinson1000 commented 9 months ago

Meeting 14/02/2024

Testing variable conversion discussed with @paogorman:

Q - Is bottom interface pressure equal to surface pressure?

@judithberner asked Julio who replied

PSL is 'sea-level pressure'. It is equal to PS over ocean, but is extrapolated over land. The PINT variable is the pressure at layer interfaces. So, the bottom level of PINT is equal to PS (should be). Just FYI there are two more pressure variables - PMID and DELP - the mid-layer pressure and pressure change across the layers respectively. PINT,PMID and DELP were introduced when the vertical coordinate was switched to a 'dry mass' coordinate - i.e. water mass not included.

So it would seem pint(1) is the sensible choice for "surface pressure". Can always check the CAM output to be sure.

Making progress with FTorch with Will and CISL - they will install a binary of libtorch compatible with cuda 11.8 or 12.1 on the stack. Apparently is no spack build for libtorch.

jatkinson1000 commented 9 months ago

@paogorman In the notes above I wrote that we normalise pressure to create a $\sigma$ coordinate by dividing by the pressures of each grid by their respective surface values.

However, I was wondering, would it make sense to use the same surface pressure value to normalise both grids, as otherwise we are misaligning the grids in 'unnormalised'/absolute space?

I can see an argument the other way, saying that SAM is only a reference and that normalised surface pressure should have $\sigma = 1.0$ in both models, and there is a danger that we end up with a value of $\sigma < 1.0$ at the surface.\ I suppose ideally one might train the NN model with $\sigma$ rather than p?

paogorman commented 9 months ago

We want to use the respective surface pressures to capture the influence of the lower boundary. But note this NN was only trained over ocean. In the longer run we will want to switch to Griffin’s NN which was trained on sigma coords and over land (it just needs a bit more testing in sam which Griffin is working on).

On Tue, Feb 20, 2024 at 12:20 PM jatkinson1000 @.***> wrote:

@paogorman https://github.com/paogorman In the notes above I wrote that we normalise pressure to create a $\sigma$ coordinate by dividing by the pressures of each grid by their respective surface values.

However, I was wondering, would it make sense to use the same surface pressure value to normalise both grids, as otherwise we are misaligning the grids in 'unnormalised'/absolute space?

I can see an argument the other way, saying that SAM is only a reference and that normalised surface pressure should have $\sigma = 1.0$ in both models, and there is a danger that we end up with a value of $\sigma < 1.0$ at the surface. I suppose ideally one might train the NN model with $\sigma$ rather than p?

— Reply to this email directly, view it on GitHub https://github.com/m2lines/convection-parameterization-in-CAM/pull/44#issuecomment-1954686219, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARPLW62EZOA32PYIAJ5JGR3YUTLNLAVCNFSM6AAAAAA3J2SIOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUGY4DMMRRHE . You are receiving this because you were mentioned.Message ID: @.*** com>

jatkinson1000 commented 8 months ago

Comments from discussion on 1/3/24:

dorchard commented 8 months ago

(sorry I don't know where my comment went on this before) we thought it might make sense to call the flag YOGCOMP at the moment from the beginning as it is running both YOG and ZM now (and later we can add the separate YOG flag for running it in isolation).

jatkinson1000 commented 8 months ago

@paogorman Is a reasonable surface boundary condition for qv, qc, and qi 0.0? Alternatively I could set equal to the bottom cell value or extrapolate to surface? This is required for interpolation to the SAM grid.

Another question - I have implemented the calculation of tendencies on the SAM grid before interpolation back to the CAM grid (see lines 189-213 here) In theory there should be no difference, but as ever in numerical practice there will be. My reasoning was that it is easier to implement interpolation at the top of the SAM grid for tendencies rather than variables, and that the SAM grid is likely to be finer meaning more detail will be retained doing the calculation here.

jatkinson1000 commented 8 months ago

@paogorman comments - Skin temperature is not ideal in all settings, so perhaps linear extrapolation? For both tabs and q. Note we'd expect qc to be low anyway. But, as for the convection scheme, we should ensure q >= 0.

On tendencies the conservative regridding is a linear operation so we can hope that the methods are reversible 'in-practice'. :fingers crossed:

dorchard commented 8 months ago

(To be clear: linear extrapolation downward for qv)

paogorman commented 8 months ago

Yes, linear extrapolation down for all variables.

On Wed, Mar 20, 2024 at 12:53 PM Dominic Orchard @.***> wrote:

(To be clear: linear extrapolation downward for qv)

— Reply to this email directly, view it on GitHub https://github.com/m2lines/convection-parameterization-in-CAM/pull/44#issuecomment-2010047652, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARPLW672BN77WCPCLJ3PDRDYZG5GZAVCNFSM6AAAAAA3J2SIOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGA2DONRVGI . You are receiving this because you were mentioned.Message ID: @.*** com>

jatkinson1000 commented 8 months ago

Yes, by 'q' I mean all q - qv, qc, and qi, as discussed 😄

dorchard commented 6 months ago

Re the simplification that we applied to these lines: https://github.com/m2lines/Neural_nework_parameterization/blob/f81f5f695297888f0bd1e0e61524590b4566bf03/sam_code_NN/nn_convection_flux.f90#L439-L442 removing the factors dz * ... * 1/dz

There was however a suggestion we still need to have an additional factor of 1/dz in application of the sedimenting flux at the surface. This was discussed before but there was a potential miscommunication of dz heard as adz.

However, it should be noted that the calculating of surface precipitation in our updated code does include the 1/dz factor https://github.com/m2lines/convection-parameterization-in-CAM/blob/cam-profile-test/NN_module/nn_convection_flux.f90#L434-L436 @paogorman - is this where you were thinking it should go? Are you advocating for a further 1/dz factor? We may need to the check the dimensional analysis on this...

paogorman commented 6 months ago

There seems to be two problems with the precipitation:

1) Only the precipitation from cloud sedimentation is currently included (and this is a very small part of the total). The code is missing the equivalent of the following lines from Janni's nn_convection_flux routine which add in the much bigger contribution from 'autoconversion':

do k=1, nrf precsfc(i,j) = precsfc(i,j)-q_tend_tot(k)adz(k)dzrho(k)(1/dz)! removed the time step mult because q_tend_tot is already mult end do

2) Both of the updates to prec (from sedimentation and autoconversion) need to be multiplied by dz relative to what Janni's code does. This is because the precsfc variable is later multiplied by dz elsewhere in the SAM code prior to outputting statistics. See these lines in statistics.f90 and note the dz factor:

do j=1,ny do i=1,nx precsfc(i,j)=precsfc(i,j)dz/dt3600./(nstatis+1.e-5) end do end do

On Wed, May 1, 2024 at 10:53 AM Dominic Orchard @.***> wrote:

Re the simplification that we applied to these lines:

https://github.com/m2lines/Neural_nework_parameterization/blob/f81f5f695297888f0bd1e0e61524590b4566bf03/sam_code_NN/nn_convection_flux.f90#L439-L442 removing the factors dz ... 1/dz

There was however a suggestion we still need to have an additional factor of 1/dz in application of the sedimenting flux at the surface. This was discussed before but there was a potential miscommunication of dz heard as adz.

However, it should be noted that the calculating of surface precipitation in our updated code does include the 1/dz factor

https://github.com/m2lines/convection-parameterization-in-CAM/blob/cam-profile-test/NN_module/nn_convection_flux.f90#L434-L436 @paogorman https://github.com/paogorman - is this where you were thinking it should go? Are you advocating for a further 1/dz factor? We may need to the check the dimensional analysis on this...

— Reply to this email directly, view it on GitHub https://github.com/m2lines/convection-parameterization-in-CAM/pull/44#issuecomment-2088581713, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARPLW66DKBAGYSPBAX2ZD7DZAD6U5AVCNFSM6AAAAAA3J2SIOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGU4DCNZRGM . You are receiving this because you were mentioned.Message ID: @.*** com>

jatkinson1000 commented 6 months ago

@dorchard @paogorman

RE 1) On the standalone testing that we have been looking at over the last fortnight the precipitation includes both sedimentation and autoconversion, see:

https://github.com/m2lines/convection-parameterization-in-CAM/blob/5de9f0272cf070176ed812350f4eccae71178ab1/profile_test/nn_convection_flux.f90#L376-L383

My intention is to propagate the updates we have made there (and in CAM) back here once we are happy.

RE 2) That helps understand, thank you. I'll make this change now, and make sure it is commented in the source to explain.

paogorman commented 6 months ago

There may be a problem in the code you just linked to:

precsfc(i) = precsfc(i) - q_sed_flux(1) irhoadzdz(1) rho(k) adz(k) !! dtn/dz

rho(k) should be rho(1)? adz(k) should adz(1)?

On Fri, May 3, 2024 at 10:35 AM jatkinson1000 @.***> wrote:

@dorchard https://github.com/dorchard @paogorman https://github.com/paogorman

RE 1) On the standalone testing that we have been looking at over the last fortnight the precipitation includes both sedimentation and autoconversion, see:

https://github.com/m2lines/convection-parameterization-in-CAM/blob/5de9f0272cf070176ed812350f4eccae71178ab1/profile_test/nn_convection_flux.f90#L376-L383

My intention is to propagate the updates we have made there (and in CAM) back here once we are happy.

RE 2) That helps understand, thank you. I'll make this change now, and make sure it is commented in the source to explain.

— Reply to this email directly, view it on GitHub https://github.com/m2lines/convection-parameterization-in-CAM/pull/44#issuecomment-2093150018, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARPLW6ZE5BIETUOR5E44R4DZAOOD3AVCNFSM6AAAAAA3J2SIOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGE2TAMBRHA . You are receiving this because you were mentioned.Message ID: @.*** com>

jatkinson1000 commented 6 months ago

Ah, they are in my code! Just realised this is something I had caught last week but hadn't pushed yet.

That, plus the factor of dz is now added here:

https://github.com/m2lines/convection-parameterization-in-CAM/blob/faddb565cb80e0cf878835446913a6e51f23e39b/profile_test/nn_convection_flux.f90#L376-L384

paogorman commented 6 months ago

Looks good

On Fri, May 3, 2024 at 10:56 AM jatkinson1000 @.***> wrote:

Ah, they are in my code! Just realised this is something I had caught last week but hadn't pushed yet.

That, plus the factor of dz is now added here:

https://github.com/m2lines/convection-parameterization-in-CAM/blob/cam-profile-test/profile_test/nn_convection_flux.f90#L376-L384

— Reply to this email directly, view it on GitHub https://github.com/m2lines/convection-parameterization-in-CAM/pull/44#issuecomment-2093188901, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARPLW64L3LP2RKS6GLVBJYTZAOQTHAVCNFSM6AAAAAA3J2SIOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGE4DQOJQGE . You are receiving this because you were mentioned.Message ID: @.*** com>

jatkinson1000 commented 3 months ago

I have just made commits https://github.com/m2lines/convection-parameterization-in-CAM/pull/44/commits/399612b1f5eb6cdbb5c20765907965f0ffdea33f and https://github.com/m2lines/convection-parameterization-in-CAM/pull/44/commits/0e8f6fc026c482f42c2b13bf194d31cfc750188e which bring the code in-line with the current implementation used within CAM.

For full details see the commit messages.

This also updates the testing routines.

Suggestion is that this is merged to be consistent with CAM (after a couple of further points below) so that Adeleke can work on writing tests for regridding and any further work can be done in more manageable chunks.

MarionBWeinzierl commented 3 months ago

Should this PR be changed to "ready for review"?