Implementing FTorch on CESM/derecho

[jatkinson1000]

In discussion with Will Chapman at NCAR

CISL are adding libtorch and

Jack has forked CESM and CISL to DataWave and will work on implementing FTorch coupling there.

[jatkinson1000]

gw_drag.F90 - ll. 1471

This line calculates the source spectrum: https://github.com/DataWaveProject/CAM/blob/eaba9ff4ba60d036c4e89a07b4bd26db896a1ad7/src/physics/cam/gw_drag.F90#L1479

This line calculates the drag: https://github.com/DataWaveProject/CAM/blob/eaba9ff4ba60d036c4e89a07b4bd26db896a1ad7/src/physics/cam/gw_drag.F90#L1484

utgw and vtgw are the diagnostics that are generated by the ML scheme. We will be looking to replace the entire call to gw_drag_prof with the ML scheme

ttgw and egwdffi are not calculated by the ML scheme.\ They are negligible in Mid-Top CAM in the mesosphere (but not WACCM) - JA JA has code that could be used to calculate these

ll. 1508 1509 are no longer needed, but we can either neglect, or JA has got an analytical expression that can replace it.

ll. ~1458~ 1484 - 1509 will be replaced by the NN However - Keep in the call to gw_beres_src for now.

This is 'hypothetical' description, as in reality we will keep the current parameterisation for comparisons.

[jatkinson1000]

For future code/nets (orography, fronts) the same function gw_drag_prof will be called.

So the implementation we write will need a switch that says e.g. 'Use net_1_conv, net_2_oro, or net_3_front' with a single wrapper function.

Some challenge may come if inputs are different for each scheme, so we may need 'optional' inputs for certain arrays.

[jatkinson1000]

Update: Working with Will Chapman at NCAR we have got an ICCS fork of CIME that will link to libtorch through FTorch (built locally) and can run simple FTorch operations (tensor creation, simple model creation, forward inference) from within CESM.

Next steps are to try and bring

[jatkinson1000]

Instructions to build with this fork of CIME are part of #5

[jatkinson1000]

It would make sense to modify gw_drag.f90 as above to change the version of gw_drag_prof we call based on the switch set in the namelist.

However, our parameterisation should be in a separate file with:

• [ ] Initialisation (read in the net from file and store as an FTorch model)
  • Before or after CESM scattering...?\ I think probably after as we are dealing with pointers?
  • Try to make this a generic function for all future GW-schemes (orography, frontogenesis, etc.) - i.e. take ftorch model as an input argument and avoid using module variables.\ Alternative would be to have new functions every time we add a new GW model which is not in the zeitgeist of the current way GWs work in CAM.
  • [ ] Need to call this from the main routine somewhere.\ I suggest gw_init in gw_drag.F90 for consistency with CAM behaviour.
• [ ] Destruction
  • Same comments as above
• [ ] A modified version of gw_drag_prof() to be called from gw_drag.F90
  • Design of this depends on whether the NN is a generic replacement for gw_drag_prof(), or specifically tuned to the deep convection process. If the latter we need to be more careful about splitting up the code.