Wrap surface scheme to be called independently

[mcgibbon]

In the final model, we want to have a main loop that:

1. Perform a dynamics step
2. Perform a surface step, computing any surface model outputs
3. Perform a physics step a. Finish the GFS physics step, picking up after the surface step, to compute its outputs b. Run the ML model using inputs from the surface model and the rest of the state to compute the residual tendency.
4. Update the GFS physics-stepped state with the ML residual tendency.

Lines 1015 to 1212 of GFS_physics_driver.F90, and possibly some of the code below it, needs to be wrapped so it can be called independently from Python. This code calls routines stored in the FV3/gfsphysics/physics directory.

In the longer run, they will likely also need to be separated out of this driver routine, so that we can call the remainder of the physics separately when running prognostically. Lucas mentioned ongoing efforts to separate the land models, so we should look out for overlap there. This separation would not need to be done for a full-tendency ML model, only for a residual model.

[nbren12]

Wrap NOAH land surface model.

[nbren12]

@spencerkclark Do you have any idea what land surface model SHIELD uses? There is a lot of GFS specific code in this part of the model, so it could be quite different from GFDLs workflow. It may not be worth separately wrapping the FV3GFS LSM if it is significantly different from the target model we are trying to improve.

[nbren12]

Unfortunately, there is no clean interface between the surface schemes and the rest of the gfs physics routines. For instance, the evaporation array evap is modified by many of the surface functions and then used by around 10 different physical parameterizations later in the same GFS_physics_driver subroutine. Before we wrap the surface schemes we should probably refactor this code to at least another subroutine so we at least understand what the inputs and outputs of this whole mess are. After that, it would be simple to write a Cython wrapper.

@ofuhrer Do you have any ideas about how to write a regression test we can use for this refactoring? I guess we could just run the whole model and look for byte/byte changes in the outputs.

As an aside, this is one advantage of the "Fortran calls python" approach, which would not require refactoring the original source beyond adding a namelist option for turning off all the physical parameterizations.

[nbren12]

Overall, I think we should probably add regression tests demanding that the cython wrapper produces identical outputs to the original Fortran model.

[spencerkclark]

@spencerkclark Do you have any idea what land surface model SHIELD uses?

I checked with Lucas and he says that SHiELD uses the same version and configuration of the Noah LSM that is in the publicly released FV3GFS.

+1 for refactoring and regression testing. It would indeed be nice to make this portion of the codebase more understandable.

[nbren12]

It would indeed be nice to make this portion of the codebase more understandable.

Haha. I think almost any change will help with this.

[mcgibbon]

Unfortunately, there is no clean interface between the surface schemes and the rest of the gfs physics routines. For instance, the evaporation array evap is modified by many of the surface functions and then used by around 10 different physical parameterizations later in the same GFS_physics_driver subroutine. Before we wrap the surface schemes we should probably refactor this code to at least another subroutine so we at least understand what the inputs and outputs of this whole mess are. After that, it would be simple to write a Cython wrapper.

Yes, my sense is that it's very possible and useful to figure out where to draw the line and do that.