-
Notifications
You must be signed in to change notification settings - Fork 0
DevelopmentsEnhancements
Here, we list technical developments and physics enhancements that would make MetUM-OML MC-KPP more accessible to the broader scientific community. Some of these are "one-off" tasks, but others would require continual support. Some we can do ourselves; others would require assistance from those with more technical experience than we have. It is partly a wish list and partly a roadmap to increasing the exposure to and use of MetUM-OML and MC-KPP by the wider community.
Integrating MetUM-OML into the UMUI and/or ROSE - large initial effort, then moderate continuing support Currently, running MetUM-OML on ARCHER requires including an FCM branch and a set of hand-edits in the UMUI, then editing and running a script on ARCHER and possibly editing a poorly-documented Fortran namelist, prior to submitting the UMUI job. It may also require editing a history file and resubmission scripts during the simulation, particularly if the job fails along the way. All of this requires some bespoke knowledge of the system, which only a couple of us have. As use of the MC-KPP framework increases -- and [ProjectsProposals chances are it will very soon] -- it would make training and supporting users of MetUM-OML much easier if the framework were properly integrated into the UMUI.
This would involve creating UMUI panels and options that are equivalent to the MC-KPP namelist options, producing some documentation for those panels and options, then writing the necessary back-end scripts to translate the UMUI switches into the MC-KPP namelist. It would also likely also require changing the MetUM-OML FCM branches and possibly the MC-KPP code itself, as well as putting MC-KPP into FCM to allow the UMUI to build it alongside the atmospheric executable. Continuing support would be required when new UM versions are released, to ensure that the MC-KPP UMUI panels continue to work with those new UM versions.
Eventually we will want to support ROSE as well, once MC-KPP [SupportedModels supports a MetUM version] that works with ROSE. Initially, we should integrate into the UMUI, as the academic community will probably continue to focus on pre-9.x UM versions for the foreseeable future.
N.B.: Nick's NERC fellowship includes three months of support for Ros Hatcher to include MetUM-OML into the UMUI.
Better parallel-processing support - moderate initial effort, very little continuing support MC-KPP has limited support for OpenMP, to allow us to run the 1D physics on multiple cores on a single supercomputing node. At higher atmospheric horizontal resolutions, or as MC-KPP becomes more expensive due to physics enhancements (see below), it may be necessary to add support for MPI, to allow a mixed-mode OpenMP/MPI strategy for running MC-KPP on multiple nodes. This would require cleaning up and enhancing the existing OpenMP support, adding MPI communication and grid-decomposition routines and altering the HPC submission scripts.
Also, at higher horizontal resolutions we may need to consider a parallel coupling strategy, which is supported by the OASIS MCT framework. MC-KPP does not currently support OASIS MCT or parallel coupling. This will require revisions to the MC-KPP coupling interface for the MetUM.
Improved tools for generating ancillary files - moderate initial effort, very little continuing support MC-KPP requires a number of ancillary files (e.g., for heat and salt corrections, coupling mask/weight, SST and ice climatologies). Nick has scripts that generate these, but they are written in a mess of separate IDL and Fortran codes that are poorly documented. All MC-KPP ancillary files are netCDF, but occasionally the variable and dimension names are occasionally inconsistent between files. This makes generating new files painful for the uninitiated. New files are needed to support additional horizontal resolutions, to change the coupling region and to use different SST or ice climatologies.
Ideally, we could build better and more flexible tools that would generate the necessary ancillary files to run common types of experiments.
Documentation - moderate initial effort, little to moderate continuing support There is very little available documentation for MC-KPP. Nick wrote a PDF with documentation for an old version (circa 2009) of the framework, but this is now largely obsolete. We need to develop documentation, ideally web-based and hosted on these pages, so that users can understand the many namelist options and the design of the various ancillary files.
We also need to ensure that this documentation is kept up-to-date, as various improvements and modifications are made to the code.
General usability improvements - small initial effort, no continuing support There are numerous small improvements that would make MetUM-OML easier for new users: better variable names and metadata in the output files; including a run/job identifier in the output filenames; support for multiple meaning periods for each diagnostic; the ability to split output across multiple output files to prevent running up against netCDF file-size limits; gridpoint-varying relaxation timescales for temperature and salinity (#5); probably lots more.
It is important to note that these physics improvements would be available to all [SupportedModels supported model configurations], not just the MetUM.
Better handling of sea ice - large initial effort, little continuing support Currently, we cannot couple near ice because we have no interactive ice support in MC-KPP. It is not clear to us how best to handle ice in the model, but there is relevant expertise at Reading (Danny Feltham's group). Building an ice module for MC-KPP might be an entirely separate project in itself, or could be part of a project (i.e., part of a funding application) that intended to use MetUM-OML at high latitudes.
Vertical advection - moderate to large initial effort, little continuing support MC-KPP does not include vertical advection, which is an important process in many regions (e.g., for coastal upwelling) and for many phenomena (e.g., Ekman pumping from tropical cyclones). Including vertical advection would allow the MC-KPP framework to be used for a wider range of applications and provide more accurate simulations in these regions and of these phenomena.
This is potentially a large effort, considering the required testing and the potential need to revise other aspects of the code to support vertical transports.
Relaxation to geostrophic currents - small to moderate initial effort, little continuing support The currents in MC-KPP are a mess, quite frankly. Under certain surface-forcing conditions, the inertial oscillations can become computationally unstable, producing very strong shear that deepens the mixed layer to the bottom of the domain and results in spurious isothermal and isohaline layers that never regain their stratification (#6). We have worked around this by introducing a nonlinear relaxation to zero current, using a timescale that inversely scales with the magnitude of the current, but this is at best a hack. Relaxing to geostrophic currents would be a much more physically based choice, but requires some work to implement properly. It is possible that code for this already exists at ECMWF (from Yuhei Takaya's work).