MEDUSA-Training-How-to-run-MEDUSA-1D-(-on-NOC-linux-system).md

@@ -62,6 +62,21 @@ cd MEDUSA_git
 
 ![image](uploads/384704d03849bd12c9a1bac68759cd0b/image.png)
 
+* `MEDUSA_resources` includes :     
+  ![image](uploads/b0cd9df3250566afcf7352595e498c6e/image.png)   
+  with 
+  * **`src`** : where all the `fortran` code files are; 
+  * **`cfgs`** : where ready-to-compile configuration are stored   
+  * **`arch`** : files used to compile
+  * **`sette`** : some automatic stability tests (used for development purpose)  
+  * **`README.md`** : the `MEDUSA git` home page documentation
+  * **`add_msa_to_nemo`** : script to put MEDUSA at the right place
+* `nemo` is the NEMO code :   
+  ![image](uploads/7bcef083d7366f47fc1ff7ff67b940a1/image.png)   
+  We find the same architecture than in `MEDUSA_resources` (because `MEDUSA` is made to fit in NEMO by replicating it's structure, ...) plus :
+  * **`makenemo`** : The compilation script -- compilation is used to create an **executable** we'll be able to run, from all our `fortran` code (if you do some changes in a `fortran` file, it will only be taken into account at run time if you recompile the code).
+   
+
 Here, `NEMO` and `MEDUSA` have both been downloaded, but `MEDUSA` is outside of `NEMO`. We need to put the different parts are the right place.   
 That's what `add_msa_to_nemo` is for. So let's run it:    
 
@@ -101,8 +116,12 @@ We'll do both, because doing it the "old Way" you should better understand how t
 ## Compiling MEDUSA 1D "the easy way"
 
 To make things easier, and reduce the risks of error, i've added a MEDUSA 1D reference configuration : `C1D_MED_PAPA`. That means that you just need to compile it to get MEDUSA running in 1D.   
+```sh
+cd nemo
+```
+
+`nemo` is your NEMO4.2 base directory (i might refer to it as `${NEMO}` later on, it is the directory with `makenemo` inside.
 
-From your NEMO4.2 base directory (should be something like `${NEMO}` defined just above, but of course, adapt to your own medusa path).
 
 * Now you can compile your MEDUSA 1D configuration -- valid whatever the machine -- type : 
   ```sh
@@ -110,6 +129,15 @@ From your NEMO4.2 base directory (should be something like `${NEMO}` defined jus
   ```
   It should compile successfully the dynamic and the passive tracer all at once. Here our 1D config is called `C1D_MED`. Compiling this way, All the files are at the right place already, so - still, double check - you should be able to happily skip the file management part of the next section. 
 
+Once compiled, You have a new directory: `C1D_MED` in `nemo`'s `cfgs` directory :  
+Let's have a look: 
+![image](uploads/1139657de150fd2c241e99bffcf7af74/image.png)  
+with :    
+* **`BLD`** : where the code is compiled for this config.
+* **`MY_SRC`** : specific fortran code used instead of those in the `src` directory
+* **`WORK`** : All fortran files used in the compilation process.
+* `cpp_C1D_MED.fcm` : list of compilation keys used for this config.
+* **`EXP00`** : a minimalist,ready to use, **running directory** 
 
 ## Compiling MEDUSA 1D "the old way"
 
@@ -149,14 +177,28 @@ Modify our new config component and cpp keys. At the moment they are based on `C
    ```sh
    ./makenemo -m auto -r C1D_MED -j 16
    ```
+
 # The Running Directory 
 
+Let's have a look at `EXP00` :    
+![image](uploads/4c60e162d316d0ba451334dade628b62/image.png)
 
+we can see :   
+* some `xml` files. These are from the **`XIOS`** software. it's been developed to manage the outputs of the model. The files we (users) have to know about are: 
+  * `context_nemo.xml` : tells which field-def and file-def files are used at run time.
+  * `field-def*.xml` : define **ALL** possible outputs/diagnostics the model needs to know about. All those we could possibly ask for, they are defined here.
+  * `file-def*xml` : where **we** tell what outputs we want, and the frequency! `XIOS`, as you'll see, is very flexible!
+* `namelists`: Namelists are where give information to the model. `NEMO-MEDUSA` will read the namelists at run time, to know parameter values, initial files name and location, forcing files name and location, etc. There are 2 kinds of namelist for each model component: `ref` and `cfg`.
+  * `ref` are the default values. you **should not** modify them. 
+  * For good practice and clarity, the `cfg` namelist should only contain the modified parameters. This helps to "easily" know what a run is doing.
+* `nemo` : Our executable.
+
+We still miss few things to be able to run the model. Of which, initial conditions and forcing fields.  Let's do a first run with a "ready to use" set-up. 
 
  
 # Running MEDUSA 1D
 
-## Running The PAPA "ready to use" config.
+## Running The PAPA "ready to use" set-up.
 
 From here, NEMO-Executable is ready, but we still need to include MEDUSA's namelist and other files to be able to run it.
 * go into `cfgs/C1D_MED/EXP00`.
@@ -212,15 +254,22 @@ From here, NEMO-Executable is ready, but we still need to include MEDUSA's namel
    wget https://zenodo.org/record/3386310/files/INPUTS_C1D_PAPA_v4.0.tar?download=1  
    tar xvf 'INPUTS_C1D_PAPA_v4.0.tar?download=1'
    ```
+   If `wget is not available on your system (it wasn't when i did my tests) you can grap it from my directory :   
+   ```sh
+   cp /noc/users/jpp1m13/WORKING/MEDUSA2/MEDUSA_git/nemo/cfgs/TEST_MED1D/EXP00/INPUTS_C1D_PAPA_v4.0.tar\?download=1 .
+   tar xvf 'INPUTS_C1D_PAPA_v4.0.tar?download=1'
+   ```
+
    The namelist are already adapted for these forcing and initial fields.
 1. In our test MEDUSA starts from constant values. you can change that by extracting the right profile from a trc restart file.     
 
-Now you can run with `./nemo`
+Now you can run with `./nemo &`
 
 ## Running from 3D-extracted conditions.
 
 ### Prepare your running directory :  
 
+You might want to run in different locations...    
 For this we'll use 3D initial conditions and forcings from UKESM1.1.   
 Let's make a new running directory :  
 * go to `cfgs/C1D_MED/`
@@ -232,8 +281,8 @@ cd EXP_1D
 ```
 * Copy and run the appropriate `COPY_ME` bash script that will prepare you running directory for the 1D runs forced with UKESM1 :   
 ```sh 
-cp ${SETTING_RUN_DIR}/COPY_ME__NEMOMED-4.2_1D_UKESM1_405.sh .
-./COPY_ME__NEMOMED-4.2_1D_UKESM1_405.sh 
+cp /noc/users/jpp1m13/SCRATCH/SETTING_RUNNING_DIR/1D_NOC_LINUX/COPY_ME__NEMOMED-4.2_1D_UKESM1.sh .
+./COPY_ME__NEMOMED-4.2_1D_UKESM1.sh 
 ```
 
 ### Extract the initial conditions and forcings 
@@ -287,7 +336,12 @@ Here, all is ready to run 10y, with 5days frequency outputs.
 
 Finally, to run :   
 ```sh
-sbatch hetjob_ORCA1
+./nemo &
+```
+
+Once your model is running, you can see what it's doing with:    
+```sh
+tail -f ocean.output
 ```
 
 ### Running in high latitudes.
@@ -333,3 +387,27 @@ Here are the additional steps needed if you need to run with the ice model `ON`.
        <file_definition src="./file_def_nemo-medusa.xml"/>  <!--  NEMO ocean biology       -->
    ```
 From there you should be ready to run 1D with the ice model activated. 
+
+# Viewing your Outputs
+
+Your run successfully finished! 
+you now have some `netcdf` outputs :    
+![image](uploads/0cb7c230bec8f76e89be7ce5a2bf639e/image.png) 
+
+* the `grid` files are `NEMO` outputs,
+* `ptrc-T` are MEDUSA main tracers
+* `diad-T` are MEDUSA diagnostics (there are a lot...!)
+
+to see them easily, you can use `ferret`:    
+```sh 
+module load ferret
+ferret
+```
+if ferret is not available, you can log on another linux-machine like `theia`. To use ferret, just :      
+``` sh
+use $file_name
+show data ## to see the data
+shade var[k=1,l=1]
+```
+here i plot the surface of a 3D variable (k=1) and if there are several time record, l=1 ask to plot the first
+i'll show you more on the training, but if you're used to matlab or python, do not hesitate to use your own thing ;)
\ No newline at end of file