FFSL linear model transport

[James Kent (jameskent-metoffice)]

PR Summary

Sci/Tech Reviewer: cjohnson-pi
Code Reviewer:

The linear model currently uses MoL transport. Using FFSL should improve performance and mean we use the same transport scheme for linear and non-linear transport.

This PR has added the tangent linear FFSL code. I have created the control routines for horizontal and vertical transport, and then used the existing FFSL kernels. This builds on the split transport routine added in PR#149.

The linear transport has two parts, u' dot grad(ls_f) and ls_u dot grad(f'). For the u' dot grad(ls_f) term, as this is a flux-form semi-Lagrangian method, we need to first transport ls_f by ls_u, and then compute the flux using u' with this. This is documented in the code.

I have added a C12 test using FFSL (for both azspice and ex1a) and also a C224 test. The C224 test is run with a smaller dt than the MoL version - this is due to the stability of FFSL depending on the Lipschitz number and any stability fixes we use being non-linear in nature.

Results for C12 NWP Linear Model Test:

This is MoL on trunk showing u:

This is FFSL showing u:

This is MoL on trunk showing theta:

This is FFSL showing theta:

FFSL has produced larger velocities and theta values near the model top.

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)

trac.log

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

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

[cjohnson-pi]

I realise that this code is still in draft status, but I thought that (with the approaching review deadline) it would be useful to add a review now.

Science review 1

Many thanks for putting this linear FFSL code together. The nonlinear FFSL code is quite complicated so I would like to congratulate you on navigating a path forwards with this.

As you have mentioned, there are some differences between the MoL and FFSL plots, especially at the model top. However, these can likely be resolved with further investigation in future work – and it will be good to have this code on trunk so that we have something to start with.

I have a few (hopefully minor) comments that need to be addressed.

Comments at L255 of tl_ffsl_vert_alg_mod.x90 and L339 of tl_ffsl_hori_alg_mod.x90
This requires further explanation. I think something like, assuming that only the wind u varies and that Df/Dt=0 where D/Dt is the Lagrangian derivative, the tracer at time n+1 is given by
f^n+1 (x) = f^n ( x- dt u )
so that the perturbation is given by
f’^n+1 (x) = f^n ( x – dt(u+u’) ) – f^n ( x - dt u’ ) \approx f^n+1( x – dt u’ )

‘Linear scheme’ variable
Why is the ‘linear_scheme’ variable required as an input to the subroutines? It is set to false for tl_ffsl_horiz_pert and set to true for tl_ffsl_horiz_ls. i.e. for different subroutines. So I think it would be better if this was hardcoded in the subroutine.

Variable names
For the transport controllers, I’m not keen on the name mean_transport… because its not consistent with the rest of the code. Perhaps nonlinear_transport_controller would be a better choice?

Please define (with a comment) what ls_field_new_with_pert, pert_u_ls_field and field_with_ls_wind are – as they don’t seem very clear to me.

Please could we rename field to field_n (in tl_ffsl_control_alg_mod) so as to be consistent with the corresponding nonlinear code. Similarly with ls_field, field_w3_shifted, ls_field_w3_shifted and field_ptr.

Generally the rules for naming variables in the linear model is that e.g. for the variable in the nonlinear code, this becomes flux for the perturbation in the linear model (i.e. the same name) and ls_flux for the linearisation state. There are some variable names e.g. mass_flux_pert that could be changed to follow this.

tl_ffsl_control
Please add a description at the top of what this code is doing. Something like: The nonlinear code computes …. And the linear code computes …. using the addition of 2 parts, u’.grad(ls_f) and ls_u.gradf’

Configuration options
I’m worried that as the linear code is using the nonlinear code it might be possible to set a configuration option that then makes the code nonlinear. (Especially as the plan is for the linear and the nonlinear models to be run in the same executable – with a merged configuration, and making it easier for confusion between nonlinear config options and linear options). So is it necessary/possible to add some error message into the linear code if an incorrect option has been specified.

It may be better to add FFSL configuration options to the default rose-app.conf if these are the default FFSL config options for FFSL in the linear model, as long as they only affect FFSL and not the other configurations. This could be changed on a follow-on pull-request. Something to think about really.

Integration tests
We need to have some linear integration tests to test the validity of whether this code is linear and a linearisation of the nonlinear code. Given the complexity of the code, and that you have included some full tests (C224 and C12) these could be added in a follow on pull-request.