FABM 3.0: Runtime error during initialize

[FabianGrosze]

Hi,

I tried to update my environment to FABM 3.0 but I am getting a forrtl: severe (157): Program Exception - access violation" during initialize, more precisely during call freeze_model_info(...).

I noticed that FABM 2 called filter_expressions prior to freeze_model_info. This has been removed in v3.0. Any advice on how to modify my setup to avoid this error using FABM 3.0 is appreciated.

Cheers,
Fabian

[jornbr]

Hi Fabian,

Thanks for reporting. Could you compile with runtime compiler checks on and rerun, to see if you can get a full traceback to the line causing the issue? Alternatively, I'd be happy to try and reproduce the issue, so I can then explore it in detail, but then it'd be useful to know which host and biogeochemical model(s) (fabm.yaml) you are using.

Cheers,

Jorn

[FabianGrosze]

Hi Jorn,

Thank you for the quick response and the suggestion re. compiler checks. I didn't get a full traceback but still managed to resolve the issue with some additional compiler flags and log_message calls.

The problem was that, in one of the models I inherited, the macros _SURFACE_LOOP_BEGIN_ and _SURFACE_LOOP_END_ were missing within the do_surface routine. As a result the freeze routine bound to type_base_model failed for the corresponding surface flux link (here: oxygen_sfl).
FABM 2.x didn't complain about that but FABM 3.0 does (at runtime), though without any informative error message.

Cheers,
Fabian

[jornbr]

Thanks for the update! Yes, FABM now makes an early call to all "do" routines to check which routines are implemented by each biogeochemical model. As the call is made before the model domain is defined, any variable accesses that are incorrectly placed outside _BEGIN_LOOP_/_END_LOOP_ will trigger an array-out-of-bounds error. Unfortunately, we have not found a way to detect this error in the biogechemical model at compile time, and explicit detection and reporting at runtime would come with a massive performance penalty. Hence this issue will for now show up as a runtime "access violation" or similar.

[FabianGrosze]

Yes, for the sake of completeness, this is the error I received after enabling additional runtime checks:
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable READ when it is not allocated

The original error (with less checks) was something including "access violation".

Finally, the good news though: update to FABM 3.0 succeeded.

[jornbr]

Great. It's worth noting that the pre-v3 behaviour was in effect more problematic - for do_surface/do_bottom the issue would remain hidden as long as you ran in hosts without horizontal dimension (e.g., GOTM); when moving to 3D you'd either get random runtime errors or corrupt results.