Extend CNFireMethodMod with a FATESFireData class

[ekluzek]

In order to give FATES access to the Fire data (such as lightning and population density), we'd like to extend the CNFireMethodMod abstract class with a FATESFireData class. This also extends the CNFireBaseMod class so that it will get access to the hdm and pop-density data.

This will add an additional option to the fire_method namelist item I propose to be called "fateslnfm". It could only be set if use_fates is set. We should also add the current default option of "fatesnofiredata" so that FATES wouldn't use any additional data.

FATESFireData class would extend CNFireBaseMod class. It wouldn't use the CNFireArea, CNFireFluxes nor CNFireReadNML, methods, so should probably set them to a stub that dies if called. It would also save the data for when read in, and handle the accumulator methods to average it over the daily interval.

Initially the hierarchy of

CNFireMethodMod
CNFireBaseMod
(and then the three classes that extend that of CNFireLi2014Mod, CNFireLi2016Mod, and CNFireNoFireMod)

would just be extended with the FATESFireData class.

Some renaming would be helpful though, I've put that in a separate issue #983.

For CN-Fire the fire instance would be handled just as it is now. Which means it's attached to the CNVegetationFacade, which is just as it should be. When FATES is active though FireMethod would be a type added to the FATES interface as new data. The FireFactory would be called for FATES. The FireFactory would just need to make sure that the No-Fire and Li-fire options are only used when use_cn is on, and fatesnofiredata and fateslnfm are only allowed when fates is on.

@rgknox @slevisconsulting

[ekluzek]

I think the way to handle it is for cnfire_method_type to be instantiated inside of clmfates_interface in the clm_fates instance of hlm_fates_interface_type.

Here's some rough code that sketches out how to do that below. I show passing in a control variable called fates_fire_data that would signal the level of fire data being sent down to FATES, but I don't show how it comes into play. That would also need to be fleshed out. I do think that making a CNFireMethod creation type just for FATES makes sense though. That would be part of the CNFireFactoryMod and would be specific to the FATES fire data levels.

diff --git a/src/utils/clmfates_interfaceMod.F90 b/src/utils/clmfates_interfaceMod.F90
index df05801e..2a7cfd70 100644
--- a/src/utils/clmfates_interfaceMod.F90
+++ b/src/utils/clmfates_interfaceMod.F90
@@ -130,6 +130,7 @@ module CLMFatesInterfaceMod
    use FatesPlantHydraulicsMod, only : InitHydrSites
    use FatesPlantHydraulicsMod, only : UpdateH2OVeg
    use FatesPlantHydraulicsMod, only : RestartHydrStates
+   use CNFireMethodMod        , only : cnfire_method_type
 
    implicit none
    
@@ -170,6 +171,9 @@ module CLMFatesInterfaceMod
       ! fates_restart is the inteface calss for restarting the model
       type(fates_restart_interface_type) :: fates_restart
 
+      ! fates_fire_data_method is the fire data that the HLM is importing into FATES
+      class(cnfire_method_type), allocatable :: fates_fire_data_method
+
    contains
       
       procedure, public :: init
@@ -228,6 +232,7 @@ contains
       use FatesInterfaceMod, only : FatesInterfaceInit, FatesReportParameters
       use FatesInterfaceMod, only : numpft_fates => numpft
       use FatesParameterDerivedMod, only : param_derived
+      use CNFireFactoryMod , only : create_fates_fire_data_method
 
       implicit none
       
@@ -513,6 +518,12 @@ contains
       ! Report Fates Parameters (debug flag in lower level routines)
       call FatesReportParameters(masterproc)
 
+      ! Figure out what level of fire data to send down to FATES
+      if(use_fates_spitfire) then
+         allocate(this%fates_fire_data_method, &
+            source=create_fates_fire_data_method(fates_fire_data))
+      end if
+
     end subroutine init
 
     ! ===================================================================================

[ekluzek]

The other thing is the FATESFireData class which extends the CNFireBase class. So it's top would be something like this:

  public :: fates_fire_lnfm_type
  !
  type, extends(cnfire_base_type) :: fates_fire_lnfm_type
   private
   ! 24 hour averaged lightning data would need to be in here..
    real(r8),pointer :: lnfm24(:)  ! Daily avg lightning by grid cell (#/km2/hr) contains
     !
     ! !PUBLIC MEMBER FUNCTIONS:
     procedure, public :: CNFireInit            ! Extend the CNFireInit method to also initialize the 
                                                                    ! accumulation needed to be done
     procedure, public :: CNFireReadNML ! Stub should never be called
     procedure, public :: CNFireArea    ! Stub -- should never be called
     procedure, public :: CNFireFluxes ! Stub -- should never be called
  end type fates_fire_lnfm_type

In clm_driver, calls to the CNFireInterp and UpdateAccVars would need to be done as well for FATES. The FATESFireData class also could have it's own subroutines with FATES specific names to do this functionality. They could in turn call the CNFireInterp specific subroutine from the CNFireBaseMod class level.

[ekluzek]

I think this outlines what needs to happen fairly well. Note, that all of this doesn't change the current CNFire* hierarchy, it's only adding new things for FATES, by adding a new subroutine to CNFireFactoryMod and extending the CNFireBaseMod class with a FATES specific version that uses the Init and Interp method and data from that class.

@slevisconsulting when you get time to work on this let me know if this makes sense. It might be good to have more discussion on it again to make sure everyone agree's with the proposed implementation. I want to make sure @rgknox is good with adding the FATESFireData class instance to clmfates_interface. That's the thing that made the most sense to me. But, I could see disagreement on that...

[ekluzek]

The changes in ctsm1.0.dev095 to CNFire have some impact here. We should make the updated version compatible with those changes.

[ekluzek]

This was finished with ctsm5.1.dev022