diff --git a/ICON-NWP/bacy.md b/ICON-NWP/bacy.md index a83615820cda6e563868d2d99c48560e6cbf9501..cde7a6435a39c856f70413fb553c3d1e1bb26c23 100644 --- a/ICON-NWP/bacy.md +++ b/ICON-NWP/bacy.md @@ -3,36 +3,24 @@ cycles with ICON. It is modular in structure with each module performing steps like computing the dynamical model evolution (more), data assimilation (core), surface, snow and sea surface analysis. -################################################################################### - BACY_1.0 -################################################################################### - +# BACY_1.0 This document gives you a short introduction into the usage of BACY_1.0. A detailed userguide and further documentation is available at 'git@gitlab.dkrz.de:dace/dace_doc.git' under dace_doc/org/dace_bacy.git and is continuously being updated. - -=================================================================================== - How to get BACY_1.0? -=================================================================================== - +## How to get BACY_1.0? BACY_1.0 is under version control using 'git'. To obtain BACY_1.0 from the remote repository 'git@gitlab.dkrz.de:dace/dace_bacy.git' the following steps on your local machine are necessary: - - git clone git@gitlab.dkrz.de:dace/dace_bacy.git <my_bacy_name> - cd <my_bacy_name>/modules - ./copy_defaults.sh - -=================================================================================== - How to use BACY_1.0? (Overview) -=================================================================================== - ------------------------------------------------------------------------------------ - Modules ------------------------------------------------------------------------------------ - +~~~ +git clone git@gitlab.dkrz.de:dace/dace_bacy.git <my_bacy_name> +cd <my_bacy_name>/modules +./copy_defaults.sh +~~~ + +## How to use BACY_1.0? (Overview) +### Modules BACY_1.0 pursues a MODULAR CONCEPT. Each MODULE is an self-sufficient unit. The only contact points to its environment are realized by INTERFACES. These are the directories 'iodir/input' and 'iodir/output' which are @@ -57,19 +45,17 @@ which rely on NAMING CONVENTIONS, classification of variables, etc., which are IMPORTANT to maintain the modular concept. In summary: to run a module stand-alone, the following steps are necessary. - - prep_<module> [-h] [-d] arg1 ... argn - <module> [-h] [-d] arg1 ... argn - save_<module> [-h] [-d] arg1 ... argn +~~~ +prep_<module> [-h] [-d] arg1 ... argn +<module> [-h] [-d] arg1 ... argn +save_<module> [-h] [-d] arg1 ... argn +~~~ The option [-h] gives you an explanation of the usage of the script and the option [-d] calls the script in a dry-run, meaning that no jobs will be submitted. ------------------------------------------------------------------------------------ - A cycle ------------------------------------------------------------------------------------ - +### A cycle The module 'cycle' plays a special role and cannot be understood as a module in the usual sense (see above). The main difference is the absence of the 'input', 'output' and 'run' directories. The purpose of 'cycle' is the provision of an