Purge Intermediate Api access to configuration object from in favor of new config_type object

[mo-rickywong]

PR Summary

Sci/Tech Reviewer: @allynt
Code Reviewer: @oakleybrunt

This ticket purges lfric_core of instance of the intermediate api to configuration namelists. Previously this was via at namelist_collection_type generally initialised and located as a member of the modeldb_type from driver_modeldb_mod. Following the commit of PR #175, templating and infrastructure for config_type was put in place on lfric_core, but only so that PR #175 would remain a non-linked PR change.

This PR removes the remaining initialisation and usage of the namelist_collection_type (configuration) from lfric_core. This however will require linked changes to lfric_apps. Changes to lfric_apps have been limited to only allow it to work with this lfric_core purge.

Linked PR

• Update Apps to work with purge of intermediate configuration object api on lfric core lfric_apps#208

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 Core rose-stem suite
• If required (e.g. API changes) I have also run the LFRic Apps test suite using this branch
• 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)

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)

No AI was used on this change

Documentation

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

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
  N/A

Sci/Tech Review

N/A

• 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

This is a technical change only and doesn't need a SciTech, however code owners may wish to comment if there are issues.

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

[MatthewHambley]

Presumed code owner's review, although I'm not sure which code.

Everything here looks fine. I like the fact that on average more lines are being removed than added which suggests the original goal of simplifying configuration is being achieved.

I've left a comment for the eventual code reviewer to consider and have one question here:

Why are we choosing to forgo whole English words by replacing configuration with config for arguments? We can change the type of an argument without changing its name.

Response by @mo-rickywong config significantly shortens references to the module/declarations and code to extract variables from the namelist without (I feel) making it vague. The other reason is that during the transition period from the old api to the new api both namelist_collection_type and config_type configuration objects will exist, which could confuse things in the transition if both declared types where called configuration

[MatthewHambley]

Adding commented out code?

[mo-rickywong]

Oversite, left in developer/debugging code, now removed

[hiker]

(I just noticed this after apps #208 was brought to my attention, so please consider this just a comment/question): why is the standard log_event (which would do a 'more graceful' shutdown in case of an error like here) replaced with a write(6....; flush; stop?

[mike-hobson]

I understand the reason for this - The log level is set through configuration, so the logger has to be initialised after configuration is read in. Calling the logger before it is initialised would be undefined behaviour. However, where this happens elsewhere in the code, we don't just write to unit 6, as this is a little uncontrolled, too. What we do elsewhere is:

use, intrinsic :: iso_fortran_env, only : error_unit

write(error_unit, '(A)')'Arguments...

[hiker]

Ah, thanks a lot for the clarification.

[mo-rickywong]

Branch has been updated to use error_unit and output_unit

[stevemullerworth]

Currently, when uninitialised, the logger will write to the error unit if called with log_level_error before the logger is initialised (along with a message saying the logger is uninitialised). This is mentioned in the documentation. So it is OK to use the logger for this error message, I think, rather than to assume that the logger initialisation is dependent on the configuration.

Note, I've created a PR to ensure the uninitialised-logger warning message and normal non-error log messages also go to the error unit.

#296

[mo-rickywong]

Branch brought up to head, hardcoded units switched to error_unit and output_unit

[mo-rickywong]

Due to the old commits, this branch will need an override in order to commit