Top Menu

Jump to content
  • downscale
    • View all projects
Home
    • Work packages
    • News
    • Getting started
    • Introduction video
    • Welcome to OpenProject

      Get an overview

      Get a quick overview of project management and team collaboration with OpenProject.
      You can restart this video from the help menu

    • Help and support
    • Upgrade to Enterprise Edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support

    • Additional resources
    • Data privacy and security policy
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

Side Menu

  • Overview
  • Activity
  • Work packages
  • News
  • Repository
  • You are here:Wiki main page
    • Table of contents
      • Hierarchy leafGravimetric humidity bias on 2008-04-07, 05 UTC
      • Expanded. Click to collapseCollapsed. Click to showWiki main page
        • Expanded. Click to collapseCollapsed. Click to showCoarse data
          • Hierarchy leafCoarse external data
          • Hierarchy leafIntroduction of new data
          • Hierarchy leafTemperature
        • Hierarchy leafDependencies
        • Expanded. Click to collapseCollapsed. Click to showExchange of variable fields
          • Hierarchy leafnamcouple
          • Expanded. Click to collapseCollapsed. Click to showSchomburg scheme
            • Expanded. Click to collapseCollapsed. Click to showSchomburg rules
              • Hierarchy leafSchomburg rule
        • Expanded. Click to collapseCollapsed. Click to showFine data
          • Hierarchy leafEstimated resolutions
          • Expanded. Click to collapseCollapsed. Click to showFine external data from the Climate Limited-area Modeling community
            • Hierarchy leafDivided by 7
            • Hierarchy leafEmulation of the test data resolution
          • Hierarchy leafSRTM data
        • Hierarchy leafIntroduction
        • Hierarchy leafLiterature
        • Expanded. Click to collapseCollapsed. Click to showModel1
          • Hierarchy leafDeprecated dummy data
          • Hierarchy leafDummy coordinates
          • Hierarchy leafProcessing
          • Expanded. Click to collapseCollapsed. Click to showRead_grib1
            • Hierarchy leafEccodes_handler
        • Hierarchy leafNaming schemes
        • Hierarchy leafOASIS3
        • Hierarchy leafPrivacy policy
        • Hierarchy leafTitle page
        • Expanded. Click to collapseCollapsed. Click to showValidation
          • Expanded. Click to collapseCollapsed. Click to showPreservation of the sub-scale average
            • Expanded. Click to collapseCollapsed. Click to showBias anecdote for gravimetric humidity
              • Hierarchy leafGravimetric humidity bias on 2008-04-04, 18 UTC
            • Expanded. Click to collapseCollapsed. Click to showBias anecdote for surface pressure
              • Hierarchy leafSurface pressure bias on 2008-04-04, 18UTC
              • Hierarchy leafSurface pressure bias on 2008-04-07, 05UTC
            • Expanded. Click to collapseCollapsed. Click to showBias anecdote for temperature
              • Hierarchy leafTemperature bias on 2008-04-07, 05UTC
              • Hierarchy leafTemperature bias on 2008-04-04, 18UTC
            • Hierarchy leafgrib2bin.pl
          • Hierarchy leafSpatial average and variance before and after downscaling
        • Expanded. Click to collapseCollapsed. Click to showWhat the Community Land Model requires
          • Hierarchy leafsva_DWD_forcing.ncl
You are here:
  • Wiki main page
  • Exchange of variable fields

Content

Exchange of variable fields

  • More
    • Table of contents

The coupler OASIS3 means for its coupled models to be run in parallel. Dedicated procedures must therefore conduct the exchange of fields. OASIS3 provides 6 modules[6] of them including prism_def_var_proto, prism_get_var, etc. The coupler requires further preparations: The size of the domain to be downscaled is hard-coded into model1.F90, model2.F90 and namcouple.

In model1 and model2, there each are variables called nlon and nlat, which must be set to the number of different longitudes and latitudes, respectively. Model1 needs those of the predictor fields, model2 those of the fine external data. The namelist of OASIS3 is
source:data_oasis3/namcouple
which, in its 2nd part, below ‘$STRINGS’, declares the exchangeable fields. It lays the groundwork for 18 transferable fields in its ‘$NFIELDS’ section, even though model1 uses 19.

Formatting of namcouple

source:data_oasis3/namcouple
Comment lines starting with ‘#’ are always allowed, blank lines are always forbidden.

Simulated time

Under the heading ‘$RUNTIME’, OASIS3 expects the total time to be modeled, in seconds. The number is framed with ‘#begin PM’ and ‘#end PM’ and is a frequent number to change. It does not have to be divisible by any coupling time period, specified in the following section.

The time may have only 8 digits. Since Model1 and model2 both require the simulated time to be given in hours, the maximal useful setting here is 99 997 200 s = 27 777 h = 1 157.375 days, which equal 3 years and about 2 month. This maximum is imposed in the entire project.

Introducing the fields ($STRINGS)

Please refer to:
http://www.cerfacs.fr/oa4web/oasis3/oasis3doc/node33.html

In inappropriate brevity, the 2nd part of namcouple, after ‘$STRINGS’, is a list of variables, and every variable gets five lines:

  1. The names of the field when viewed (1) from the sender, (2) from the receiver, the index of the variable in the supplement source:data_oasis3/cf_name_table.txt , the coupling time period in seconds, the number of words in line 4, the name for a potential restart file, the word ‘AUXILARY’ in this improper spelling, or the word ‘EXPORTED’. AUXILARY variables never leave OASIS3, but affect the EXPORTED variables who do.
  2. The length of the dimensions with first dimensions first (1) as seen from the sender and (2) as seen from the receiver. After this, two prefixes and a ‘SEQ’ setting.
  3. Four single character settings regarding parallel computing
  4. The transformation(s) the field has to undergo before sending.
  5. Additional arguments for the transformations.

Standards for downscal

These specific standard names in this sense follow a convention, see below. The other standards are:

  1. 2 standard names, ‘10 7200 1 fd001.nc’, and the word ‘EXPORTED’ in case of active variables at the lowest layer or else ‘AUXILARY’
  2. The sizes after the internal partitioning of the variables in Model1, ‘gmd1 gmd2 SEQ=1’
  3. ‘P 0 P 0’ These are zeros, not capital o.
  4. ‘DOWNSCAL’
  5. ‘SKOMBURG LR SCALAR’ and another word naming the variable to choose the appropriate Schomburg rule, e.g. ‘PRESKE1’ for pressure, ‘GSPRE’ for subsidence-scale precipitation or ‘CVPRE’ for convective-scale precipitation. The latter is never the same.

All standard names for line 1 are 8 characters long, the allowed maximum for OASIS3.

Any name as seen from sender begins with ‘S’. If it is AUXILARY, an ‘A’ follows, else ‘D’.
If Model1 is the sender, the next characters are ‘_M1_’, else ‘_M2_’. The remaining 2 characters are a serial number, padded with 0 if smaller than 10.

The receiver names follow much of the same standards as the sender names. The 1st character, though, is always ‘R’. The model specification in the middle, e.g. ‘_M2_’, refer to the receiver model now. Thus, they are just the opposite of the model spec in the corresponding sender name. The serial number is the same.

Footnotes

fn1^. Namely:

  1. mod_kinds_model
  2. mod_prism_proto
  3. mod_prism_def_partition_proto
  4. mod_prism_put_proto
  5. mod_prism_get_proto
  6. mod_prism_grids_writing

For all details, confront:
http://www.cerfacs.fr/oa4web/oasis3/oasis3doc/node9.html

Loading...