GOTM and OMEXDIA

[BeatrizArellano]

Hi all,
I am starting to explore FABM to couple a sediment model ( possibly OMEXDIA) with GOTM. I see that OMEXDIA_p is included in FABM, but I cannot access it when running GOTM. The folder hzg is not included in the path where GOTM was built.
I wonder if the module OMEXDIA_p can be coupled with GOTM or if I need some extra steps to do it.

Also, another question is if it is possible to couple a model that also outputs the information for the sediment column.

Thank you!

[platipodium]

Thanks @BeatrizArellano. The omexdia_p and the entire hzg directory was dropped from FABM after the transition to FABM 1, as these models were not updated to FABM 1. You can still access those models, for example from the repository https://sourceforge.net/p/mossco/fabm/ci/master/tree/. That will likely not work with a modern GOTM.

We have partly transitioned some of the prior models from the hzg subdirectory in a new hereon model library. This has not been merged with the official FABM managed by @jornbr, but you can access it from https://github.com/schism-dev/fabm/tree/master. That FABM was last synchronised with master last year and contains a FABM 1 version of omexdia_p at https://github.com/schism-dev/fabm/tree/master/src/models/hereon/omexdia_p

I don't think that we have tested this sufficiently, so please go ahead, download, test, and report back. On success, I am sure @jornbr will merge it into the official branch.

Thanks,
Carsten (maintainer of omexdia_p)

[BeatrizArellano]

Thanks @platipodium for the prompt reply and your support. I'll test the available version!
I am just starting to explore FABM and wonder if I could find more resources on how to couple a model.
Thanks again

[jornbr]

Just to confirm: yes, happy to merge in the hereon models on your cue, Carsten; ideally via a pull request.

From a quick glance at your FABM 1 version of the omexdia_p code, it does look like it does not yet read its parameters from fabm.yaml. Since FABM 1 and up no longer read from namelists, I suspect it may leave the omexdia_p parameters undefined. If so, some further code tweaks are likely needed. Testing will tell.

[BeatrizArellano]

Thanks @jornbr for the prompt reply! I will test it and report back. How would the code need to be modified so it can read the parameters from OMEXDIA.

[jornbr]

That would be done by replacing this section with lines like these:

call self%get_parameter(self%rFast, 'rFast', '#/day', 'decay rate fast decay det.', default=0.01_rk)

You can find an overview of parameter names, units etc. here

[BeatrizArellano]

Great, thank you! I'll test it.

[bolding]

Hi Baetriz There is quite extensive documentation available at - https://github.com/fabm-model/fabm/wiki For reading parameters it might be easiest to look at some of the other models. The simplest being - https://github.com/fabm-model/fabm/blob/master/src/models/bb/passive/passive.F90 - look at the get parameter section in the initialize subroutine. The parameters comes from a YAML formatted configuration file which is read at run time. Karsten Den fre. 1. dec. 2023 kl. 16.42 skrev BeatrizArellano < ***@***.***>:

…

Thanks @jornbr <https://github.com/jornbr> for the prompt reply! I will test it and report back. How would the code need to be modified so it can read the parameters from OMEXDIA. — Reply to this email directly, view it on GitHub <#47 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVA42MYU3IDE22FDCA5ZVLYHH3FTAVCNFSM6AAAAABABTT42OVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMZQHA4TQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Karsten Bolding ***@***.*** +4564422058

[BeatrizArellano]

Thanks @bolding. That's very helpful!

[BeatrizArellano]

Hi again @platipodium, @jornbr and @bolding,

Thank you so much for your support.
I am writing to share some updates on this thread. I followed your advice and the omexdia_p module is up and running. Now, I need to test it under different scenarios and explore its coupling with other modules.

I have two further questions:

• Is it possible to implement within FABM a biogeochemical model that also outputs the information of the benthic domain?
• I also wonder if it is possible to specify different time-steps to run different modules?

Thank you again for the feedback and support!
Beatriz

[BeatrizArellano]

if you make any updates to that, please make a pull request (PR) and I will accept your changes it into that repository. We intend to then propagate these changes upstream into the official FABM repo.

Sure, I can share the changes I've done so far :)

[platipodium]

As for the usage of the do_bottom() you might get inspiration from Onur Kerimoglu's GPM model https://github.com/OnurKerimoglu/FABM-GPM/blob/EH-Release/README.md, I don't have much experience with do_bottom().

As for a separate benthic host, we implemented that in https://sourceforge.net/p/mossco/code/ci/master/tree/src/drivers/fabm_benthic_driver.F90 as part of the MOSSCO project (but still using FABM0 :=( )

[BeatrizArellano]

Thank you @platipodium!
I had a brief look at MOSSCO and it's an amazing project! So, MOSSCO wouldn't be compatible with recent FABM modules, right?
I'll have a look at those links for inspiration :)

[platipodium]

At the moment, the fabm_pelagic and fabm_benthic drivers are not compatible, but might be upgraded within the next 2 months... If you want to contribute, you're welcome!

[BeatrizArellano]

At the moment, the fabm_pelagic and fabm_benthic drivers are not compatible, but might be upgraded within the next 2 months... If you want to contribute, you're welcome!

Great to know this! We'll assess our options these days and will definitely consider this pathway. Thanks for all the support.