_GET_HORIZONTAL_ not implemented for diagnostics

[platipodium]

Dear community,

I calculated a 2D diagnostic (z_opt below) from a 3D field. It is registered as a horizontal diagnostic and setting it works fine. At some parts of my program, I want to read this diagnostic with _GET_HORIZONTAL_ but that seems not implemented. What's the best way to work around this (other than moving this to its own FABM model)?

module clines

   use fabm_types

   type, extends(type_base_model), public :: type_optimal_depth
      type (type_horizontal_diagnostic_variable_id) :: id_zopt
   contains
      procedure :: initialize 
      procedure :: do_column
   end type

contains
   subroutine initialize(self, configunit)
      class (type_optimal_depth), intent(inout), target :: self
      integer,                     intent(in)            :: configunit

      call self%register_diagnostic_variable(self%id_zopt, 'result', '','result', missing_value=0.0_rk, &
         act_as_state_variable=.true., source=source_do_column)

   end subroutine initialise

   subroutine do_column(self, _ARGUMENTS_DO_COLUMN_)
      class (type_optimal_depth), intent(in) :: self
      _DECLARE_ARGUMENTS_DO_COLUMN_

      real(rk) :: z_opt, z_opt_old

      _GET_HORIZONTAL_ (self%id_zopt, z_opt_old)

      _VERTICAL_LOOP_BEGIN_

         z_opt = 0.5

      _VERTICAL_LOOP_END_
      _SET_HORIZONTAL_DIAGNOSTIC_(self%id_zopt,z_opt)
   end subroutine do_column

end module

Error message:

   47 |       _GET_HORIZONTAL_ (self%id_zopt, z_opt_old)
      |                                                                1
Error: 'horizontal_index' at (1) is not a member of the 'type_variable_id' structure

Indeed horizontal_index is not declared as a member of the type_variable_id (in fabm_types and fabm) for horizontal diags...

[jornbr]

To achieve this, you'd register an additional dependency to read the value of the diagnostic. That dependency then needs to be coupled to the diagnostic. That coupling can be done explicitly in code, but as it is a recurrent pattern, you can achieve the same implicitly by registering your dependency with the same name as the diagnostic. For instance, in initialize:

call self%register_dependency(self%id_zopt_old, 'result', '','result')

And then in do_column:

_GET_HORIZONTAL_ (self%id_zopt_old, z_opt_old)

This is described, albeit in very compact fashion, at the very end of https://github.com/fabm-model/fabm/wiki/Developing-a-new-biogeochemical-model#diagnostic-variables.

[platipodium]

We implemented this successfully. Now we have a (more complex) model that has both do() and do_column(). We consistently added for all diags also the corresponding dependencies to make them readable. And we need data in do() that originates from do_column() and vice versa.

We get the error:

FATAL ERROR: graph::add_call: circular dependency found: /life:do needs life/z_top provided by /life:do_column needs life/phy_N_phy1 provided by /life:do

Is that @jornbr

• a problem in general, such that you cannot have do and do_column within one model (we did not find an example), or
• is there general good practice to enable this
• or is this something related to our specific code (without disclosing it here)

[jornbr]

FABM's problem here is that it cannot schedule the calls to do and do_column such that all their inputs are up to date. If do is called first, then z_top would have the value from the previous time step. If do_column is called first, phy_N_phy1 would have the value from the previous time step. By default, this is disallowed - the assumption is that you want all inputs to be up to date. However, if you are happy with one of these two possible "not up to date" outcomes, you can explicitly flag that the corresponding input is allowed to be "stale". The API for this is not documented as it may still evolve, but for now, it would look like this:

call set_dependency_flag(self%id_z_top%link%target, source_do, dependency_flag_stale)

which states that id_z_top does not need to be up to date when do is called.

Note 1: in the previous scenario, where you register a dependency on your own diagnostic, this stale flag is implied as the input value of that diagnostic can never be up to date for the routine that compute the diagnostic.

Note 2: it is quite common for such circular dependencies to arise when a lot of logic is put in a single module. In such cases it may be that the detected circular dependency is not real, in the sense that one of the routines does not actually use the dependency value at all. For those cases, a much better solution is to split that one monolithic module into multiple modules.

[platipodium]

Thank you @jornbr . We had thought of the 2nd possibility, too, but the first one make more sense (with stale flag), as it is not a real circular dependency anyway.