Vertical "averaging" in FABM river input

[poplarShift]

Hi, I'm new to the code so take this with a grain of salt, but this:

uk-fvcom/FVCOM_source/mod_force.F

Line 12976 in 9f8fc6c

FABMR(J,IFABM)=SUM(FABM_ALL(JJ,1:KBM1,IFABM))/KBM1

is only a vertical average if sigma layers have a constant thickness, I think. There are several cases of the same logic around there.

[mikebedington]

Yep that would be wrong if people are using s-coordinates or similar at the coast, however have you actually run into any problems with it? We always run with hybrid coordinates so have constant thickness at the coast so would be correct in our case anyway, but as far as I can see in the code those values aren't ever used as that code is only applied for variables with no_river_dilution but then in mod_fabm_3D.F this matrix is skipped for no_river_dilution. If this is they case then the block 12971- 12985 should probably just set FABMR to zero with a comment to make clear why. @riquitorres any idea whether fabmr for no_river_dilution is used elsewhere, it appears on first look that it isn't...?

[riquitorres]

To be honest, the original approach to no-river dilution was causing problems of unbounded growth of some ERSEM (in our case) variables so we stopped using it. In the last iteration, the approach was to skip the river treatment all together rather than add the FABMR calculated average. In theory, the mod_fabm_3D shouldn't use FABMR for variables that are marked as no_river_dilution.

uk-fvcom/FVCOM_source/mod_fabm_3D.F

Line 2048 in 9f8fc6c

IF (.NOT. model%interior_state_variables(IFABM)%no_river_dilution) THEN

FABMR should only operate with values that are 0 (FABM variables are therefore diluted by river inputs) or the values provided in the river file. I guess we can remove that section of mod_force.F if it is no longer used.

[poplarShift]

Thanks for the explanations. To be clear, it hasn't caused me any problems (I think), I just came across this while digging for something else and thought I'd leave a note.