[NDSL] GF convection port (GF2020)

[FlorianDeconinck]

Located at GEOS_GF_InterfaceMod.F90:GF_Run, two main subroutines.

Use GEOS-FP to determine which one to port and GMAO expertise. Everything under Run should be considered for port. GF_2020 should be the one we run, since the GEOS5 is the older one.

Parent: GEOS-ESM/SMT-Nebulae#57

---

• Port GF to pyMoist

---

Breakdown:

*GF2020_Interface *

• alloc_grads_arr
• set_index_loops
• flipz
• get_vars
• GF2020_DRV
  • prepare_temp_pertubations
     - CUP_gf (Note this is not the same as CUP_gf from GEOS5)
    • gen_random
        - system_clock
    • cup_env
      • satur_spec_hum
    • SOUND
        - cup_env_clev
    • get_interp
    • get_partition_liq_ice
      • fract_liq_f
        • ice_fraction -> ICE_FRACTION_SC
    • precip_cwv_factor
        - get_cloud_bc
        - get_lcl
         - satvap
         - td
    • cup_cloud_limits
        - cup_minimi
        - rates_up_pdf
        - get_zu_zd_pdf
         - gammaBrams
          - intfuncgamma
        - get_lateral_massflux
        - get_buoyancy
        - cup_up_moisture_light
        - cup_up_vvel
        - cup_up_moisture
         - get_delmix
         - fract_liq_f
          - ice_fraction
         - get_melting_profile
         - get_delmix
         - get_jmin
         - get_lateral_massflux_down
         - get_wetbulb
         - cup_dd_moisture
         - cup_up_aa0
         - cup_up_aa1bl
         - cup_dd_edt
         - tridiag
         - fct1d3
         - cup_forcing_ens_3d
         - cup_forcing_ens_3d_mid
         - cup_up_cape
         - cup_forcing_ens_3d_shal
         - ke_to_heating
         - cup_output_ens_3d
         - get_precip_fluxes
         - rain_evap_below_cloudbase
         - cloud_dissipation
         - cup_up_lightning
         - get_liq_ice_number_conc
          - make_IceNumber
          - make_DropletNumber
         - cup_env_clev_chem
          - get_w_upd_gcc
         - get_incloud_sc_chem_up
          - henry_gcc
          - henry
          - compute_ki_gcc_gas
      - gcc_e_ice
         - get_incloud_sc_chem_dd
         - set_grads_var
         - wrt_bin_ctl
• MAPL_EQsat -> QSAT0 (Found under src/Shared/@MAPL/base/MAPL_SatVapor.F90)

Note: I think there're recursive calls possible within QSAT0

[FlorianDeconinck]

Main difficulty is the K-axis flip and axis re-shuffling (from I, J, K) to (K, I, J).

De-flipping the K is going to be a headache. Whereas axis re-shuffle can be a utility made for all GF translate test

[CharlesKrop]

Progress has been made building the interface. Current design aims to bring data form the fortran-to-python bridge and deposit it at the point where fortran calls cumulus parameterization (ConvPar_GF2020.F90, line 1413). Everything before this point seems to be data management/reshaping/computing various input parameters for the cumulus parameterization, so this has all been constructed in a driver_setup stencil. During construction, the flipped k-axis was eliminated and a few variables were renamed (mostly due to the elimination of unnecessary temporaries, but occasionally for clarity). Further work here may eliminate a few more temporaries, but most of the remaining ones will be necessary.

A GF2020_flags placeholder class exists to mimic the flags that need to be brought from the fortran during the initialization of the stencil.

Next step is to create the cumulus parameterization. There is a small amount of code that needs to be considered outside of the fortran CUP_gf call (lines 1416-1485), and then the entire CUP_gf call must be considered. All code after the CUP_gf call looks to be more data manipulation/reshaping and can be considered separately from the actual parameterization scheme. Use caution when considering the k-axis, most (but not all) variables were flipped, so some will remain unchanged.

Beyond the flipped k-axis, the cumulus parameterization seems fairly straightforward. There are a lot of offset reads, and at least one offset write (but I don't know if it actually executes yet), so it will likely have to be constructed with a series of stencils rather than a few stencils calling a series of functions.

The only problem I have not considered are the tracers. There is a '[X_DIM, Y_DIM, Z_DIM, 23]' tracer bundle that is iterated over a few times within the parameterization scheme. I have not checked all if 23 tracers are modified, but given how it is written I wager they are not. Need to develop a method of tracking which tracers are modified at various times and ensuring that only those are iterated on, so that we are not iterating over the entire domain 23 times every time tracers are touched. A 1D mask may be the best solution, but I think I can do better.