Inland basin flow coupling and use land fractions on rivers grid

[Dan Copsey (DanCopsey)]

PR Summary

Sci/Tech Reviewer: Maggie (@maggiehendry)
Code Reviewer: Erica Neininger (@ericaneininger)

Pass inland basin flow from the rivers (TRIP) to LFRic via OASIS. To get this to conserve water we need to determine if there is any ocean in each TRIP grid point where there is inland basin flow. Therefore we need to pass land fractions into the standalone-TRIP part of JULES. If there is any ocean then pass the inland basin flow to the ocean (alongside river outflow). If there is no ocean then pass the inland basin flow to soil moisture (via LFRic).

• linked MetOffice/um#63
• linked Inland basin flow coupling lfric_apps#401

• closes Inland basin flow coupling and use land fractions on rivers grid #34

Code Quality Checklist

(Some checks are automatically carried out via the CI pipeline)

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid undertanding and enhance the
  readability of the code
• My changes generate no new warnings
• If editing rose-meta/jules-shared then have you supplied a linked UM PR?

Testing

• I have tested this change locally, using the JULES rose-stem suite
• If shared files have been modified, I have run the UM and LFRic Apps rose
  stem suites
• If any tests fail (rose-stem or CI) the reason is understood and
  acceptable (eg. kgo changes)
• I have added tests to cover new functionality as appropriate (eg. system
  tests, unit tests, etc.)

trac.log

Test Suite Results - jules - jules_test_inland_flow/run1

Suite Information

Item	Value
Suite Name	jules_test_inland_flow/run1
Suite User	dan.copsey
Workflow Start	2026-04-15T13:04:37
Groups Run	all

Dependency	Reference	Main Like
jules	DanCopsey/jules@test_inland_flow_v5	False
SimSys_Scripts	MetOffice/SimSys_Scripts@2026.03.1	True

Task Information

❌ failed tasks - 2

Task	State
nccmp_meto_azspice_gnu_gswp2_trip_rivers-only	failed
nccmp_meto_ex1a_cce_gswp2_trip_rivers-only	failed

✅ succeeded tasks - 661

⌛ waiting tasks - 2

Task	State
housekeep_meto_azspice_gnu_gswp2_trip	waiting
housekeep_meto_ex1a_cce_gswp2_trip	waiting

Security Considerations

• I have reviewed my changes for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

Performance Impact

• Performance of the code has been considered and, if applicable, suitable
  performance measurements have been conducted

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance
  of Generative AI tool name (e.g., Met Office Github Copilot Enterprise,
  Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the
  Simulation Systems AI policy
  (including attribution labels)

Documentation

• Where appropriate I have updated documentation related to this change and
  confirmed that it builds correctly

Approvals

Please request all relevant approvals. See the CodeOwners.txt file for section
owners.

Technical

• JULES Code Owner
• OpenMP
• River Routing
• Rose Stem
• Rose Metadata
• Upgrade Macros

Scientific

• Surface
• Hydrology
• Vegetation
• Veg3 RED Demography
• Biogechemistry
• Biogenic fluxes
• Fire
• Lakes
• Evaluation
• Imogen

Sci/Tech Review

• I understand this area of code and the changes being added
• The proposed changes correspond to the pull request description
• Documentation is sufficient (do documentation papers need updating)
• Sufficient testing has been completed

Please alert the code reviewer via a tag when you have approved the SR

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• CLA compliance has been confirmed
• Code quality standards have been met
• Tests are adequate and have passed
• Documentation is complete and accurate
• Security considerations have been addressed
• Performance impact is acceptable

[Maggie (maggiehendry)]

I'm on leave currently. I'll need to review when I return on 23rd April.

[Dan Copsey (DanCopsey)]

I have applied all the sci/tech review comments from the documentation issue in JULES_docs_PR79.

I have applied most of the sci/tech review comments in the JULES FCM ticket #1528 – See section that starts with “Updated review 11/09/2025”. I have repeated this below and added my replies:

rose-meta/jules-standalone/HEAD/rose-meta.conf
Can you add a human readable message please to go alongside the fail-if under

[namelist:jules_input_grid=nx]
[namelist:jules_input_grid=ny]
[namelist:jules_rivers_props=nx_rivers]
[namelist:jules_rivers_props=ny_rivers]

regarding l_use_land_fraction.

I have done this and added the text # If using land fractions for rivers then the input grid needs to be the same as the rivers grid so that the land fractions are copied across to the rivers grid correctly.

rose-meta/jules-standalone/versions.py
Why does upgrade macro need to move the l_inland switch from the rivers namelist to the hydrology namelist only when l_rivers=T? Why not just rename the namelist it belongs to? Currently it should only be true in UM-JULES.

The reason for this is that in UM-JULES NWP models the rivers are turned off and therefore we don’t know what the l_inland switch is set to. It might be on but not doing anything as rivers is turned off. In this scenario we don’t want to simply copy it across. I think the coding that I have done is correct and only set the new jules_hydrology/l_inland to true when l_rivers is true and jules_rivers/l_inland is true. Therefore I don’t think I need to change anything here.

rose-stem/app
Can you add the 'inland_outflow_rp' diagnostic to the 'outflow' profile in the rivers-only TRIP opt files so the code will be tested by standalone; l_use_land_fraction = .false.. They'll just all be defined as inland points rather than coastal.

I have done this.

lfric_apps.x_br - vn2.2_inland_flow/interfaces/jules_interface/build/extract.cfg
src/initialisation/shared/check_compatible_options_mod.F90 \

• src/initialisation/shared/check_compatible_options_rivers_mod.F90
  src/initialisation/standalone/ancillaries/init_ancillaries_coupling_mod.F90

This has already been done.

I think a check should be added to ensure that the land fraction ancillary is consistent with the river routine ancillary (upgrade first to HoT).
src/initialisation/standalone/ancillaries/init_rivers_process_data_mod.F90

This is already done in initialisation/standalone/ancillaries/init_rivers_props_mod.F90‎ (lines 389 to 403) where it compares the grids to make sure they are consistent. I don’t think this needs to be done twice. Also if I were to put such a check in init_rivers_process_data_mod.F90 then I would need to put in the plumbing for the land fraction grids to be passed all the way down to init_rivers_process_data_mod.F90 which would be a bit messy. Shouldn’t this be avoided for just one check that is already done elsewhere?

Typo
2467 " coastal points have been detected/"

Thanks for spotting that. I have removed the extra /

src/initialisation/standalone/ancillaries/init_rivers_process_data_mod.F90
Superflous "USE"
951 USE coastal, ONLY: l_use_land_fraction

I have removed the Superflous "USE"

src/initialisation/standalone/init_output_mod.F90
Will it not change the outflow per river diagnostic regardless of whether it's coupled? Should it print the warning regardless?

In the coupled model adding the inland_outflow_rp output diagnostic will not change results as coupled models have inland_outflow in the namcouple file and therefore l_inland_outflow will already be True. This warning is for the case where JULES is run uncoupled and someone is analysing the outflow_per_river diagnostic and then adds the inland_outflow_rp diagnostic and is surprised when the outflow_per_river diagnostic changes. This is probably quite rare so this warning will hardly be generated. If I change it to the suggested setup then this will always appear in coupled models and I think we are trying to reduce the amount of warning messages.

What happens if inland_outflow is requested, but outflow_per_river isn't?

The outputting of the inland_outflow diagnostic is independent of whether or not outflow_per_river is in the diagnostic list. You can take out outflow_per_river from the diagnostic list and still be able to output inland_outflow fine.

[Dan Copsey (DanCopsey)]

Hi Maggie. I have applied your suggested changes to the jules documentation and tried to make it. There was one slight issue which I fixed. I have checked all the changes appear correct. I have moved the final html directory so if you want to have a look then just send me a private message.

[James Bruten (james-bruten-mo)]

Macro looks good

[Dan Copsey (DanCopsey)]

Hi Maggie,
I think I have done everything that you requested apart from the allowing of runoff to be initialised to zero in coupled models (if we choose not to initialise from a dump). Hopefully you will allow that. I will now pass this ticket back to you for sci/tech review.
Dan.

[Maggie (maggiehendry)]

Just a few small changes to rescue formatting of JULES user guide & fix url in metadata.

[Maggie (maggiehendry)]

I'm still not convinced that this is doing the correct check, but we can tweak it if need be when the LFRic apps Rose stem tests are added.

[Maggie (maggiehendry)]

Thanks Dan Copsey (@DanCopsey). Good to go now 😄.

[Erica Neininger (ericaneininger)]

Thanks Dan, approving, pending outstanding code owner approval.