Feature: add handling of FABM property "disable_transport"

[platipodium]

In some FABM models there is a property call "disable_transport"

      call self%set_variable_property(self%id_consumed_prey, 'disable_transport', .true.)
For any variable that you don’t want in transport.

which is meant to mark a tracer not to be transported. This feature is currently not supported in SCHISM (and most other hosts). There should be at least a warning, but at best an implementation for this.

[platipodium]

A question I have to this is whether to

(1) include such marked variables in tr_nd(:) and skip them during calculation or
(2) not at all consider them in tr_nd(:)

The reason for (1) could be that such variables might need to be manipulated through initial conditions, which would likely not be possible with (1)

[platipodium]

We should also think of other properties that are commonly used, such as no_river_dilution ...

[josephzhang8]

If some vars are not to be transported, it's best FABM excludes them in its list of tracers, and also manages its own i.c. etc.

[platipodium]

OK, I had a look and will be working on this in a separate fabm branch, submit a PR when ready. It's a little bit more intricate in fabm_schism.F90, as this would lead to separation of state_variables that are transported versus those not

• non-transported variables need to be allocated in host (similar to diagnostics)
• surface fluxes need to be handled (as not supplied by host anymore)
• I/O needs to be handled separately.

[josephzhang8]

Another option: why not at each time step, first save the no-transported vars in temp arrays in FABM, and restore them after main routine?

[platipodium]

Creative idea @josephzhang8 ! They would then cost us, of course, as their advection/diffusion would still be computed. but it may be a first and easy implementation.

Questions:

• in the I/O then, the variables would probably be written out wrong (with the advected = non-restored state) ?

[josephzhang8]

I/O occurs last in _step so it'd work.