Log In | Users | Register
Edit | Attach | New | Raw | Diff | Print | | Tools
You are here: COSMO » RcmCosmophd


Running COSMO(-CLM)

What is the difference between a laf and lbf?

Which one is used for what? Can I start a simulation with a lbf? version: not relevant; date: 03.09.2012

A laf (Analysis) is a file containing the standard prognostic variables (T, PP, U, V, W, QV, ...) and also the constant fields (HSURF, FIS, ...) and additional "external parameters" fields (PLCOV, ROOTDP). A lbf (Boundary) is a file containing only the standard prognostic variables. A laf is usually used to start the simulation, i.e. as Initial Condition (IC), whereas a lbf is used as Boundary Condition (BC). It is also possible to use laf as BC. It is not possible to use a lbf to start the simulation.

What to take care of when changing the (spatial) resolution?

version: not relevant; date: 03.09.2012

You should at first adapt the time step (in INPUT_ORG). Then you might consider switching some parameterization on/off (e.g. convection parameterization at very high resolution).

How to use the restart files?

version: not relevant; date: 03.09.2012

Set these parameters properly in your namelists:

  ydate_ini = 'date',
  hstart = x

If you have a restart file for the 1st of January 2006 00UTC and you have boundary conditions each 6 hours, then you have to give:

  ydate_ini = '2005123118',
  hstart = 6

It means that the initial date (ydate_ini) is hstart hours earlier than the date for which you have a restart file available (and at which you would like to start the simulation). hstart and thus ydate_ini should be set according to the frequency at which you have boundary data available.

Note: boundary data for the initial date (in this example for the 31st of December 2005 at 18UTC) have to be provided!

Why do I get a square pattern/bias in my simulation output where the number of squares varies with the number of processes?

version: not relevant; date: 25.03.2013

  • 1) The domain might be not correctly partitioned and distributed to the CPUs. The routine which is responsible for this is "distribute_field" and stored in "parallel_utilities.f90". So for some reason in your setup this routine might not be correctly called or not where/when it is needed. The routine itself works fine. Alternatively, it is not called enclosed by "if ( my_cart_id == 0) then". This is needed because only CPU 0 should call it.
This problem is rather not expected to show up for a default setup of the model. It has been observed for idealized setups, however. Also, it might appear if you read in data on your own or made some modifications (or if you are using a very new module which is not yet debugged very well:-), then the mentioned routine needs to be called first after reading in your data.
  • 2) Those problems occur if something is wrong with the update of the halos surrounding each processor. Multiple issues can pop up.
    • 2a) Some stencil (e.g., advection, horizontal diffusion, compt. of deformation, etc.) will require a certain amount of points from within the halo. Thus, the Halo needs to be updated appropriately at the end of the time step, otherwise -> stripes
    • 2b) A parameter might be computed during one timestep on a grid including some Halo points. Later during that same time step, a tendency is computed from, e.g., a horizontal divergence of this parameter. If the parameter was computed on a grid not large enough, the operator will not have enough updated points available and again -> stripes
More recently released COSMO versions should probably be free of such flaws. The routine explicit_horizontal_diffusion does have bugs in old versions.
  • 3) Some problem with array indices:
    • 3a) Exceeding of array boundaries leads to arbitrary values being included in your calculations which vary with the processor. After compiling with debugging options there is a good chance of getting a warning/error if this happens.
    • 3b) Check your output for other patterns apart from the square, e.g. mirror effects (within the squares). This hints to screwed index order and may cause the square pattern by flapping of the boundary regions.

Coding in COSMO(-CLM)

How to add a new variable to the COSMO code?

version: not relevant; date: 03.09.2012

  • First of all, in case you want to introduce a new diagnostic variable, think about the option to compute it outside the COSMO code in a post-processing step.
In some case this option might be better (e.g. if you need the temperature in ° celsius, there is no reason to add a new variable to the COSMO code and you can simply convert the temperature written out in the COSMO outputs from Kelvin to ° celsius using e.g. the nco tools).
  • The answer also depends on the version that you are using.
  • If you are using a version previous to COSMO5.0, then you will have to do quite some work. You will have to:
    • declare your variable in data_fields.f90
    • allocate and deallocate your variable in src_allocation.f90
    • add your variable to the var structure in src_setup_vartab.f90 (in case you want to read or write this variable)
    • in case your variable should be a prognostic variable (and not only a diagnostics), you will also have to:
      • add your variable to the lists (in organize_data.f90):
        • pp_restart%yvarml, pp_restart%yvarpl and increase the numbers pp_restart%nyvar_m and pp_restart%nyvar_p (in case you want to read/write your variable from/to a restart file)
        • yvarini_d (in case you want to read your variable from a file for the initial condition)
        • yvarbd_d (in case you want to read your variable from a file for the boundary condition)
      • perform boundary relaxation in src_relaxation.f90 (in case you have "real boundary conditions" and not periodic boundary conditions)
      • advect your variable in src_advection_rk.f90 or/and in src_leapfrog.f90 (! be careful when doing this especially in Leapfrog because not all variables are advected the same way)
      • update your field using the boundaries in lmorg.f90
      • perform horizontal diffusion in hori_diffusion.f90
      • handle the turbulent mixing in src_slow_tendencies_rk.f90 or/and in slow_tendencies.f90 (! if you choose to have a surface value as bottom boundary condition, you have also to declare, allocate/deallocate, fill the var structure for this field)
      • perform additional processes (e.g. passive transport by convection, microphysics, chemistry, ...)
See this presentation for more details.
  • In case you are using COSMO5.0 or a higher version, the tracer module can simplify this task greatly for prognostic variables.
Instead of doing all the steps mentionned above, you can simply make a call to the subroutine trcr_new with the correct arguments and then directly perform the additional processes (microphysics, chemistry, ...). The declaration, allocation/deallocation, the management of the restart, boundaries, initial conditions, the advection, turbulent mixing, horizontal diffusion, the field update, the passive transport by convection are done automatically, depending on the arguments that you have chosen when calling trcr_new. See the COSMO technical report N° 20 for more information.
  • Irrespective to the model version you have chosen, you have to make sure that you implement your variables and the rest of your developments in a modular way. Please define for example a new namelist switch or include your developments between CPP keys, in order to be able to switch on/off your development or even to compile the code with/without your development. It is very important to have the possibility to compute also WITHOUT your development.

Where is advection coded in COSMO?

version: not relevant; date: 05.10.2012

It is coded in src_advection_rk.f90 and in src_leapfrog.f90.

How do I create my own diagnostic variable?

version: not relevant; date: 10.10.2012

Before implementing a new variable in the code consider postprocessing. If it is easily obtained by a simple formula, calculate it with COSMO output (e.g. theta(p,T)). If it is a more involved calculation, which is performed by COSMO anyway and you want to store the result in a variable for output proceed as follows: * in src_setup_vartab.f90: 1) declare the variable 2) create an entry in the table 3) set idef_stat = -1 * in src_allocation.f90: 1) Add it to the declarations 2) complete the allocation / deallocation * in data_fields.f90: 1) Add your variable there Then you can use the variable in every routine you want by adding it with the USE data_fields, ONLY ... statement. Maybe you also have to add the variable in organize_data.f90 /src_output.f90 if you want to be able to output it. For e.g potential temperature (POT_TEMP) add in src_output.f90: ELSEIF ( ylist(n)(1:izlen) == 'POT_T' ) THEN kbot = 1 ktop = ke CALL calc_Theta_Tppp( t(:,:,:,itl ), pp(:,:,:,itl ), p0, & ie, je, ke, r_d, cp_d, zvarlev(:,:,1:ke)) somewhere between the ELSEIF statements around line 1600 in Section 3.

Add prognostic variable?

version: previous COSMO5.0; date: 10.10.2012

In case you want to introduce a prognostic variable into COSMO, you have to do exactly what Lukas described (i.e. same procedure as for a diagnostic variable) but you will generally also have to do additional steps: a. Add your variable to several lists in organize_data.f90: * restart: pp_restart%yvarml, pp_restart%yvarpl and increase the numbers pp_restart%nyvar_m and pp_restart%nyvar_p * initial conditions: yvarini_d * boundary conditions: yvarbd_d b. Advect your variable in src_advection_rk.f90 or/and in src_leapfrog.f90 c. Update your field using the boundaries in lmorg.f90 d. Perform horizontal diffusion in hori_diffusion.f90 e. Do boundary relaxation in src_relaxation.f90 f.  Handle the turbulent mixing in src_slow_tendencies_rk.f90 or/and in slow_tendencies.f90 g. Perform additional processes (e.g. microphysics, chemistry, transport by convection, ...) This is valid for COSMO versions prior to COSMO5.0. Starting from COSMO5.0, it should be more easy. The procedure described here is valid for real cases (i.e. 3D model with boundary relaxation and so on). I don't know how this procedure should be adapted in case of 2D simulations or in case of idealized simulations (with periodic boundary conditions). 

Parameterizations in COSMO(-CLM)

What should I use as cloud scheme? A statistical one or a physical one?

version: not relevant; date: 03.09.2012

There is no general answer.

Error messages in COSMO(-CLM)

I get an error code of xxxx (e.g. 8102). How can I find out what that means?

version: not relevant; date: 03.09.2012

First of all, try to understand the error message which is delivered in the standard error/output. If the error message is not clear, just go into the source directory (/src) and grep the error code (e.g. grep 8102 *). In this way, you will find the code section which is handling the error. Try to understand what is going on in this code section and what could be the cause of the model abort. You can also insert print statements in this code section to better understand what is happening. If you nevertheless don't manage to understand, have a look at the rest of this section "Error messages" and try to find if this error code/message is reported there. If all of this didn't help and you are desperate, contact me smile

List of cryptic error messages

Error message Associated error number (if any) Meaning/"Solution"
Caught signal Terminated, sending to application   You killed your job or you have not requested enough time for your job (valid for CSCS).
PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED IN ROUTINE: organize_output 2033 check that you have removed your old restart files before having run the simulation
NetCDF: Invalid dimension ID or name 8102 My file for initial conditions (first laf) was not complete. I erroneously took an aerosol emission file instead of a complete laf. These attributes should be contained in the laf: number of gridpoints in the latitude and in the longitude directions, number of levels, number of soil levels, current date, coordinates of the lower left grid point, grid resolution. I just had some of them in my emission file.
Wrong filename specified
Fatal error in MPI_Recv: Message truncated, error stack: MPI_Recv(186).............................: MPI_Recv(buf=0x2aaad1b03020, count=230388, MPI_BYTE, src=0, tag=12345, comm=0xc4000006, status=0x1a3e780) failed MPIDI_CRAY_ptldev_recv_event_handler(1652): Message truncated [NID 00032] 2010-08-05 15:55:33 Apid 40273: initiated application termination Application 40273 exit codes: 1 Application 40273 exit signals: Killed - Wrong number of gridpoints in the Namelist (ie_tot, je_tot)!

This site is managed by the Center for Climate Systems Modeling (C2SM).
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems? Send feedback!