Domain Period and resolution

Because of the higher computational costs a smaller domain and a shorter period has been selected for LEMs. The domain is is centered at 13.3º N and 57.7º W and comprises the HALO circle.  It is elongated on the zonal (East-West ) direction for a total domain size of 300x500 km²: from the centre, the domain spans 150km North and South, and 250 km East and West. For the vertical domain height of at least 6 km is advised as the heighest clouds can reach heights up to 4 km  beyond with a sponge layer of a few km has to be added. 

Participants are encouraged to use an horizontal resolutions as close as possible to 100 m, coarser resolutions up to 400 m are also accepted as alternative, or in addition. For the vertical resolution a resolution of 20m near the surface is advised. The grid may be stretched such as to have a resolution of 50m near cloud top height at 3 km. 

The simulation period is from  00 UTC on February 1^st 2020 to 00 UTC on February 12^th 2020. The first day is to be discarded because of the spin-up so that analysis will cover the 10 day period from February 2^nd to Februay 11^th  2020.

Initial and Lateral Boundary Conditions for the Present Day Simulations

The Initial and Lateral Boundary Fields are provided on a hourly basis from simulations form the COSMO model on a resolution of 2 km. The 3d fields needed for the initialisation and the lateral boundaries are provided at model levels and include  ( T, u, v,, zg, q_v, q_i, , q_i )  ( Temperature, horizontal wind components, geopotential heights, water vapour specific humidity, liquid cloud water and cloud ice) and can be found HERE. 

The 2D surface fields such as Sea Surface Temperature and Surface Pressure are also provided at an hourly basis from COSMO and can be found HERE.

REMARK 1: It is our experience that direct nesting of the 100~200m LEM into the 2 km resolution COSMO model output can give rise to numerical issues such as spurious waves and long spin up patterns for turbulence and does not allow for importing well developed mesoscale structures through the lateral boundaries. We therefore recommend a double nesting strategy by using a coarser 500m resolution simulation on a domain as large as the common analysis (orange) domain as a first nesting. The results of this first nesting simulation can subsequently be used as a source in which the 100~200 m resolution large eddy simulation can be nested in.

REMARK 2: The top of some LES models can be as low as 6 to 8 km. In that case suitable upper boundary conditions for the incoming short- and longwave radiaton needs to be provided. We advise to run a 1d radiation model along with the simulation that is feeded with the mean atmospheric profiles for temperature and humidity and which can provide realistic estimates for the downward ahort and longwave radiation.

Initial and Lateral Boundary Conditions for Future Weather Simulations

For the Future Weather runs, the SST fields are increased by 4K and the lateral COSMO boundary fields are perturbed with perturbation fields that are derived from a  30 year monthly means difference between a +4K-SST and a present day global climate simulation (see also section on methodology and references there for further details). For this purpose output data of the GFDL model has been used, a model with a moderate equilibrium climate sensitivity (ECS).

The PGW perturbations have already been added to the COSMO fields and the plus 4K perturbations have also all been added to the SST fields. So in order to simulate this Future Weather Simulation, just use exactly the same set-up as for the Present Day Simulation using the 3d hourly initialisation and perturbed boundary fields from COSMO fields that can be found HERE and the 2d  +4K SST fields and  Pressure fields that can be found HERE

Required Output

The required output fields and fluxes are described HERE . Please provide 2 output sets: one for the present day case and one for the future weather case.

The data for EUREC4A-MIP should be uploaded in the Zarr format.  One way to create the zarr data is to save data from the model in netCDF and then convert it to zarr when uploading. Zarr has a similar data model to netCDF, so metadata like units and attributes are preserved when converting. See HowtoEUREC4A for detailed instructions on the format and upload procedure.