overview on the cosmo-model system - clm-community - … · which did not show up on the last slide...

Overview on theCOSMO-Model System

Ulrich SchättlerDeutscher Wetterdienst

BU Research and DevelopmentDepartment for Numerical Modelling

08.-12.02.2010 COSMO/CLM Spring School 2010 2

Contents

• The COSMO-Model and its Users• The COSMO-Model Software Package• A Short Development History• Components of the COSMO-Model• Preprocessing• Working with the COSMO-Model

Software Package

The COSMO-Modeland its Users


The COSMO-Model

• The COSMO-Model System is a nonhydrostaticlimited-area atmospheric prediction system.

• It can be used for regional numerical weatherprediction (NWP) and regional climate modelling(RCM).

• The COSMO Community (COnsortium for Small scale MOdeling) runs the system for daily productionof (numerical) weather forecasts.

• The CLM Community deployed it for the IPCC runsand for various scientific purposes in the climatemode. For these applications the model is calledCOSMO-CLM or CCLM.

• The software package of the COSMO-Model systemis freely available, but only for scientific purposes.


COSMO NWP-Applications

DWD (Offenbach, Germany):NEC SX-8R, SX-9

MeteoSwiss:Cray XT4: COSMO-7 and COSMO-2 use 800+4 MPI-Tasks on 402 out of 448 dual core AMD nodes USAM (Rome, Italy):

HP Linux Cluster XEON biproc quadcoreSystem in preparation

Roshydromet (Moscow, Russia), SGI

NMA (Bucharest, Romania):Still in planning / procurement phase

ARPA-SIM (Bologna, Italy):IBM pwr5: up to 160 of 512 nodes at CINECA

COSMO-LEPS (at ECMWF):running on ECMWF pwr6 as member-state time-criticalapplication

HNMS (Athens, Greece):IBM pwr4: 120 of 256 nodes

IMGW (Warsawa, Poland):SGI Origin 3800:uses 88 of 100 nodes

ARPA-SIM (Bologna, Italy):Linux-Intel x86-64 Cluster fortesting (uses 56 of 120 cores)


BTU CottbusCoordination and Evaluation

COSMOOperational Weather Forecast

Model and DataCoupling (OASIS), Model Service

Consortial Runs

IMK-TROSoil and Vegetation Modell Veg3D

BaWü, Extreme Events and Seasonal Prediction

IMK-IFUHydrology, Land Data, PEP

Model Intercomparison

MPI ChemistryAerosols and Clouds, Hygroscopy

JRC IspraLand-Atmosphere-Interaction

Transferability in EuropaData, Model Intercomp.

FU Berlin, Meteorol.Paleo-Climate, Dyn. Mediterranean

Hydrology, Extreme Events

GKSSTransferability Studies

Extreme Events in Coastal Regions,Clouds and Radiation Uni Göttingen, Bioclimat.

Climate of Indonesia

Uni Frankfurt, Atmosph.Ice Phase,

Climate in Mountain Ranges

Uni Köln, Geophys.Clouds and Radiation,Climate in West-Afrika

Wegener Center GrazClimate of the Alps

High Resolution Sim.

IAC-ETH, ConvectionConvection in Alpine Region

High Resolution Sim.

Univ. Bonn, Meteorol.Precipitation

High Resol. Sim. in Rhineland

UCL, ASTR, BelgiumClouds and Contrails

Impact of Aviation in Europe

PIKHydroclimatological Extremes

Uncertainties of Param.,Developm. Environm.

DWDModel Maintenance

Meteorol. Centre DublinWind Climatology

High Resolution Sim. in Irland

IAC-ETH, Land-Atm.Land-Atmosphäre-Interaction, CLM-CLM

Vegetation, climate change

9.2006: 41 Members

9.2007: 55 MembersCLM-Community

CLM Community


Research Communities

The following Universities / Research Institutes have an activepartnership with DWD:• Academy of Sciences, Czech Republic• Alfred-Wegener Institut, Bremerhaven, Germany• Freie Universität Berlin, Germany• Institut für Physik der Atmosphäre, DLR, Oberpfaffenhofen, Germany• Institut für Troposphärenforschung, Leipzig, Germany• University of Bonn, Germany• University of Frankfurt, Germany• University of Hannover, Germany• University of Karlsruhe / Karlsruher Institut für Technologie, Germany• University of Köln, Germany• University of Leipzig, Germany• University of Mainz, Germany• University of München (LMU), Germany

There are also other institutes collaborating with the other NationalWeather Services of COSMO.

The COSMO-ModelSoftware Package


• The COSMO-Model is formed by theequations and the algorithms to solve them.

• For practical reasons these must beimplemented on computer systems.

• This is what we call the COSMO-ModelSoftware Package.

• To run this software, you also need data.

About Software


• Utilities for preprocessing– EXPAR (DWD) / PEP (CLM): to prepare external parameters for

the COSMO-Model– INT2LM: Interpolation program

which reads data from a drivingmodel and interpolates them to theCOSMO-Model grid

• The simulation model itself– COSMO-Model

• Postprocessing tools that arenecessary to understand the results

– for visualization– for verification– for evalutation of climate runs

• Input data for the COSMO-Model– External parameters to describe

the earth´s surface:• constant data, e.g.: orography,

land-sea-mask, soil type• (not so constant) data, e.g.: plant

characteristics– Data from a driving model to

provide initial and boundary datato start the COSMO-Model

• The simulation model itself– Needs initial and boundary data

(see above)

• Output data of the COSMO-Model

Software and Data

For a complete system, the following ingredients are necessary:


• To install the software package for the COSMO-Modelon computers, some external libraries are needed, which did not show up on the last slide– For input and output of data:

• GRIB Library: GRIB is a standard data format defined by theWorld Meteorological Organization (WMO) and is widely used bythe weather services.

• NetCDF Library: The Network Common Data Form is a set of software libraries and machine-independent data formats to support the creation, access, and sharing of array-orientedscientific data and is widely used by the climate community.

– For computing „synthetic satellite images“:• RTTOV Library: The Radiative Transfer Model can be used to

compute radiances and brightness temperatures, as can bemeasured by certain satellites and their instruments (see below: Components of the COSMO-Model).

The Software Package


• The software package for the COSMO-Model contains– The source code for the COSMO-Model– The source code for the INT2LM– The source code for the Grib1 library

• It does NOT contain (and their use can be avoided)– The NetCDF library: It is available from

http://www.unidata.ucar.edu– The RTTOV library: This library has been developed in the

framework of the NWP-SAF (Satellite Application Facility). For usingit, a special licence is necessary, which is available [email protected]

• It does also NOT contain– the program to prepare the external parameters– Postprocessing tools

More information about these issues is given in the PracticalExercises.

The Software Package (II)

mailto:[email protected]

A Short DevelopmentHistory


History

• DWD developed the nonhydrostatic Local Modelduring 1996-1999 and started operational runs on 1 December 1999.

• The development did not start from the scratch! Theformer system EM/DM of DWD was used as a basis.

• In Summer 1999, the Consortium for Small-ScaleModelling was founded by the national weatherservices of Germany, Switzerland, Italy and Greece, which took over the Local Model.

• Later on, Poland (in 2001),Romania (in 2007) and Russia (in 2009) joined the Consortium.

• In 2006 it was decided to use COSMO as thecommon model name.


History (II) – The CCLM

2002

12.2005

10.2006

3.2004

6.2003


From EM/DM to COSMO

Basic Framework for NWP

Fortran77

MemoryManagement (with Cray-Extensions)

Serial

Utilities

I/O (GRIB 0)

Diagnostics

Dynamics (hydrostatic)

Physics(basic package)

I/O (Grib1, NetCDF, Restart)

Diagnostics

Dynamics (nonhydrostatic)

Physics(more advanced)

Assimilation

Framework for NWP and Climate

Fortran90

(Standard) MemoryManagement

Parallelizationfor distributedmemorycomputers

Utilities

EM/DM (now HRM) in the 90ies COSMO-Model (>1999)

Chemics

Components of theCOSMO-Model


Components

• Basic Framework• Data Input / Output• Dynamics• Physical

Parameterizations• Diagnostics• Assimilation• Aerosol and Reactive

Tracers (ART)

I/O (Grib1, NetCDF, Restart)

Diagnostics

Dynamics (nonhydrostatic)

Physics(more advanced)

Assimilation

Framework forNWP and Climate

Fortran90

(Standard) MemoryManagement

Parallelizationfor distributedmemorycomputers

Utilities Chemics


Basic Framework

• The basic organization of the COSMO-Model is done in the main program lmorg.F90.

• The first task is the setup, to define the configuration

– namelist input for the setup

– definition of the model domain

– memory management

– parallelization by domain decomposition

– computation of basic constants and fields


I/O and Postprocessing

• For practical simulations, it is necessary to get data into and out of the model. For idealized test cases, input can beswitched off.

• The COSMO-Model supports three different data formats:– Grib, Version 1– NetCDF– Binary data (only for Restarts)

• It is planned to implement Grib, Version 2, „in the nearfuture“ (may take 1-2 years!)

• It would be better to have the restart files in NetCDF, to bemachine independent.

• During the Output, additional fields can be computed, ifwanted (Postprocessing)


Dynamics

• The Dynamics solves the set of differential equations, that define the COSMO-Model

• Two different dynamical cores are offered, theLeapfrog-scheme (old scheme, used since thebeginning) and the Runge-Kutta (or 2-timelevel) scheme (implemented in the last years). For bothschemes there are several variants.

• The Runge-Kutta scheme was mainly intended forhigh-resolution runs (< 3km), but is now also testedfor coarser resolutions. We aim to replace theLeapfrog scheme in all applications in the near future.


Variants for the Dynamics

• Leapfrog HE-VI: The „horizontal explicit - verticalimplicit“ variant of the Leapfrog scheme is thestandard scheme (still) used in coarser resolutions(COSMO-EU).

• Leapfrog semi-implicit: This scheme was implementedto overcome stability problems in small-scaleapplications, where steep slopes of the orography mayoccur. Although a larger time step may be usedcompared to the HE-VI scheme, the necessarysolution of an elliptic differential equation made thisscheme too expensive for operational use. It isavailable in the source code, but not tested any more.

• Two variants of a two timelevel Runge-Kutta schemeare implemented:– 3rd order scheme after Wicker and Skamarock (default used)– „Total Variation Diminishing“ (TVD) variant after Liu, Osher

and Chan


Physical Parameterizations

• The COSMO-Model uses several sub-componentsfor the physical parameterizations. For most sub-components, different variants are offered.

• Note: Not all variants are fully tested!• The sub-components are:

– Microphysics– Radiation– Moist convection– Turbulent diffusion and parameterization of surface

fluxes– Soil Processes– Lake and sea ice schemes– Subgrid Scale Orography Scheme


Diagnostics

• In the Diagnostics, additional meteorologicalfields are computed, that are not present in the basic equations.

• Also, some ASCII output is produced for a quick monitoring of the forecast: Meteographs, mean values for severalvariables, etc.


Assimilation

• An Assimilation scheme is implemented in the COSMO-Model, which is used in NWP-mode: the Nudging

• In Assimilation mode, the model-state iscontinuously nudged against availableobservations.

• Therefore it provides the analysis for theinitial state of a forecast.


Chemics

• Interfaces have been implemented into theCOSMO-Model for an online coupling of – COSMO-ART: Aerosols and Reactive Tracers– a Pollen module.

• This work has been done by the Karlsruhe Institute of Technology (KIT).

• Note: The source code for COSMO-ART and the Pollen module is not distributed byCOSMO or the CLM-community, but can beobtained directly from KIT.

Preprocessing


Necessary Data

•To run the COSMO-Model, several fields have to be provided(Depending on the chosen configuration)

– External parameters: Constant or slowly varying fields for :• HSURF (FIS), FR_LAND, SOILTYP, Z0, FR_LAKE, DEPTH_LK,

• FOR_E, FOR_D, constant• PLCOV, LAI, ROOTDP, annual cycle• VIO3, HMO3 annual cycle

– Initial fields:• Atmosphere: U, V, W, T, PP, QV, QC, QI, QR, QS, QG• Soil and surface: T_SNOW, W_SNOW, W_I, QV_S, T_S, T_SO, W_SO, FRESHSNW, RHO_SNOW, (T_M, T_CL, WG_1, WG_2, W_CL)

– Boundary fields:• Atmosphere: U, V, W, T, PP, QV, QC, QI, QR, QS, QG• Soil and surface: T_SNOW, W_SNOW, QV_S, (T_S, T_M, WG_1, WG_2)


EXTPAR / PEP

• The external parameters have to be provided fora special application (domain, grid size and resolution) of the COSMO-Model.

• They are derived from (global / regional) rawdata sets like GTOPO30, GLC2000, etc.

• DWD developed a program, to process these(EXTPAR)

• The CLM Community (Gerhard Smiatek fromGarmisch), extended this program to processadditional raw data like ECOCLIMAP data

• This program is called PEP: Preparing ExternalParameters


EXTPAR / PEP (II)

• PEP is NOT distributed with the COSMO-Model package!• Because without the raw data it does not make sense. And

the raw data are several hundreds of GBytes!• If you need a special set of external parameters, you can

– contact DWD (but we are not running PEP, only the original part) or– contact CLM to provide external parameters with PEP

• DWD started to modernize and harmonize its ownprogram. Later on, a web-interface will be implemented, over which external parameter data sets can be ordered.


INT2LM

• The INT2LM does the final preprocessing of all input datafor the COSMO-Model. Despite the name, this is morethan just an interpolation.

• The constant external parameters are taken as providedby EXTPAR / PEP.

• The varying external parameters are taken from EXTPAR/ PEP and processed for the special day of the year.

• The variables for ozone (vio3, hmo3) are not provided byEXTPAR / PEP, but are computed by INT2LM, dependingon the special day of the year.

• All other initial and boundary fields are taken from a coarse grid model and processed for the COSMO-Modeldomain.

• This involves (mainly) a horizontal interpolation, a verticalinterpolation and a special treatment in the boundarylayer.

Working with theCOSMO-Model

Software Package


Namelist Input

• For both, the INT2LM and the COSMO-Model, you haveto specify a certain configuration.

• This defines, what you want to run: which variant of thedynamics, which versions for the physicalparameterizations, etc.

• To specify the configuration, both programs useNAMELIST input

• The COSMO-Model has more than 500 (!) Namelist variables, the INT2LM has about 200.

• It is not necessary to know all of them. Perhaps only 10 % of them are really important.


Namelist Groups

COSMO INT2LM

RUNCTL CONTRL Specifying the basic configuration

LMGRID LMGRID GRID_IN

Specifying the COSMO-Model domainSpecifying the input model domain

IOCTL, GRIBIN, GRIBOUT,

DATA Specifying I/O characteristics

DYNCTL To choose the dynamical core variantPHYCTL To choose the physical

parameterizations

DIACTL To choose the diagnostics


Basic Framework: /RUNCTL/

ydate_ini Initial date and time of the forecast in the form 2009030212

ydate_end End date of the total forecast in the form 2009030612 (optional; necessary for long term simulations that are cut into periods)

ydate_bd Start date and time of the forecast, from which the boundary fields are used

hstart, hstop Start and end of the actual forecast period (in hours)

dt Time step (depending on the resolution

Initial date and forecast range



lphys Physical parameterizations

ldiagnos Diagnostics

luseobs Assimilation

luse_rttov Synthetic satellite images

l_cosmo_art Aerosols and Chemistry

l_pollen Pollen

lartif_data To switch off input and generate artificial data instead

With the following switches you can turn on (.TRUE.) and off(.FALSE.) components:



nprocx, nprocy, Number of processors in east-westand south-north

nprocio Number of additional IO processors(usually 0)

nboundlines =2 for Leapfrog dynamics=3 for Runge-Kutta dynamics

lreproduce Ensures computation of reproducibleresults, but needs morecommunication

There are also some „machine-dependent“ variables, likeldatatypes, ncomm_type. For them, all settings should work on anycomputer, but could give a different performance.NOTE: Only ldatatypes=.TRUE. is NOT working on machineswith 64-bit addressing (like the NEC at DWD )

Parallel Execution:



idbg_level Selects verbosity of output

lprintdeb_all Whether all processors should printdebug output

ldebug_xxx To switch on/off debug output forcertain components

ldump_ascii To switch on/off flushing of ASCIIfiles

Some other control parameters


Basic Framework: /LMGRID/

startlat_tot,startlon_tot

Rotated latitude and longitude of lowerleft grid point

dlat, dlon Resolution (grid spacing) in degrees

pollat, pollon Geographical latitude / longitude ofrotated north pole

ie_tot, je_tot Horizontal grid size (in grid points)

ke_tot Number of vertical levels

Definition of model domain:


Microphysics /PHYCTL/

• Four variants are offered for the microphysics. Theymainly differ in the number of cloud and precipitationparticles, that are considered.

• The basic namelist parameters are– lgsp=.TRUE. To run microphysics– itype_gscp=

• 1: without ice phases not longer used and tested• 2: with snow not longer used and tested• 3: with snow and cloud ice used for COSMO-EU• 4: with snow, cloud ice, graupel used for COSMO-DE

– lprogprec=.TRUE. Switch on/off prognostic precipitation

• For itype_gscp=4, only lprogprec=.TRUE. can be chosen• Use of lprogprec=.FALSE. is not tested and therefore not

recommended any more!


Radiation /PHYCTL/

• The radiation uses the scheme of Ritter and Geleyn, whichis based on a delta-two-stream version of the equation forradiative transfer.

• The basic namelist parameters are– lrad=.TRUE. To run the radiation– nincrad / hincrad To choose the interval between two calls– nradcoarse To run the radiation on a coarser grid

• =1 original grid• >1 nradcoarse grid points are combined in each direction

– lradf_avg To average the radiative forcing– ico2_rad To choose a special CO2 scenario

• The option, to run on a coarser grid, is just for savingcomputational time and is used in the COSMO-DE


Convection /PHYCTL/

• For applications on the meso-α and meso-β scales down to grid spacings of 5-10 km, cumulus convection is a sub-grid scale process which requires a parameterizedrepresentation.

• Even on the meso-γ scale, a parameterization of shallowconvection still is necessary.

• The basic namelist parameters are– lconv=.TRUE. To run the convection parameterization– nincconv To choose the interval between two calls– itype_conv=

0: Tiedtke scheme (default for COSMO-EU)1: Kain-Fritsch scheme (is only a test version)2: Bechtold scheme (not yet available, work going on in Switzerland)3: Shallow convection (default for COSMO-DE)

– lconf_avg: To average the convective forcing


Turbulence /PHYCTL/

• For the vertical diffusion due to turbulent transport, threeschemes are available.

• The basic namelist parameters are– ltur=.TRUE. To run the turbulence scheme– itype_turb To choose the special scheme

• 1: 1-D diagnostic scheme• 3: 1-D TKE based diagnostic scheme (default for COSMO-EU, -DE)• 5/7: 3-D closure scheme, together with l3dturb=.TRUE.

• The 1-D diagnostic scheme is the historical scheme fromEM/DM and is not used (and tested) any more at DWD.

• The 3-D closure scheme has been developed lately. It isintended for the kilometer-scale and not yet recommendedfor use.


Surface Fluxes /PHYCTL/

• These fluxes provide a coupling between the atmosphereand the soil model.

• The basic namelist parameters are– ltur=.TRUE. To run the turbulence scheme– itype_tran To choose the special scheme

• 1: for 1-D diagnostic turbulence scheme (not used anymore)• 2: for 1-D TKE based diagnostic scheme (default at DWD)

• The parameterization of surface fluxes for the 1-D TKE based diagnostic scheme is used in all applications byDWD.

• There are (much) more namelist variables in theturbulence scheme, which should not be changed. Theyare intended for use by the developers only!


Soil Processes /PHYCTL/

• The calculation of surface fluxes requires the knowledge of the temperature and the specific humidity at the ground. TheCOSMO-Model offers two variants of a soil model.

• The basic namelist parameters are– lsoil=.TRUE. To run the soil model– lmulti_layer To choose the special scheme

• =.TRUE. To run a multi-layer (deep soil) scheme (default)• =.FALSE. To run the historic 2-(3-) layer scheme.

– llake To run the FLake model

• The FLake-Model has been implemented recently. At themoment it cannot be used extensively, because it requiresadditional external parameters, that cannot be providedroutinely up to now.


Subgrid Scale Orography

• The subgrid scale orography scheme deals explicitely with a low-level flow, which is blocked, if the subgrid scaleorography is sufficiently high.

• The basic namelist parameters are– lsso=.TRUE. To run the subgrid scale orography

scheme– nincsso To run the scheme only every

nincsso timesteps


Input / Output: /IOCTL/

ngribout To specify, how many output groups are used

yform_read To specify the format of input files (`grb1`,`ncdf`)

yform_write To specify the format of output files (`grb1`,`ncdf`)

lbdclim To switch on the climate mode and read additional boundary fields for long term runs

ydir_restart Directory, where to write the restart files

nhour_restart Triplet to specify start, stop and increment of writing restart files (values are given in hours)

This group defines the most important parameters for I/O


Input / Output: /GRIBIN/

ydirini,ydirbd

Directories of the files with initial and boundarydata, resp.

lchkini,lchkbd

To write check values of data read to the fileYUCHKDAT

lana_qi,llb_qi

To specify, whether cloud ice qi is in the initial(ana) field and / or in the lateral boundary field

lana_qr_qs,llb_qr_qs

The same for rain qr and snow qs

lana_qg,llb_qg

The same for graupel qg

This group defines parameters for input (not only GRIB!)


Input / Output: /GRIBOUT/

ydir Directory of the output fileslcheck To write check values to the file YUCHKDATyvarml(:) List of model level variables for outputyvarpl(:) List of pressure level variables for outputyvarzl(:) List of z-level variables for outputhcomb(:) Triplet to specify start, stop and increment for

outputydomain To write the full (`f`: default) or a sub (´s`)

domainslon, slat,elon, elat

Definition of subdomain in rotated coordinates

This group defines parameters for output (not only GRIB!)This group can occur several times, to specify different kindof output for different model times.


INT2LM: /CONTRL/

ydate_ini,ydate_bd

Initial date and time of the forecast and ofthe forecast from the boundaries

hstart, hstop,hincbound

Start and end of the forecast and incrementfor providing boundaries (in hours)

lgme2lm, lec2lm,llm2lm, lcm2lm

To specify the input model that provides(initial and) boundary data

linitial,lboundaries

To specify, whether initial and / or boundarydata should be computed

lbdclim To provide the boundaries for the climatemode

lfilter_oro To do a filtering of the orography foravoiding numerical problems

Basic control:


INT2LM: /GRID_IN/

ni_gme, i3e_gme Resolution and vertical grid size for GME

ie_in_tot,je_in_tot,ke_in_tot

Grid specifications for other models thanGME

startlat_in_tot,startlon_in_tot

dlon_in, dlat_in

pollat_in,pollon_in

This group specifies the characteristics of the input model:


INT2LM: /LMGRID/

startlat_tot,startlon_tot

Rotated latitude and longitude oflower left grid point

dlat, dlon Resolution (grid spacing) indegrees

pollat, pollon Geographical latitude / longitudeof rotated north pole

ielm_tot,jelm_totkelm_tot

Horizontal and vertical grid size (ingrid points)

Definition of model domain (same as in the COSMO-Model):


INT2LM: /DATA/

ylmext_cat,yinext_cat

Directories of external fields for COSMO-and input model

ylmext_lfn,yinext_lfn

Names of the files for external fields forCOSMO- and input model

ylmext_form_read,yinext_form_read

To specify the format of these files(`grb1`,`ncdf`)

ie_ext, je_ext Size of the external field for the COSMO-Model (in grid points)

ylm_cat, yin_cat Directories where to write the results andwhere to read the input data

yin_form_readylm_form_write

To specify the format of input and outputfiles (`grb1`,`ncdf`)

This group controls the input and output:


Coming to an END

• This presentation should have given you an overview on the different parts and components of the COSMO-ModelSystem.

• During this week you will learn more on the theoreticalaspects for the dynamics, physics and additional components.

• You will also get some practical experience for installingthe source code and running the necessary programsduring the „Tutorials“.

• We are happy to take your comments and suggestions!

overview on the cosmo-model system - clm-community - … · which did not show up on the last slide...

Documents