Jack's ZM_MCSP modifications

[KaiHuang94]

Add the optional MCSP to CAM7. It is turned off by default.
Closes #1474 issue.

[adamrher]

@KaiHuang94 thanks for bringing this in. I have two high level requests. There needs to be a way to shut off the mcsp in zm_conv_intr so that you're not calling the init phase and run phase (zm_conv_mcsp_tend) even if all the do_mcsp_x flags are false.

The second request is to help us understand what this PR has to do with SCREAM. We certainly don't want these IFDEF SCREAM lines in the CAM code base, as SCREAM will not be pulling from the CAM code base. It's probably fine to have small things like order of operation changes to make the porting to SCREAM easier. We'll probably need to take these decisions to accommodate SCREAM on a case by case basis.

Also, a more naive question -- is the Fortran version of SCREAM going to be deprecated in favor of the Kokos C++ version, and therefore anything done here to accommodate SCREAM is unnecessary?

[adamrher]

Adding on a third high level point -- I'm not sure it's wise to put the MCSP driver in CAM. It should be CCPP'ized and brought into https://github.com/ESCOMP/atmospheric_physics/tree/main/schemes/zhang_mcfarlane. If that can't be done at this stage due to time constraints, we need a plan for eventually bringing it into atmospheric physics, since CAM will eventually be sunset once CAM-SIMA has all the necessary functionality.

[PeterHjortLauritzen]

Thank you @KaiHuang94 for submitting the PR.

Minor "cosmetic" code request; please remove identifier comments in the code like :

!KH:++++++++++++++++
!KH:----------------------------
!++ MCSP
!-- MCSP

(in addition to the #ifdef's)

[chihchen24]

@KaiHuang94 thanks for bringing this in. I have two high level requests. There needs to be a way to shut off the mcsp in zm_conv_intr so that you're not calling the init phase and run phase (zm_conv_mcsp_tend) even if all the do_mcsp_x flags are false.

The second request is to help us understand what this PR has to do with SCREAM. We certainly don't want these IFDEF SCREAM lines in the CAM code base, as SCREAM will not be pulling from the CAM code base. It's probably fine to have small things like order of operation changes to make the porting to SCREAM easier. We'll probably need to take these decisions to accommodate SCREAM on a case by case basis.

Also, a more naive question -- is the Fortran version of SCREAM going to be deprecated in favor of the Kokos C++ version, and therefore anything done here to accommodate SCREAM is unnecessary?

@KaiHuang94 thanks for bringing this in. I have two high level requests. There needs to be a way to shut off the mcsp in zm_conv_intr so that you're not calling the init phase and run phase (zm_conv_mcsp_tend) even if all the do_mcsp_x flags are false.

The second request is to help us understand what this PR has to do with SCREAM. We certainly don't want these IFDEF SCREAM lines in the CAM code base, as SCREAM will not be pulling from the CAM code base. It's probably fine to have small things like order of operation changes to make the porting to SCREAM easier. We'll probably need to take these decisions to accommodate SCREAM on a case by case basis.

Also, a more naive question -- is the Fortran version of SCREAM going to be deprecated in favor of the Kokos C++ version, and therefore anything done here to accommodate SCREAM is unnecessary?

1. C++ code for SCREAM can be removed.

2. in zm_conv_mcsp_tend, we can add an if statement, i.e. if all four mcsp coefficients are zero, then skip the entire calculations.

[KaiHuang94]

@KaiHuang94 thanks for bringing this in. I have two high level requests. There needs to be a way to shut off the mcsp in zm_conv_intr so that you're not calling the init phase and run phase (zm_conv_mcsp_tend) even if all the do_mcsp_x flags are false.
The second request is to help us understand what this PR has to do with SCREAM. We certainly don't want these IFDEF SCREAM lines in the CAM code base, as SCREAM will not be pulling from the CAM code base. It's probably fine to have small things like order of operation changes to make the porting to SCREAM easier. We'll probably need to take these decisions to accommodate SCREAM on a case by case basis.
Also, a more naive question -- is the Fortran version of SCREAM going to be deprecated in favor of the Kokos C++ version, and therefore anything done here to accommodate SCREAM is unnecessary?

@KaiHuang94 thanks for bringing this in. I have two high level requests. There needs to be a way to shut off the mcsp in zm_conv_intr so that you're not calling the init phase and run phase (zm_conv_mcsp_tend) even if all the do_mcsp_x flags are false.
The second request is to help us understand what this PR has to do with SCREAM. We certainly don't want these IFDEF SCREAM lines in the CAM code base, as SCREAM will not be pulling from the CAM code base. It's probably fine to have small things like order of operation changes to make the porting to SCREAM easier. We'll probably need to take these decisions to accommodate SCREAM on a case by case basis.
Also, a more naive question -- is the Fortran version of SCREAM going to be deprecated in favor of the Kokos C++ version, and therefore anything done here to accommodate SCREAM is unnecessary?

1. C++ code for SCREAM can be removed.
2. in zm_conv_mcsp_tend, we can add an if statement, i.e. if all four mcsp coefficients are zero, then skip the entire calculations.

@adamrher @PeterHjortLauritzen @chihchen24 The modifications according to the above suggestions were done and have passed two test runs with MCSP turned on and turned off by default. Please see the updated version for details.