Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradual implementation of HIGHTUNE functionality into MONC #26

Open
6 of 8 tasks
sjboeing opened this issue Oct 16, 2020 · 2 comments
Open
6 of 8 tasks

Gradual implementation of HIGHTUNE functionality into MONC #26

sjboeing opened this issue Oct 16, 2020 · 2 comments

Comments

@sjboeing
Copy link
Contributor

sjboeing commented Oct 16, 2020

Leif and I had a brief chat about this earlier today. One option would be to start implementing small parts of the functionality required in a clean module. @leifdenby and @cemac-ccs , you would then be able to restructure this so that the MONC forma.

In particular, this could include functionality to help:

  • Read the HIGHTUNE-formatted netCDF files, both the logical flags and the input fields (not sure whether to keep the full input fields in memory).**
  • Perform height (and time, for time-varying fields) interpolation of these fields to the MONC grid.** (Implementing space and time interpolation for HIGHTUNE-based forcing #27)
  • Initialise the fields in MONC.
  • Apply relevant tendencies corresponding to the different processes.**
    ** Inspired by Todd's earlier work

Other functionality we will want to implement later:

  • Ensure there are no entries in the case MONC configuration file (mcf) that should be set via NetCDF (these entries will be in the global mcf, but should be ignored there). Ensure the termination time is smaller than the HIGHTUNE file end time (make a subroutine that simply performs checks).
  • Use the HIGHTUNE NetCDF flags to enable/disable components. This may also need checks on compatibility with the mcf.
  • Use the HIGHTUNE files to set other parameters: surface properties, time-dependent coriolis parameter, surface pressure.
  • Getting the relevant inputs for SOCRATES from HIGHTUNE (lat, lon, time of day). We can use the prescribed radiative tendencies from ERA5 for early testing if needed.

An overview of the parameters that could come from either the mcf or the HIGHTUNE NetCDF is here (from page 7).
https://docs.google.com/document/d/1mz2Ajo4ABdMQBHEYTKmNgBUV4Y9iZjCCLdlbtu1aYgU/edit?usp=sharing

What do you think, @leifdenby and @cemac-ccs?

@leifdenby
Copy link
Collaborator

This list looks like a great starting point @sjboeing! We could use this issue to keep track of how far we've gotten in implementation.

@sjboeing
Copy link
Contributor Author

sjboeing commented Feb 3, 2021

Initial work on this is under #34. This partially addresses the issue of other parameters as well, but surface pressure still needs implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants