#474: LFRic-Nudging: Part-A: Introduce ability to read nudging datafiles by mcdalvi · Pull Request #474 · MetOffice/lfric_apps

Mohit Dalvi (mcdalvi) · 2026-04-30T16:20:18Z

PR Summary

Sci/Tech Reviewer: Thomas Bendall (@tommbendall)
Code Reviewer: Matthew Hambley (@MatthewHambley)

This PR introduces the ability to read in datafiles that will be used for Nudging the Momentum models (Ref: Nudging NWP to AI/ML models - possibly targeting PS49).
The handling of Nudging data is modelled on existing lateral boundary condition handling in LFRic since they are both required to be interpolated from high time resolution file data on every model timestep.
Nudging changes summary:

Ability to read in nudging data for temperature, U-wind, V-wind and Log surface pressure (required for vertical remapping to model levels).
New [namelist:nudging], which will be active when theta or wind are 'forced by nudging' (in namelist:external_forcing). A corresponding upgrade_macro to add the namelist and I/O related items.
Introduce routine create_nudging_fields to create the nudging input fields as '2-D with user-specified (nudge_data) levels'. Corresponding grid_def_nudging.xml and grid_def_nudging_coarse.xml added to lfric_atm/metadata/.
Introduce ability to read in nudging data on native ('dynamics') or a coarser grid, with rationalising of routines that create the model fields ('make_spec', 'create_model_data') to accept both aerosol and nudging coarse mesh definitions.
Note that the above requires a LFRIC_CORE change to allow defining 3-D coarse grid fields as ''multigrid_ll'' x ndata.
Define a nudging_time_axis which will be populated based on the actual number of time records in the specified nudging file.
Introduce two new rose-stem tests lfric_atm_nwp_gal9_nudging-C48 that reads nudging files on the model grid and lfric_atm_nwp_gal9_nudging_coarse-C48 that reads in data at a lower resolution (C12) grid. This currently uses nudging data created from ERA5 source, but aim is to expand this to AIFS and other models.
At this stage the reference fields are only made available to LFRic and do not modify temperature/ winds.
linked #369: Allow coarse-grid fields with ndata levels: vn3.1 read coarse 2d lfric_core#369

Code Quality Checklist

I have performed a self-review of my own code
My code follows the project's style guidelines
Comments have been included that aid understanding and enhance the readability of the code
My changes generate no new warnings
All automated checks in the CI pipeline have completed successfully

Testing

I have tested this change locally, using the LFRic Apps rose-stem suite
If any tests fail (rose-stem or CI) the reason is understood and acceptable (e.g. kgo changes)
I have added tests to cover new functionality as appropriate (e.g. system tests, unit tests, etc.)
Any new tests have been assigned an appropriate amount of compute resource and have been allocated to an appropriate testing group (i.e. the developer tests are for jobs which use a small amount of compute resource and complete in a matter of minutes)

Test Branch: test4_vn3p1_nudging_data

trac.log

Test Suite Results - lfric_apps - test4_vn3p1_nudging_data/run4

Suite Information

Item	Value
Suite Name	test4_vn3p1_nudging_data/run4
Suite User	mohit.dalvi
Workflow Start	2026-06-18T13:18:54
Groups Run	developer', 'lfric_atm_azspice_extra

Dependency	Reference	Main Like
casim	MetOffice/casim@2026.03.2	True
jules	MetOffice/jules@3647a42	True
lfric_apps	mcdalvi/lfric_apps@test4_vn3p1_nudging_data	False
lfric_core	mcdalvi/lfric_core@vn3.1_read_coarse_2d	True
moci	MetOffice/moci@2026.03.2	True
SimSys_Scripts	MetOffice/SimSys_Scripts@3e2998b	True
socrates	MetOffice/socrates@2026.03.2	True
socrates-spectral	MetOffice/socrates-spectral@2026.03.2	True
ukca	MetOffice/ukca@1cdb9c2	True

Task Information

❌ failed tasks - 1

Task	State
run_lfric_atm_nwp_gal9_eda-C12_azspice_gnu_fast-debug-32bit-crun0	failed

✅ succeeded tasks - 1261

⌛ waiting tasks - 1

Task	State
housekeep_azspice	waiting

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)

VsCode - code completion/ snippets.

Documentation

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

PSyclone Approval

If you have edited any PSyclone-related code (e.g. PSyKAl-lite, Kernel interface, optimisation scripts, LFRic data structure code) then please contact the TCD Team

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

…se-stem changes.

… time-axis definitions

…r the new arguments

DanStoneMO · 2026-05-01T09:30:12Z

Is there any chance main could be merged into this branch? I'm currently unable to test the changes with JEDI due to the conflicts

Mohit Dalvi (mcdalvi) · 2026-05-01T09:46:55Z

Apologies, I was not aware creating a PR triggers all this activity ! I have changed it to draft till all my testing is complete.

…at are defined in source code; implement upgrade macro

…2bit as done for other azspice runs; remove unused additions to ancil reading code

cjohnson-pi

I think there will be an interaction/conflict with #502 where I have reorganised create_model_data. Essentially, there shouldn't be an impact from #474 on linear_driver, which will be enabled by #502.

It will just depend on which ticket goes on first as to how to address this.

Matthew Hambley (MatthewHambley)

A few things to consider while we think about the linked ticket.

Matthew Hambley (MatthewHambley) · 2026-05-21T07:12:25Z

+    type(mesh_type), pointer :: mesh => null()
+    type(mesh_type), pointer :: twod_mesh => null()


We no longer require initialisation on declaration of pointers. In fact we now prohibit it. Please use nullify(pointer) at the top of the procedure code, if it is not otherwise immediately initialised.

Done b906772. also updated neighbouring pointer declarations for consistency.

Matthew Hambley (MatthewHambley) · 2026-05-21T07:24:11Z

    if (present(twod)) field_spec%twod=twod
    if (present(empty)) field_spec%empty=empty
    if (present(coarse)) field_spec%coarse=coarse
+    if (present(coarse_mesh_name)) field_spec%mesh_name=coarse_mesh_name


Why is the generic field_spec%mesh_name being assigned from the specific course_mesh_name. If the type member is generic, the initialising variable should be too. If the initialising variable is specific, the type member should also be.

Code updated to use coarse_mesh_name throughout. b906772

Matthew Hambley (MatthewHambley) · 2026-05-21T07:29:51Z

            else
               dim = 1
            end if
+      case ('ecmwf_levels')


Does this actually have anything to do with ECMWF or is that just the source of the data which happens to be being used at the moment?

Changed to nudging_levels in all references now. b906772

Matthew Hambley (MatthewHambley) · 2026-05-21T08:11:29Z

+
+    type(field_maker_type) :: creator
+
+    call log_event('GungHo: Creating nudging fields...', LOG_LEVEL_INFO)


Does this need to be "info" level. We already suffer the logging being much too talkative. This goes for all other new event logs.

Changed to LOG_LEVEL_TRACE.

Matthew Hambley (MatthewHambley) · 2026-05-21T08:19:56Z

+        if (coarse_rad_aerosol) then
+          mesh_name = aerosol_mesh_name
+        else
+          mesh_name = ''
+        end if


Wasn't this set above, outside the conditional? Do we have code duplication here?

Duplicate statements removed. b906772.

Matthew Hambley (MatthewHambley) · 2026-05-21T08:23:59Z

   !> @brief Map moisture array enumerators to moisture array.
  type(time_axis_dict_type), parameter :: time_axis_dict &
-    = time_axis_dict_type(525,529,536)
+    = time_axis_dict_type(525,529,536,542)


Where do these numbers come from? UM code? A comment to explain this would be handy.

These numbers are part of the field_spec design itself. See original comments lfric_core:#4208, which seem to indicate they have to be unique for each field, within a different range for each field category.

I see that, in which case, a comment explaining that this is where these numbers are defined and they are opaque identifiers with no intrinsic meaning would help future developers.

A better solution still would be to define them as integer, parameter :: usefule_name = 525, then use them here. If you make these parameters public, they can be used outside the module. If that is their purpose. Even if it isn't, keeping them private but having useful names would help developers of this module.

Implemented. Note that I am not familiar with the design of the routine so hopefully this is acceptable to the respective section owner.

thomasmelvin

All looks good to me

…cation

Matthew Hambley (MatthewHambley)

There are also changes requested for core which may effect this change.

Matthew Hambley (MatthewHambley) · 2026-06-04T12:18:56Z

@@ -0,0 +1,112 @@
+!-----------------------------------------------------------------------------
+! (c) Crown copyright 2025 Met Office. All rights reserved.


Wrong year, although we are not including year in the copyright statement any more.

Matthew Hambley (MatthewHambley) · 2026-06-04T12:22:38Z

+  use external_forcing_config_mod, only : theta_forcing_nudging,               &
+                                          theta_forcing,                       &
+                                          wind_forcing_nudging,                &
+                                          wind_forcing


Please use the new configuration API. You can find documentation of this at https://metoffice.github.io/lfric_core/how_to_use_it/lfric_datamodel/modeldb.html#accessing-configuration-data but please ask if you have further questions.

Matthew Hambley (@MatthewHambley)
Re: using modeldb to access configuration values: I have attempted to implement this for process_nudging_fields. However process_nudging_fields is also called in gungho_model_mod/before_context_close, same as the LBC fields. This before_contaxt_close routine name is actually passed as a procedure pointer to init_io -> lfric_core:driver_io and finally called from lfric_xios_context_mod. I cannot see a way to use the modeldb argument at this level in the code hierarchy.
Thomas Bendall (@tommbendall)

As mntioned above it does not look to be feasible to access modeldb at all places where 'process_nudging_fields' is called (namely from lfric_core:lfric_xios_context_mod'. However, modeldb has been introduced in create_nudging_fields to access clock.
The configuration API has been used in other routines where new configuration variables are being accessed and modeldb is already available e.g. gngo_driver_mod, gungho_init_fields_mod. It does seem that the API does not return a default value (RMDI/ EMDI) if the namelist/ item is not active in a particular model application. The availability has to be explicitly checked before trying to access value of the namelist item, otherwise this causes a invalid memory access error while obtaining the item value.

While it's not possible to pass ModelDB to the callback due to a circular dependency, it is possible to pass any configuration you need. Either as primitive values, if there are few of them, or as a namelist type if you need lots of configuration.

This is not an ideal solution as it bloats the callback's argument list but it at least makes the problem explicit. The problem still exists when fetching from global scope, it is just obfuscated. It is more important that we move away from global scope configuration and I think we would rather see our problems than not.

As of yesterday the location of the callback has changed so you will have to merge your branch up to head of trunk before making any changes.

Ideally this would be done by creating a new branch from your development branch and merging that up to head of trunk. This leaves a branch based on a release tag, which the GC group can use, should they care to, and one which can actually merge onto trunk. Unfortunately it doesn't seem to be possible to change the source branch of a pull request.

Instead please add a comment to this pull request with the hash of the head-of-branch before you merge up. This can be used to retrieve the version against the release tag.

Matthew Hambley (@MatthewHambley) I am going to need help in understanding the best way to pass the configuration values to process_nudging_fields. The callback routine gungho_model_mod__before_context_close that calls the former, is now defined in lfric_core:driver_io_mod as a io_configuration_type with only clock as the argument. Since it already receives modeldb%clock, can this be extended to receive modeldb itself by changing the configuration_type to type(modeldb_type), intent(in) :: modeldb, or will that interfere with other locations where 'before_close' variants might be called?
The same issue will arise even if just the required configuration values were to be explicitly passed.

Do you need modeldb? if you only need the configuration, can you not just pass the config_type object? So you would end up with 2 arguments the config and clock.?

This has been implemented now as proposed, passing modeldb to process_nudging_fields, and in driver_io under lfric_core.
Tests run overnight complete except for 'nwp_gal9_eda' which seems to have failed in ~umtest/ as well.

Ricky Wong (@mo-rickywong) , sorry your comment did not appear till I refreshed ! Is there an example of the config_type argument I can look at?

Matthew Hambley (MatthewHambley) · 2026-06-04T12:25:00Z

+  !> @param[in]    mesh       The current 3d mesh
+  !> @param[in]    twod_mesh  The current 2d mesh (not used here)
+  !> @param[in]    mapper     Provides access to the field collections
+  !> @param[in]    clock      The model clock
+  subroutine create_nudging_fields(mesh, twod_mesh, mapper, clock)


If the 2D mesh isn't being used, why pass it in? If it is needed later, then it can be obtained from the mesh collection. Something like mesh_collection%get_mesh(mesh, extrusion=TWOD) but check the API.

Given that you also need the clock and field collections, it might be more straight forward to pass modeldb in. Note that it also contains the configuration so no need to pass that either.

The comment appears to be left over from earlier version: twod_mesh is passed to tbe 'creator%init' routine.
Clock is now accessed from modeldb'

Matthew Hambley (MatthewHambley) · 2026-06-04T12:41:01Z

   !> @brief Map moisture array enumerators to moisture array.
  type(time_axis_dict_type), parameter :: time_axis_dict &
-    = time_axis_dict_type(525,529,536)
+    = time_axis_dict_type(525,529,536,542)


I see that, in which case, a comment explaining that this is where these numbers are defined and they are opaque identifiers with no intrinsic meaning would help future developers.

A better solution still would be to define them as integer, parameter :: usefule_name = 525, then use them here. If you make these parameters public, they can be used outside the module. If that is their purpose. Even if it isn't, keeping them private but having useful names would help developers of this module.

Matthew Hambley (MatthewHambley) · 2026-06-04T12:49:42Z

+    use multires_coupling_config_mod,  only : coarse_nudging,                  &
+                                              nudging_mesh_name


As noted above, we are migrating to configuration objects.

Introduced in this and other routines where new items are being accessed.

Matthew Hambley (MatthewHambley) · 2026-06-04T12:53:39Z

+    if (coarse_rad_aerosol) then
+      mesh_name = aerosol_mesh_name
+    else
+      mesh_name = ''
+    end if
+


Can you just pass the mesh object rather than messing about with names?

Possibly, but this will require re-writing all calls to 'make_spec' if not for the aerosol ones with 'coarse' option.
I have opened isue #554 to standardize handling of fields on coarse mesh, although this will be better addressed by a core LFRic developer.

…places where *process_nudging_fields* is called

… additional checks that the namelist is active in current application

Matthew Hambley (MatthewHambley)

One remaining issue, then we can go to trunk.

Matthew Hambley (MatthewHambley) · 2026-06-17T07:11:04Z

+  use external_forcing_config_mod, only : theta_forcing_nudging,               &
+                                          theta_forcing,                       &
+                                          wind_forcing_nudging,                &
+                                          wind_forcing


While it's not possible to pass ModelDB to the callback due to a circular dependency, it is possible to pass any configuration you need. Either as primitive values, if there are few of them, or as a namelist type if you need lots of configuration.

This is not an ideal solution as it bloats the callback's argument list but it at least makes the problem explicit. The problem still exists when fetching from global scope, it is just obfuscated. It is more important that we move away from global scope configuration and I think we would rather see our problems than not.

As of yesterday the location of the callback has changed so you will have to merge your branch up to head of trunk before making any changes.

Ideally this would be done by creating a new branch from your development branch and merging that up to head of trunk. This leaves a branch based on a release tag, which the GC group can use, should they care to, and one which can actually merge onto trunk. Unfortunately it doesn't seem to be possible to change the source branch of a pull request.

Instead please add a comment to this pull request with the hash of the head-of-branch before you merge up. This can be used to retrieve the version against the release tag.

Mohit Dalvi (mcdalvi) · 2026-06-17T09:39:42Z

Latest working commit for dev branch before merging main: 7818d2d

…fig values

…ess_nudging_fields*

Matthew Hambley (MatthewHambley)

This change now looks to be ready for trunk.

Mohit Dalvi (mcdalvi) · 2026-06-18T13:54:46Z

This change now looks to be ready for trunk.

Thanks Matthew Hambley (@MatthewHambley) . Just adding a reminder here about the test input files to be placed in BIGDATA

cjohnson-pi · 2026-06-19T09:05:05Z

#502 has now been committed and I expect this to cause a conflict with this PR. In #502 I split create_model_data into create_model_data and create_physics_model_data. Ideally the changes on this ticket should go into create_physics_model_data and then there should not be any change in the linear_model.

Mohit Dalvi (mcdalvi) · 2026-06-19T09:57:07Z

#502 has now been committed and I expect this to cause a conflict with this PR. In #502 I split create_model_data into create_model_data and create_physics_model_data. Ideally the changes on this ticket should go into create_physics_model_data and then there should not be any change in the linear_model.

I will merge with main to resolve conflicts, but I believe the external_forcing with nudging is independant of physics. In fact we have had to move some existing code sections out of #ifdef UM_PHYSICS.
Thomas Bendall (@tommbendall) ?

Thomas Bendall (tommbendall) · 2026-06-19T10:19:42Z

#502 has now been committed and I expect this to cause a conflict with this PR. In #502 I split create_model_data into create_model_data and create_physics_model_data. Ideally the changes on this ticket should go into create_physics_model_data and then there should not be any change in the linear_model.

I will merge with main to resolve conflicts, but I believe the external_forcing with nudging is independant of physics. In fact we have had to move some existing code sections out of #ifdef UM_PHYSICS. Thomas Bendall (Thomas Bendall (@tommbendall)) ?

cjohnson-pi thanks for flagging the conflict! Good question Mohit Dalvi (@mcdalvi) -- I think it could be argued either way. I'd probably lean towards us adding the new fields to the new create_physics_model_data routine? From a dynamical core point-of-view I see external_forcing as physics schemes that are owned by gungho.

Mohit Dalvi (mcdalvi) · 2026-06-19T10:26:22Z

#502 has now been committed and I expect this to cause a conflict with this PR. In #502 I split create_model_data into create_model_data and create_physics_model_data. Ideally the changes on this ticket should go into create_physics_model_data and then there should not be any change in the linear_model.

I will merge with main to resolve conflicts, but I believe the external_forcing with nudging is independant of physics. In fact we have had to move some existing code sections out of #ifdef UM_PHYSICS. Thomas Bendall (Thomas Bendall (Thomas Bendall (@tommbendall))) ?

cjohnson-pi thanks for flagging the conflict! Good question Mohit Dalvi (Mohit Dalvi (@mcdalvi)) -- I think it could be argued either way. I'd probably lean towards us adding the new fields to the new create_physics_model_data routine? From a dynamical core point-of-view I see external_forcing as physics schemes that are owned by gungho.

Thanks for the clarification Tom, will merge in the changes accordingly.

Mohit Dalvi (mcdalvi) added 3 commits April 29, 2026 10:44

Interim Commit while migrating from FCM branch - XML, namelist and ro…

0389dfc

…se-stem changes.

Second commit transferring changes from FCM: Nudging field and file ,…

388b69b

… time-axis definitions

Compilation fixes, mainly updating other calls to setup_model_data fo…

8a745da

…r the new arguments

Mohit Dalvi (mcdalvi) requested review from a team, cjohnson-pi, iboutle, Matt Shin (matthewrmshin), Steven Sandbach (ss421) and thomasmelvin as code owners April 30, 2026 16:20

Mohit Dalvi (mcdalvi) requested review from Matthew Hambley (MatthewHambley) and removed request for a team April 30, 2026 16:20

github-actions Bot assigned Mohit Dalvi (mcdalvi) Apr 30, 2026

Mohit Dalvi (mcdalvi) changed the title ~~LFRic-Nudging: Part-A: Introduce ability to read nudging datafiles : vn3.1.1 read nudging data~~ #74: LFRic-Nudging: Part-A: Introduce ability to read nudging datafiles : vn3.1.1 read nudging data Apr 30, 2026

Mohit Dalvi (mcdalvi) changed the title ~~#74: LFRic-Nudging: Part-A: Introduce ability to read nudging datafiles : vn3.1.1 read nudging data~~ #474: LFRic-Nudging: Part-A: Introduce ability to read nudging datafiles : vn3.1.1 read nudging data Apr 30, 2026

Mohit Dalvi (mcdalvi) added 2 commits April 30, 2026 17:36

Improve trigerring in metadata

e2c6817

include files that were not explicitly 'git add'ed

05b457a

Mohit Dalvi (mcdalvi) marked this pull request as draft May 1, 2026 09:45

Mohit Dalvi (mcdalvi) added Linked Core This PR is linked to a MetOffice/lfric_core PR KGO This PR contains changes to KGO macro This PR contains a metadata upgrade macro labels May 1, 2026

Mohit Dalvi (mcdalvi) added 2 commits May 5, 2026 11:13

First round of fixes from testing: only handle fields and settings th…

f1f0ddb

…at are defined in source code; implement upgrade macro

Fixes -mostly aligning field definitions; rationalised tests to use 3…

dd2ed96

…2bit as done for other azspice runs; remove unused additions to ancil reading code

Mohit Dalvi (mcdalvi) modified the milestone: Summer 2026 May 12, 2026

Mohit Dalvi (mcdalvi) mentioned this pull request May 12, 2026

#369: Allow coarse-grid fields with ndata levels: vn3.1 read coarse 2d MetOffice/lfric_core#369

Open

29 tasks

Mohit Dalvi (mcdalvi) added 2 commits May 13, 2026 15:13

merge into origin/main at 08455b0

de251b0

modify path to point to files containing licence information

8baec12

cjohnson-pi approved these changes May 21, 2026

View reviewed changes

Matthew Hambley (MatthewHambley) requested changes May 21, 2026

View reviewed changes

thomasmelvin approved these changes May 21, 2026

View reviewed changes

Changes from Review- mainly consistent naming of fields; remove dupli…

b906772

…cation

github-actions Bot added the cla-modified The CLA has been modified as part of this PR - added by GA label May 29, 2026

Mohit Dalvi (mcdalvi) requested a review from Matthew Hambley (MatthewHambley) June 2, 2026 16:07

Matthew Hambley (MatthewHambley) requested changes Jun 4, 2026

View reviewed changes

Mohit Dalvi (mcdalvi) added 3 commits June 5, 2026 10:45

Attempt to get away from hardwired numbers in collection declaration.

6975f0a

Revert some changes after review as modeldb may not available in all …

344ff27

…places where *process_nudging_fields* is called

Expand use of configuration API for new items. However, this requires…

7818d2d

… additional checks that the namelist is active in current application

Mohit Dalvi (mcdalvi) requested review from David Lee (davelee2804) and Wolfgang Hayek (tinyendian) as code owners June 15, 2026 16:00

Mohit Dalvi (mcdalvi) mentioned this pull request Jun 16, 2026

#554: Improve set up of fields on coarse grid in LFRic #554

Open

Mohit Dalvi (mcdalvi) requested a review from Matthew Hambley (MatthewHambley) June 16, 2026 09:12

Matthew Hambley (MatthewHambley) requested changes Jun 17, 2026

View reviewed changes

Merge in main at 0337ca1

a692006

github-actions Bot removed the cla-modified The CLA has been modified as part of this PR - added by GA label Jun 17, 2026

Pass in *modeldb* to process nudging fields to allow accessing of con…

55356f3

…fig values

Mohit Dalvi (mcdalvi) requested a review from Matthew Hambley (MatthewHambley) June 18, 2026 08:15

Only pass the required configuration information information to *proc…

f2b5edc

…ess_nudging_fields*

Matthew Hambley (MatthewHambley) approved these changes Jun 18, 2026

View reviewed changes

Mohit Dalvi (mcdalvi) added 3 commits June 19, 2026 12:10

Merge main into branch after MetOffice#504

6f76af3

Correct order of upgrade_macros

1eec0e3

Point to core branch, updatte KGOs

b97aae6

		type(mesh_type), pointer :: mesh => null()
		type(mesh_type), pointer :: twod_mesh => null()


		type(field_maker_type) :: creator

		call log_event('GungHo: Creating nudging fields...', LOG_LEVEL_INFO)

		@@ -0,0 +1,112 @@
		!-----------------------------------------------------------------------------
		! (c) Crown copyright 2025 Met Office. All rights reserved.

		use multires_coupling_config_mod, only : coarse_nudging, &
		nudging_mesh_name

Conversation

Mohit Dalvi (mcdalvi) commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Code Quality Checklist

Testing

trac.log

Test Suite Results - lfric_apps - test4_vn3p1_nudging_data/run4

Suite Information

Task Information

Performance Impact

AI Assistance and Attribution

Documentation

PSyclone Approval

Sci/Tech Review

Code Review

Uh oh!

DanStoneMO commented May 1, 2026

Uh oh!

Mohit Dalvi (mcdalvi) commented May 1, 2026

Uh oh!

cjohnson-pi left a comment

Choose a reason for hiding this comment

Uh oh!

Matthew Hambley (MatthewHambley) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomasmelvin left a comment

Choose a reason for hiding this comment

Uh oh!

Matthew Hambley (MatthewHambley) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mohit Dalvi (mcdalvi) Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mohit Dalvi (mcdalvi) commented Apr 30, 2026 •

edited

Loading

Mohit Dalvi (mcdalvi) Jun 15, 2026 •

edited

Loading

Mohit Dalvi (mcdalvi) Jun 15, 2026 •

edited

Loading