Question about external surface fluxes when using built-in models

[Karsten Lettmann]

Dear all,

I'm a new FABM user. Therefore, I hope you will not mind this question.

I tried to provide an external surface flux to a passive tracer following this post in fabm-users group:

https://groups.google.com/g/fabm-users/c/wN1NzDFDqxo/m/AZb75qmZAgAJ

I added a model instance to the yaml-file:

T2_flux:
    model: external_surface_flux
    coupling :
      target : tracer2/c 

The problem is that I do not know how to link the flux within the physical model.

I tried to link as a horizontal_data.

I can test, that the variable is needed by:

use fabm
  USE fabm_config
   USE fabm_driver
  USE fabm_types
  USE fabm_builtin_models

type (type_fabm_horizontal_variable_id)       :: horizontal_id

horizontal_id = model%get_horizontal_variable_id('T2_flux_flux')
  if (model%is_variable_used(horizontal_id)) then
        print*,'we use this variable'
  end if
  if (model%variable_needs_values(horizontal_id)) then
   print*,'T2_flux_flux needs values'
  end if

So, these if-statements provide positive feedback.

But when trying to link the variable with the data (flux_ex)  provided in the physical model using:

call model%link_horizontal_data(horizontal_id, flux_ex)

I got a compiling error of the form:

Found no matching specific binding for the call to the GENERIC ‘link_horizontal_data’ at

Is there a special way to use these built-in models within the physical model?

Is there any idea, what I could have done wrong or what I missed to do?

Best wishes, Karsten Lettmann

[Jorn Bruggeman]

Hi Karsten,

 

That all looks fine, so I expect the issue is the way your flux_ex variable is declared. This should have the shape of a horizontal field and the data type of a normal FABM real variable. For a 3D model that could look like

 

real(rk), allocatable, target :: flux_ex(:,:)

 

The number of dimensions (:,:) will depend on the host model. The “target” attribute will not be the reason for your error, but it is formally required as FABM will keep a pointer to the field. The field does not have to be “allocatable” – it could also be “pointer” or have a static extent.

 

While debugging this issue, you could temporarily replace link_horizontal_data with link_horizontal_data_by_id – that should result in a clearer error message.

 

NB if your call to link_horizontal_data is a one-off, you could also skip the id altogether:

call model%link_horizontal_data('T2_flux_flux', flux_ex)

Cheers,

Jorn

--
You received this message because you are subscribed to the Google Groups "FABM-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fabm-users/8a6fef32-f992-4b9e-ac46-496177dade64n%40googlegroups.com.

[Karsten Lettmann]

Dear Jorn,

thanks very, very much for your answer.

Your hint to use the direct name of the subroutine (link_horizontal_data_by_id) instead of the generic name (link_horizontal_data) was quite helpful.

So, it seems,  I could find my error.

I tried to run a 1d water column model with 3 passive tracers. However, I only wanted to apply the additional external surface flux to the second tracer.

So, my thinking in prescribing the rank of the flux_ex field was as follows:
- it is a 1d model, so the surface field must be of the form: dimension(:), allocatable, target :: flux_ex

- I only want to provide flux to the second tracer, so flux_ex could be a scalar : allocate( flux_ex(1) )

But the last line was the mistake, I think.

With your hint to call the direct subroutine, I got the rank-error message

So, I changed it in this way: allocate( flux_ex(1:3) )
And I only liked to the second index:

horizontal_id = model%get_horizontal_variable_id('T2_flux_flux')

call model%link_horizontal_data(horizontal_id, flux_ex(2))

After doing this, I could get the flux from FABM by:

call model%get_surface_sources(flux_sf, sms_sf)

It was added to the variable flux_sf in second index: flux_sf(2)

Then, I could add the flux to the first layer of tracer 2 within the physical model:

 interior_state(1,1:3) = interior_state(1,1:3) + dt*flux_sf(1:3) / dz

(with interior_state(z,tracer), dt = time step, dz = layer thickness)

I think, it seems to work now.

Thanks again, very, very much for your help.

All the best for you, Karsten

[Jorn Bruggeman]

Hi Karsten,

 

Glad to hear it worked!

 

For completeness: I expect that the flux_ex(1) option can be made to work too, but you’d have to send flux_ex(1) rather than flux_ex when you call link_horizontal_data. Alternatively, you could declare flux_ex as a scalar (e.g., “real, target :: flux_ex”), in which case you could send flux_ex directly.

 

I wonder though – if you end up adding such explicit surface flux handling directly into the 1D model, is there even a need to pass the fluxes to FABM and to use external_surface_flux? You could potentially add your fluxes directly to the output of model%get_surface_sources on the host side. The one reason I can think of to route them through FABM is that you have biogeochemical modules in there that need to know the total surface flux… The external_surface_flux option is mostly used with host models that have a generic infrastructure for passing named variables to FABM already in place; external_surface_flux then provides a mechanism to leverage that infrastructure to add surface fluxes.

 

NB it’s great that your system is working and the above comments are not meant to suggest it needs changing. But I thought the information could be useful in general, also if others revisit this thread at some later stage.

To view this discussion on the web visit https://groups.google.com/d/msgid/fabm-users/0ba6d9f8-1f11-419b-a020-bc4275a07df8n%40googlegroups.com.

[Karsten Lettmann]

Dear Jorn,

thanks for this answer and the additional explanations.

Please let me give some short comment.

This 1d-model was only a short test to understand, how this external flux option works.

The reason, why I wanted to know this, is that our project partners use this external flux option in a coupled GETM/GOTM - FABM system with ERGOM as the biogeo model.

As we plan to use the same ERGOM as part of an FVCOM-FABM-ERGOM system without much/any changes on the FABM-ERGOM side, I wanted to understand how to get the external fluxes working on the FVCOM side.
Now, understanding the external flux route, I can use the identical yaml-file and ERGOM code used by our partners, I think/hope.

Thanks again very, very much for your helpful comments and answers.

Best, Karsten

[Jorn Bruggeman]

Hi Karsten,

 

Yes, that makes perfect sense, thanks for explaining. And nice to hear about the model combinations you plan to use!

To view this discussion on the web visit https://groups.google.com/d/msgid/fabm-users/5eb8d26e-d412-44b1-bf7a-3642ed0e3970n%40googlegroups.com.