Planets - User contributions [en]

Quick Install and Run Mars PCM

2026-02-25T16:10:24Z

Jorge:

In this page we give a hopefully exhaustive enough overview of the necessary prerequisites and steps to download, compile and run a simple simulation with the Mars PCM, set up on a Linux computer.

Note that there is a dedicated, install script, that attempts to do all these steps (up to and including running the simulation) that you can obtain here: https://web.lmd.jussieu.fr/~lmdz/planets/install_lmdz_mars.bash
Automating the process is not trivial as there are many subtle variants of Linux flavors and user account setups, so the script may fail in your case, but hopefully the information given in this page should help you solve the encountered problems.

== Prerequisites: Tools and Libraries ==
In order to use (i.e. compile and run) the GCM, one needs to have some tools and installed libraries at hand. We list below a (minimal) set that you should check that is available and/or that you'll need to first install on your machine. Note that we assume in this tutorial that you are on a Linux native-OS/cluster.

=== Fortran compiler ===
The GCM source code is in Fortran. One thus needs a Fortran compiler to build (compile) the executable.
The most easily available one (on Linux) is gfortran and examples discussed here will assume it is the one used.
You can check that you indeed have a gfortran compiler at hand with the following Bash command:
<syntaxhighlight lang="bash">
which gfortran
</syntaxhighlight>
which should return something like
<syntaxhighlight lang="bash">
/usr/bin/gfortran
</syntaxhighlight>

=== Subversion ===
The source code is managed using subversion (svn), which you'll need to download or update. Leaving aside the subtleties of svn and code organization for now, downloading the code amounts to doing the following:
<syntaxhighlight lang="bash">
svn checkout https://svn.lmd.jussieu.fr/Planeto/trunk --depth empty
cd trunk
svn update LMDZ.COMMON LMDZ.MARS
</syntaxhighlight>

As a side note: the source code that will be fetched by svn can also be browsed online here: https://trac.lmd.jussieu.fr/Planeto

=== FCM ===
The FCM (Flexible Configuration Management) tool is a suite of perl scripts to help building and managing codes. We use a slightly modified version which can be obtained using subversion (svn). Ideally you'll want to download it somewhere on your computer once in for all. To do this:
<syntaxhighlight lang="bash">
svn checkout https://forge.ipsl.jussieu.fr/fcm/svn/PATCHED/FCM_V1.2
</syntaxhighlight>
You'll then need to add the resulting FCM_V1.2/bin to your PATH environment variable so that the command "fcm" may be used from anywhere on your machine. e.g. by adding the following line in your .bashrc:
<syntaxhighlight lang="bash">
export PATH=$PATH:$HOME/FCM_V1.2/bin
</syntaxhighlight>
The assumption here is that the downloaded FCM_V1.2 directory is in your home ($HOME) directory. Adapt accordingly if not.

=== the NetCDF library ===
The GCM reads and writes input and output files in NetCDF format. Therefore a NetCDF library must be available. As this library is not quite standard you'll probably have to install it yourself on your system (check out [[the netCDF library]] page for more). You can use the following home-made "install_netcdf4_hdf5_seq.bash" script to do so. For this, ensure that you are in your home directory:
<syntaxhighlight lang="bash">
mkdir netcdf
cd netcdf
wget -nv --no-check-certificate http://www.lmd.jussieu.fr/~lmdz/pub/script_install/install_netcdf4_hdf5_seq.bash
chmod u=rwx install_netcdf4_hdf5_seq.bash
./install_netcdf4_hdf5_seq.bash > netcdf.log 2>&1
</syntaxhighlight>
Compiling the library and dependencies can take a while (>>15 minutes; be patient).
Once this is done, check file netcdf.log to verify that all went well.
You may want to also add its "bin" directory to your PATH environment variable by adding in your .bashrc a line of:
<syntaxhighlight lang="bash">
export PATH=$PATH:$HOME/netcdf/bin
</syntaxhighlight>
The assumption here is that you have run the "install_netcdf4_hdf5_seq.bash" script in a "netcdf" subdirectory of your home directory. Adapt accordingly if not.

As a side note: The NetCDF library provides a very simple command line tool (ncdump) to inspect the contents of NetCDF files, but you'll need more advanced visualization tools (e.g., Panoply, Python scripts, etc. - see further down this page in the "Checking the Results" section) for more advanced post-processing of the outputs.

=== the IOIPSL library ===

The IOIPSL (Input/Output IPSL) library is a library designed to handle both the reading of some input files used by the GCM (the *.def files which are described further below) and the writing of some NetCDF output files.

==== Prior to a first compilation: ksh to bash conversion ====
Some of the IOIPSL install scripts are written in ksh (Korn shell).
Given that most systems currently use Bash (Bourne Again Shell) as their command-line interpreter and not ksh (Korn Shell), you might need to install ksh on your system (assuming you have super-user privileges), for e.g., on Linux-Ubuntu:
<syntaxhighlight lang="bash">
sudo apt install ksh
</syntaxhighlight>
Or, if that is not an option, change the occurrences in the package's scripts ('''ins_m_prec''') from:
<syntaxhighlight lang="bash">
#!/bin/ksh
</syntaxhighlight>
to
<syntaxhighlight lang="bash">
#!/bin/bash
</syntaxhighlight>

==== Automated IOIPSL install script ====
Scripts to download and install the IOIPSL library can be found in the "ioipsl" subdirectory of the "LMDZ.COMMON" library. Since here we assume we're working with gfortran, the relevant one is "install_ioipsl_gfortran.bash". If your PATH environment variable is already such that it includes the path to your NetCDF library distribution's bin directory (see previous section) then all you need to do is execute the script:
<syntaxhighlight lang="bash">
./install_ioipsl_gfortran.bash
</syntaxhighlight>
If all went well the script should end with:
<syntaxhighlight lang="bash">
OK: ioipsl library is in ...
</syntaxhighlight>

''(for further details about [[The_IOIPSL_Library|the IOIPSL library]] and installing it, follow the link and/or use the Search Box at the top of this page)''

== GCM Input Datafiles and Datasets ==
In order to run, the GCM needs some inputs, such as initial conditions (values of state variables), external inputs (e.g. optical properties of aerosols) and simulation setup (e.g. specifications on how long to run, which parametrizations should be activated, etc.)

In the spirit of the illustrative example considered here (an "GCM6" simulation, i.e. simulation including CO2, dust and water cycles with a model top around 120 km), a set of necessary input data may be downloaded (note that a few reference cases are available on https://web.lmd.jussieu.fr/~lmdz/planets/mars/ ) with:
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate http://www.lmd.jussieu.fr/~lmdz/planets/mars/reference_GCM6_64x48x54.tar.gz
</syntaxhighlight>

Once unpacked ("tar xvzf reference_GCM6_64x48x54.tar.gz") the resulting "reference_GCM6_64x48x54" will contain all that is needed, namely:
<syntaxhighlight lang="bash">
callphys.def diagfi.def run.def startfi.nc start.nc stats.def traceur.def z2sig.def
</syntaxhighlight>
* Initial condition NetCDF files ''start.nc'' and ''startfi.nc''; the first containing initial condition values for the dynamics and the second initial condition values for the physics. These also define the model resolution and number of atmospheric layers (64x48x54 - the compiled GCM binary must match this!)
* Some mandatory ASCII *.def files containing run parameters, namely:
# [[The_run.def_Input_File | run.def]] : "master def file" containing main run parameters
# [[The_callphys.def_Input_File | callphys.def]] : file containing flags and keys for the various physics parametrizations
# [[The_z2sig.def_Input_File | z2sig.def]] : file describing the sought vertical discretization
# [[The_traceur.def_Input_File | traceur.def]] : file specifying the tracer number and names
* Some optional ASCII *def files containing names of variables to output:
# [[The_diagfi.def_Input_File | diagfi.def]] : list of variables that will be included in output file diagfi.nc (if there is no diagfi.def file then ALL variables will be included; you probably don't want that as the resulting file will rapidly grow to be HUGE)
# [[The_stats.def_Input_File | stats.def]] : list of variables that will be included in output file stats.nc (if there is no stats.def file then ALL variables will be included and the resulting file will be large)

== Compiling the GCM ==
Now that all the prerequisites are fulfilled, it is (almost!) time to compile the GCM

=== Prior to a first compilation: setting up the target architecture files ===
Compiling the model is done using a dedicated Bash script ''makelmdz_fcm'' located in the '''LMDZ.COMMON''' directory. This script however relies on ''architecture files''. These files contain information on which compiler to use, what compilation options to use, where relevant libraries are located etc. In practice, one must thus create these ASCII text files in the '''arch/''' subdirectory of '''LMDZ.COMMON'''. The naming convention is rather straightforward, when the script ''makelmdz_fcm'' is run with the option '''-arch somename''', it will look for files ''arch/arch-somename.env'', ''arch/arch-somename.path'' and ''arch/arch-somename.fcm''. Leaving aside a detailed description for later (see [[The_Target_Architecture_("arch")_Files|this page]]), here we mention that:
* the ''arch*.env'' is an optional file containing ''environment'' information, such as setting up environment variables or loading modules on some machines, e.g.
<syntaxhighlight lang="bash">
export NETCDF_HOME=/path/to/the/netcdf/distribution
</syntaxhighlight>
* the '''arch*.path''' is a mandatory file containing information relative to external libraries such as NetCDF and IOIPSL, e.g.
<syntaxhighlight lang="bash">
ROOT=$PWD

NETCDF_LIBDIR="-L${NETCDF_HOME}/lib"
NETCDF_LIB="-lnetcdf -lnetcdff"
NETCDF_INCDIR="-I${NETCDF_HOME}/include"

IOIPSL_INCDIR="-I$ROOT/../IOIPSL/inc"
IOIPSL_LIBDIR="-L$ROOT/../IOIPSL/lib"
IOIPSL_LIB="-lioipsl"
</syntaxhighlight>
Each library is referenced by a fixed identifier (NETCDF, IOIPSL, XIOS, ...) and 3 trailing strings: '''_LIBDIR''', for the path to the library, '''_LIB''', for the library name(s), and '''_INCDIR''' for the path to the library's ''include'' directory.

* the '''arch*.fcm''' is a mandatory file containing information relative to the compiler and compilation options, e.g.
<syntaxhighlight lang="bash">
%COMPILER gfortran
%LINK gfortran
%AR ar
%MAKE make
%FPP_FLAGS -P -traditional
%FPP_DEF NC_DOUBLE
%BASE_FFLAGS -c -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fno-align-commons
%PROD_FFLAGS -O3
%DEV_FFLAGS -O
%DEBUG_FFLAGS -ffpe-trap=invalid,zero,overflow -fbounds-check -g3 -O0 -fstack-protector-all -finit-real=snan -fbacktrace
%MPI_FFLAGS
%OMP_FFLAGS
%BASE_LD
%MPI_LD
%OMP_LD
</syntaxhighlight>
Again, not going into a detailed description (follow [[The_Target_Architecture_("arch")_Files|this link]] for that), just note here that each line corresponds to a keyword (starting with "%") followed by the relevant options. Here, we mention a few of the main ones:
* %COMPILER: The compiler to use (here, gfortran)
* %BASE_FFLAGS: compiler options (always included)
* %PROD_FFLAGS: compilation flags to include if makelmdz_fcm is run with the "-prod" option
* %DEBUG_FFLAGS: compilation flags to include if makelmdz_fcm is run with the "-debug" option
* %BASE_LD: flags to add at the linking step of the compilation

=== Compiling the test case ===
To compile the GCM at the sought resolution, run (in LMDZ.COMMON):
<syntaxhighlight lang="bash">
./makelmdz_fcm -arch local -p mars -d 64x48x54 -j 8 gcm
</syntaxhighlight>
Here, we assume that you have generated the '''arch-local.*''' files as per what is suggested in the previous section.
The options for ''makelmdz_fcm'' used here imply:
* '''-p mars''': the GCM will use the "mars" physics package
* '''-d 64x48x54''': the GCM grid will be 64x48 in longitude x latitude, with 54 vertical levels.
For a glimpse at all the possible ''makelmdz_fcm'' options and their meanings, run:
<syntaxhighlight lang="bash">
./makelmdz_fcm -h
</syntaxhighlight>
and/or check the dedicated [[The_makelmdz_fcm_GCM_Compilation_Script|makelmdz_fcm page]].

Upon successful compilation, the executable '''gcm_64x48x54_phymars_seq.e''' should be generated in the '''bin''' subdirectory.

== Running the GCM ==
To run your first simulation, you first need to have a ''datadir'' at hand, which is a directory containing some input datafiles (e.g. driving dust scenarios, aerosol properties, etc.) that the GCM will need at run time.
<syntaxhighlight lang="bash">
wget -nv --no-check-certificate http://www.lmd.jussieu.fr/~lmdz/planets/mars/datadir.tar.gz
</syntaxhighlight>
And simply, after having un-tarred it
<syntaxhighlight lang="bash">
tar xvzf datadir.tar.gz
</syntaxhighlight>
Link the resulting '''datadir''' directory to where you will run (e.g. the '''reference_GCM6_64x48x54''' directory), for instance if '''datadir''' is along side '''reference_GCM6_64x48x54''', then in the later do:
<syntaxhighlight lang="bash">
ln -s ../datadir .
</syntaxhighlight>
Secondly you need to copy (or move) the executable '''gcm_64x48x54_phymars_seq.e''' from '''LMDZ.COMMON/bin''' to the directory containing the initial conditions and parameter files, e.g. '''reference_GCM6_64x48x54'''.

You can now run the GCM.
This is usually a two-step process: the (optional) first step is to source the environment architecture file (the very same that was used to compile the model), e.g.,:
<syntaxhighlight lang="bash">
source ../LMDZ.COMMON/arch.env
</syntaxhighlight>
The second step is to execute the model, e.g.,:
<syntaxhighlight lang="bash">
./gcm_64x48x54_phymars_seq.e > gcm.out 2>&1
</syntaxhighlight>

With this command line, the (text) outputs messages are redirected into a text file, '''gcm.out'''. It is convenient to keep this file for later inspection (e.g., to track a bug). If there is no redirection (only '''./gcm_64x48x54_phymars_seq.e'''), then the outputs will be directly on the screen.

== Checking the Results of a Simulation ==
Once the simulation is finished, you'll know that all went well ("everything is cool") if the last few lines of the standard text output are:
<pre>
in abort_gcm
Stopping in leapfrog
Reason = Simulation finished
Everything is cool
</pre>

If not, start looking for an error message and a way to fix the problem...

Apart from the standard text output messages from the GCM, which are mostly for monitoring and checking the simulation progress, the user will more likely be interested in checking the contents of the ''diagfi.nc'' file produced by the GCM, as it contains instantaneous values of the main model variables (atmospheric temperature, winds, etc.).

...TODO...ADD HERE SOME ILLUSTRATIVE PLOTS OF THE EXPECTED BENCH OUTPUTS...

== Taking Things to the Next Level ==
See [[Advanced_Topics_Mars_PCM|Advanced use of the Mars PCM]]

The short tutorial presented in this page is meant to be useful to get an overview of what is required to install and run the GCM, in addition to checking the results of a simulation. Moving on to a more intensive and problem-specific usage will require diving into additional topics and aspects such as:
* Selecting the appropriate inputs and run parameters for a given study.
* Compiling and running in parallel (MPI and/or OpenMP) to obtain results in a reasonable time frame.
* post-processing and analysis of model outputs.
All these points and much more are detailed in the many pages of this site (do check out the menu on the left and dare use intensively the site's search engine)!

[[Category:Mars-Model]]
[[Category:Mars-LMDZ]]

Running Mars mesoscale model

2025-04-02T14:43:27Z

Jorge: /* Restarting simulations */

This is page I start to introduce some notes to remind that could be useful for other users (Jorge).

The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-mod-les-atmosph-riques-plan-taires/git-trunk/-/blob/master/MESOSCALE/MANUAL/SRC/user_manual.pdf?ref_type=heads

==Regarding NaNs and parallel running==
The mesoscale model cannot run in parallel in spirit at the moment, it runs but it outputs NaNs everywhere.

When running in a single core, in my case at least it produces NaNs with low output frequency (37) but by increasing the output frequency (6 works for me) it is solved. This is weird but seem to be right.

Increasing the output frequency in parallel runs doesn't work. Even with a frequency of 1 doesn't work.

==Notes on clear input and output files (TBD)==

==Notes on configuration files (TBD)==

===namelist.input===

==Changing vertical resolution==
Before running real.exe, a new levels file needs to be generated. The script to do this is in SIMU/RUN/vert_level_python.

==Smoothing topography in the borders==
This might help sometimes when simulations are breaking, but it didn't work for me so far. This script can smooth the topography in the borders of a wrfinput file.

<syntaxhighlight>
import numpy as np
import xarray as xr
import sys
import os

from scipy.ndimage import gaussian_filter

def smooth_borders(a,margin):
out=np.zeros(a.shape)
for i in range(margin):
if i>0:
b=a[i:-i,i:-i]
else:
b=a[:]
c=gaussian_filter(b, sigma=margin-i)
if i>0:
out[i:-i,i:-i]=c
else:
out=c[:]

return out

margin=int(sys.argv[1])
input_file=sys.argv[2]

#Open file
ds=xr.open_dataset(input_file)

a=ds.HGT.values[0]
a=smooth_borders(a,margin)
ds.HGT.values[0]=a

os.system('mv %s %s_presmooth'%(input_file,input_file))
ds.to_netcdf(input_file)

</syntaxhighlight>

==Restarting simulations==
In the file namelist.input there is the option "restart". The comment for this option says "Output restart files?" but actually it refers to whether or not the simulation should try to start from a previous simulation.
Restart files are periodically saved, this can be configured with restart_interval. The value is an integer number corresponding to the number of "minutes" (with a Martian hour having 37 minutes) between restart files. By default this is very long (8880, corresponding to 10 sols). If we write 37 it will be every hour. If we write 37*6 it will be every 6 hours, etc.

To restart from an existing restart file, we must change the "restart" option to .true., and the start_month,start_day, and start_hour need to be updated to coincide with the time of the restart file. Since we can tune the starting of the simulation with a resolution of hours (and not minutes), this means that the restart files need to be saved at integer hours, and therefore the restart_interval option should have values 37*N, with N the number of hours of interval between restart files.

===Troubleshooting restart files in big simulations===
In big simulations restart files fail to be saved. This does not cause any problem, and the simulation keeps running. When increasing verbosity to one, the rsl.error file contains this error messages (Note that for this debug execution we set restart_interval to 1 to obtain the error quickly):

<syntaxhighlight>
d01 2024-10-01_06:01:00 med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00
for writing
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_open_for_write_commit wrf_io.F
90, line 1279
med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00 for writing
d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303

[This line repeats many times]

d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303
Timing for Writing restart for domain 1: 0.06920 elapsed seconds.
d01 2024-10-01_06:01:00 Warning TRY TO CLOSE DRYRUN in ext_ncd_ioclose wrf_io.
F90, line 1311
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_ioclose wrf_io.F90, line
1329
</syntaxhighlight>

The problem is in the file wrf_io.F90. We have to update two files

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
</syntaxhighlight>

The problem is caused by the big size of the restart files, it will happen when files are bigger than 2gb.

Apparently, these parameters only work when writing files smaller than 2gb. We can fix that be replacing:

<syntaxhighlight>
NF_CLOBBER
</syntaxhighlight>
by
<syntaxhighlight>
IOR(NF_CLOBBER,NF_64BIT_OFFSET)
</syntaxhighlight>

Then the resulting line looks like

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
stat = NF_CREATE(FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), DH%NCID)

code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
stat = NFMPI_CREATE(Comm, FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), MPI_INFO_NULL, DH%NCID)
</syntaxhighlight>

This is documented in https://docs.unidata.ucar.edu/netcdf-fortran/current/nc_f77_interface_guide.html

==Outputs in superhigh frequency==
The way I found involves changing the file SRC/WRFV2/share/set_timekeeping.F, by adding the two lines that are commented in the following code, the outputs can be made every 20 seconds (every dynamical timestep)

<syntaxhighlight>
CALL nl_get_history_interval( grid%id, history_interval ) ! same as minutes
CALL nl_get_history_interval_mo( grid%id, history_interval_mo )
CALL nl_get_history_interval_d( grid%id, history_interval_d )
CALL nl_get_history_interval_h( grid%id, history_interval_h )
CALL nl_get_history_interval_m( grid%id, history_interval_m )
CALL nl_get_history_interval_s( grid%id, history_interval_s )
IF ( history_interval_m .EQ. 0 ) history_interval_m = history_interval

!history_interval_m=0
!history_interval_s=20
</syntaxhighlight>

Running Mars mesoscale model

2025-03-20T15:31:27Z

Jorge:

This is page I start to introduce some notes to remind that could be useful for other users (Jorge).

The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-mod-les-atmosph-riques-plan-taires/git-trunk/-/blob/master/MESOSCALE/MANUAL/SRC/user_manual.pdf?ref_type=heads

==Regarding NaNs and parallel running==
The mesoscale model cannot run in parallel in spirit at the moment, it runs but it outputs NaNs everywhere.

When running in a single core, in my case at least it produces NaNs with low output frequency (37) but by increasing the output frequency (6 works for me) it is solved. This is weird but seem to be right.

Increasing the output frequency in parallel runs doesn't work. Even with a frequency of 1 doesn't work.

==Notes on clear input and output files (TBD)==

==Notes on configuration files (TBD)==

===namelist.input===

==Restarting simulations==
In the file namelist.input there is the option "restart". The comment for this option says "Output restart files?" but actually it refers to whether or not the simulation should try to start from a previous simulation.
Restart files are periodically saved, this can be configured with restart_interval. The value is an integer number corresponding to the number of "minutes" (with a Martian hour having 37 minutes) between restart files. By default this is very long (8880, corresponding to 10 sols). If we write 37 it will be every hour. If we write 37*6 it will be every 6 hours, etc.

To restart from an existing restart file, we must change the "restart" option to .true., and the start_month,start_day, and start_hour need to be updated to coincide with the time of the restart file. Since we can tune the starting of the simulation with a resolution of hours (and not minutes), this means that the restart files need to be saved at integer hours, and therefore the restart_interval option should have values 37*N, with N the number of hours of interval between restart files.

===Troubleshooting restart files in big simulations===
In big simulations restart files fail to be saved. This does not cause any problem, and the simulation keeps running. When increasing verbosity to one, the rsl.error file contains this error messages (Note that for this debug execution we set restart_interval to 1 to obtain the error quickly):

<syntaxhighlight>
d01 2024-10-01_06:01:00 med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00
for writing
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_open_for_write_commit wrf_io.F
90, line 1279
med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00 for writing
d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303

[This line repeats many times]

d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303
Timing for Writing restart for domain 1: 0.06920 elapsed seconds.
d01 2024-10-01_06:01:00 Warning TRY TO CLOSE DRYRUN in ext_ncd_ioclose wrf_io.
F90, line 1311
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_ioclose wrf_io.F90, line
1329
</syntaxhighlight>

The problem is in the file wrf_io.F90. We have to update two files

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
</syntaxhighlight>

The problem is caused by the big size of the restart files, it will happen when files are bigger than 2gb.

Apparently, these parameters only work when writing files smaller than 2gb. We can fix that be replacing:

<syntaxhighlight>
NF_CLOBBER
</syntaxhighlight>
by
<syntaxhighlight>
IOR(NF_CLOBBER,NF_64BIT_OFFSET)
</syntaxhighlight>

Then the resulting line looks like

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
stat = NF_CREATE(FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), DH%NCID)

code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
stat = NFMPI_CREATE(Comm, FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), MPI_INFO_NULL, DH%NCID)
</syntaxhighlight>

This is documented in https://docs.unidata.ucar.edu/netcdf-fortran/current/nc_f77_interface_guide.html

==Outputs in superhigh frequency==
The way I found involves changing the file SRC/WRFV2/share/set_timekeeping.F, by adding the two lines that are commented in the following code, the outputs can be made every 20 seconds (every dynamical timestep)

<syntaxhighlight>
CALL nl_get_history_interval( grid%id, history_interval ) ! same as minutes
CALL nl_get_history_interval_mo( grid%id, history_interval_mo )
CALL nl_get_history_interval_d( grid%id, history_interval_d )
CALL nl_get_history_interval_h( grid%id, history_interval_h )
CALL nl_get_history_interval_m( grid%id, history_interval_m )
CALL nl_get_history_interval_s( grid%id, history_interval_s )
IF ( history_interval_m .EQ. 0 ) history_interval_m = history_interval

!history_interval_m=0
!history_interval_s=20
</syntaxhighlight>

Running Mars mesoscale model

2025-03-16T21:43:36Z

Jorge: /* Troubleshooting restart files in big simulations */

This is page I start to introduce some notes to remind that could be useful for other users (Jorge).

The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-mod-les-atmosph-riques-plan-taires/git-trunk/-/blob/master/MESOSCALE/MANUAL/SRC/user_manual.pdf?ref_type=heads

==Regarding NaNs and parallel running==
The mesoscale model cannot run in parallel in spirit at the moment, it runs but it outputs NaNs everywhere.

When running in a single core, in my case at least it produces NaNs with low output frequency (37) but by increasing the output frequency (6 works for me) it is solved. This is weird but seem to be right.

Increasing the output frequency in parallel runs doesn't work. Even with a frequency of 1 doesn't work.

==Notes on clear input and output files (TBD)==

==Notes on configuration files (TBD)==

===namelist.input===

==Restarting simulations==
In the file namelist.input there is the option "restart". The comment for this option says "Output restart files?" but actually it refers to whether or not the simulation should try to start from a previous simulation.
Restart files are periodically saved, this can be configured with restart_interval. The value is an integer number corresponding to the number of "minutes" (with a Martian hour having 37 minutes) between restart files. By default this is very long (8880, corresponding to 10 sols). If we write 37 it will be every hour. If we write 37*6 it will be every 6 hours, etc.

To restart from an existing restart file, we must change the "restart" option to .true., and the start_month,start_day, and start_hour need to be updated to coincide with the time of the restart file. Since we can tune the starting of the simulation with a resolution of hours (and not minutes), this means that the restart files need to be saved at integer hours, and therefore the restart_interval option should have values 37*N, with N the number of hours of interval between restart files.

==Troubleshooting restart files in big simulations==
In big simulations restart files fail to be saved. This does not cause any problem, and the simulation keeps running. When increasing verbosity to one, the rsl.error file contains this error messages (Note that for this debug execution we set restart_interval to 1 to obtain the error quickly):

<syntaxhighlight>
d01 2024-10-01_06:01:00 med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00
for writing
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_open_for_write_commit wrf_io.F
90, line 1279
med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00 for writing
d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303

[This line repeats many times]

d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303
Timing for Writing restart for domain 1: 0.06920 elapsed seconds.
d01 2024-10-01_06:01:00 Warning TRY TO CLOSE DRYRUN in ext_ncd_ioclose wrf_io.
F90, line 1311
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_ioclose wrf_io.F90, line
1329
</syntaxhighlight>

The problem is in the file wrf_io.F90. We have to update two files

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
</syntaxhighlight>

The problem is caused by the big size of the restart files, it will happen when files are bigger than 2gb.

Apparently, these parameters only work when writing files smaller than 2gb. We can fix that be replacing:

<syntaxhighlight>
NF_CLOBBER
</syntaxhighlight>
by
<syntaxhighlight>
IOR(NF_CLOBBER,NF_64BIT_OFFSET)
</syntaxhighlight>

Then the resulting line looks like

<syntaxhighlight>
code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90: line 1188
stat = NF_CREATE(FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), DH%NCID)

code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90: line 1195
stat = NFMPI_CREATE(Comm, FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), MPI_INFO_NULL, DH%NCID)
</syntaxhighlight>

This is documented in https://docs.unidata.ucar.edu/netcdf-fortran/current/nc_f77_interface_guide.html

Sub-grid water ice clouds in Mars PCM

2025-03-14T12:52:07Z

Jorge: Created page with "There is a simple parametrization of sub-grid water ice clouds implemented in the Mars PCM. It is by default deactivated and it has not been used in some time, so it is not su..."

There is a simple parametrization of sub-grid water ice clouds implemented in the Mars PCM. It is by default deactivated and it has not been used in some time, so it is not sure that it currently works.

It can be activated with the flag "CLFvarying" in the callphys. And it is documented in the PhD thesis by Alizée Pottier, which can be found at: https://theses.hal.science/tel-01528574

It includes an independent calculation of water saturation in the file "tcondwater", that is weird because the rest of the model uses the saturation computed in watersat_mod, and that might require some analysis and review.

Running Mars mesoscale model

2025-02-24T16:52:09Z

Jorge:

This is page I start to introduce some notes to remind that could be useful for other users (Jorge).

The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-mod-les-atmosph-riques-plan-taires/git-trunk/-/blob/master/MESOSCALE/MANUAL/SRC/user_manual.pdf?ref_type=heads

==Regarding NaNs and parallel running==
The mesoscale model cannot run in parallel in spirit at the moment, it runs but it outputs NaNs everywhere.

When running in a single core, in my case at least it produces NaNs with low output frequency (37) but by increasing the output frequency (6 works for me) it is solved. This is weird but seem to be right.

Increasing the output frequency in parallel runs doesn't work. Even with a frequency of 1 doesn't work.

==Notes on clear input and output files (TBD)==

==Notes on configuration files (TBD)==

===namelist.input===

==Restarting simulations==
In the file namelist.input there is the option "restart". The comment for this option says "Output restart files?" but actually it refers to whether or not the simulation should try to start from a previous simulation.
Restart files are periodically saved, this can be configured with restart_interval. The value is an integer number corresponding to the number of "minutes" (with a Martian hour having 37 minutes) between restart files. By default this is very long (8880, corresponding to 10 sols). If we write 37 it will be every hour. If we write 37*6 it will be every 6 hours, etc.

To restart from an existing restart file, we must change the "restart" option to .true., and the start_month,start_day, and start_hour need to be updated to coincide with the time of the restart file. Since we can tune the starting of the simulation with a resolution of hours (and not minutes), this means that the restart files need to be saved at integer hours, and therefore the restart_interval option should have values 37*N, with N the number of hours of interval between restart files.

==Troubleshooting restart files in big simulations==
In big simulations restart files fail to be saved. This does not cause any problem, and the simulation keeps running. When increasing verbosity to one, the rsl.error file contains this error messages (Note that for this debug execution we set restart_interval to 1 to obtain the error quickly):

<syntaxhighlight>
d01 2024-10-01_06:01:00 med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00
for writing
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_open_for_write_commit wrf_io.F
90, line 1279
med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00 for writing
d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303

[This line repeats many times]

d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303
Timing for Writing restart for domain 1: 0.06920 elapsed seconds.
d01 2024-10-01_06:01:00 Warning TRY TO CLOSE DRYRUN in ext_ncd_ioclose wrf_io.
F90, line 1311
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_ioclose wrf_io.F90, line
1329
</syntaxhighlight>

The problem is in the file wrf_io.F90. When we execute a search for this file, there are various copies of it (only files with a number before deserve our attention, others are flags)

<syntaxhighlight>
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/inc/wrf_io_flags.h
02./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.o
04./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.f
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_grib_share/wrf_io_flags.h
06./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_pnetcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/ioapi_share/wrf_io_flags.h
08./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_grib_share/wrf_io_flags.h
10./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/ioapi_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/DEV/simpler_compile_LES_phys/external/io_grib_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/LES/modif_mars/dble_preci/external/io_grib_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/LES/modif_mars/dble_preci/external/ioapi_share/wrf_io_flags.h
</syntaxhighlight>

The problem is caused by the big size of the restart files, it will happen when files are bigger than 2gb. In line 1188 of wrf_io.*(1195 in some versions of the file we find:
<syntaxhighlight>
stat = NF_CREATE(FileName, NF_CLOBBER, DH%NCID)
</syntaxhighlight>
This is documented in https://docs.unidata.ucar.edu/netcdf-fortran/current/nc_f77_interface_guide.html

Apparently, these parameters only work when writing files smaller than 2gb. We can fix that be replacing this line by:
<syntaxhighlight>
stat = NF_CREATE(FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), DH%NCID)
</syntaxhighlight>

IMPORTANT NOTES.
* Even if the error produced refers to wrf_io.F90, the problem didn't solve for me when updating just files finished by F90, I had to update them all.
* In some of these files the function is not NF_CREATE but something slightly different. The essence of the fix is to replace NF_CLOBBER by IOR(NF_CLOBBER,NF_64BIT_OFFSET)

Running Mars mesoscale model

2025-02-24T16:46:18Z

Jorge: /* Troubleshooting restart files in big simulations (ONGOING) */

This is page I start to introduce some notes to remind that could be useful for other users (Jorge).

The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-mod-les-atmosph-riques-plan-taires/git-trunk/-/blob/master/MESOSCALE/MANUAL/SRC/user_manual.pdf?ref_type=heads

==Regarding NaNs and parallel running==
The mesoscale model cannot run in parallel in spirit at the moment, it runs but it outputs NaNs everywhere.

When running in a single core, in my case at least it produces NaNs with low output frequency (37) but by increasing the output frequency (6 works for me) it is solved. This is weird but seem to be right.

Increasing the output frequency in parallel runs doesn't work. Even with a frequency of 1 doesn't work.

==Restarting simulations==
In the file namelist.input there is the option "restart". The comment for this option says "Output restart files?" but actually it refers to whether or not the simulation should try to start from a previous simulation.
Restart files are periodically saved, this can be configured with restart_interval. The value is an integer number corresponding to the number of "minutes" (with a Martian hour having 37 minutes) between restart files. By default this is very long (8880, corresponding to 10 sols). If we write 37 it will be every hour. If we write 37*6 it will be every 6 hours, etc.

To restart from an existing restart file, we must change the "restart" option to .true., and the start_month,start_day, and start_hour need to be updated to coincide with the time of the restart file. Since we can tune the starting of the simulation with a resolution of hours (and not minutes), this means that the restart files need to be saved at integer hours, and therefore the restart_interval option should have values 37*N, with N the number of hours of interval between restart files.

==Troubleshooting restart files in big simulations==
In big simulations restart files fail to be saved. This does not cause any problem, and the simulation keeps running. When increasing verbosity to one, the rsl.error file contains this error messages (Note that for this debug execution we set restart_interval to 1 to obtain the error quickly):

<syntaxhighlight>
d01 2024-10-01_06:01:00 med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00
for writing
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_open_for_write_commit wrf_io.F
90, line 1279
med_restart_out: opening wrfrst_d01_2024-10-01_06:01:00 for writing
d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303

[This line repeats many times]

d01 2024-10-01_06:01:00 Warning 2 DRYRUNS 1 VARIABLE in wrf_io.F90, line
2303
Timing for Writing restart for domain 1: 0.06920 elapsed seconds.
d01 2024-10-01_06:01:00 Warning TRY TO CLOSE DRYRUN in ext_ncd_ioclose wrf_io.
F90, line 1311
d01 2024-10-01_06:01:00 NetCDF error: NetCDF: One or more variable sizes viola
te format constraints
d01 2024-10-01_06:01:00 NetCDF error in ext_ncd_ioclose wrf_io.F90, line
1329
</syntaxhighlight>

The problem is in the file wrf_io.F90. When we execute a search for this file, there are various copies of it (only files with a number before deserve our attention, others are flags)

<syntaxhighlight>
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/inc/wrf_io_flags.h
02./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.o
04./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_netcdf/wrf_io.f
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_grib_share/wrf_io_flags.h
06./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/io_pnetcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/mars_lmd_new_real_mpifort_64/WRFV2/external/ioapi_share/wrf_io_flags.h
08./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_netcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_grib_share/wrf_io_flags.h
10./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/io_pnetcdf/wrf_io.F90
NO./code/MESOSCALE/LMD_MM_MARS/SRC/WRFV2/external/ioapi_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/DEV/simpler_compile_LES_phys/external/io_grib_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/LES/modif_mars/dble_preci/external/io_grib_share/wrf_io_flags.h
NO./code/MESOSCALE/LMD_MM_MARS/SRC/LES/modif_mars/dble_preci/external/ioapi_share/wrf_io_flags.h
</syntaxhighlight>

The problem is caused by the big size of the restart files, it will happen when files are bigger than 2gb. In line 1188 of wrf_io.*(1195 in some versions of the file we find:
<syntaxhighlight>
stat = NF_CREATE(FileName, NF_CLOBBER, DH%NCID)
</syntaxhighlight>
This is documented in https://docs.unidata.ucar.edu/netcdf-fortran/current/nc_f77_interface_guide.html

Apparently, these parameters only work when writing files smaller than 2gb. We can fix that be replacing this line by:
<syntaxhighlight>
stat = NF_CREATE(FileName, IOR(NF_CLOBBER,NF_64BIT_OFFSET), DH%NCID)
</syntaxhighlight>

IMPORTANT NOTES.
* Even if the error produced refers to wrf_io.F90, the problem didn't solve for me when updating just files finished by F90, I had to update them all.
* In some of these files the function is not NF_CREATE but something slightly different. The essence of the fix is to replace NF_CLOBBER by IOR(NF_CLOBBER,NF_64BIT_OFFSET)

Running Mars mesoscale model

2025-02-24T12:08:00Z

Jorge:

Running Mars mesoscale model

2025-02-24T11:49:11Z

Jorge:

Running Mars mesoscale model

2025-02-13T14:11:11Z

Jorge:

Running Mars mesoscale model

2025-02-13T14:00:23Z

Jorge:

Running Mars mesoscale model

2025-02-13T13:59:44Z

Jorge:

Running Mars mesoscale model

2025-02-13T13:52:51Z

Jorge: Created page with "This is page I start to introduce some notes to remind that could be useful for other users (Jorge). The user manual can be found at https://gitlab.in2p3.fr/la-communaut-des-..."

Installing Mars mesoscale model on spirit

2025-02-10T22:11:44Z

Jorge:

== Set up environment ==
=== Option 1 ===
Add this in your ~/.bashrc then source the file

<syntaxhighlight lang="Bash">
module purge
module load intel/2021.4.0
module load intel-mkl/2020.4.304
module load openmpi/4.0.7
module load hdf5/1.10.7-mpi
module load netcdf-fortran/4.5.3-mpi
module load netcdf-c/4.7.4-mpi
declare -x WHERE_MPI=/net/nfs/tools/u20/22.3/PrgEnv/intel/linux-ubuntu20.04-zen2/openmpi/4.0.7-intel-2021.4.0-43fdcnab3ydwu7ycrplnzlp6xieusuz7/bin/
declare -x NETCDF=/scratchu/spiga/les_mars_project_spirit/netcdf_hacks/SPIRIT
declare -x NCDFLIB=$NETCDF/lib
declare -x NCDFINC=$NETCDF/include
</syntaxhighlight>

Do not forget to declare the local directory in PATH by adding this to your ~/.bashrc

<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
</syntaxhighlight>

It is necessary to unlimit the stacksize to avoit unwanted segmentation faults by adding this to your ~/.bashrc
<syntaxhighlight lang="Bash">
ulimit -s unlimited
</syntaxhighlight>

In the end, source the .bashrc file!

=== Option 2 ===
If you prefer to not modify your .bashrc file, you should instead put all the lines in a "mesoscale.env" file and add a
<syntaxhighlight lang="bash">
source mesoscale.env
</syntaxhighlight>
at the beginning of the meso_install.sh script.

Note that you will still need to have "." in your PATH and unlimited stacksize. So you will definitely need to have:
<syntaxhighlight lang="Bash">
declare -x PATH=./:$PATH
ulimit -s unlimited
</syntaxhighlight>
in your .bashrc file

=== Extra technical details===
* WRF needs a NETCDF environment variable where everything is in the same dir (Fortran and C stuff). If this is not available one needs to create a uniquer dire with links to all the C and Fortran stuff. NCDFLIB and NCDFINC are for the physics.
* WHERE_MPI env variable is used by some scripts to make sure we use the right one

== Set up the installer ==

Go to your 'data' directory (cd /homedata/_MY_LOGIN_ ''or'' cd /data/_MY_LOGIN_) and download the installer with the following command
<syntaxhighlight lang="Bash">
svn co https://svn.lmd.jussieu.fr/Planeto/trunk/MESOSCALE/LMD_MM_MARS/SIMU
</syntaxhighlight>

Make sure the installer can be executed
<syntaxhighlight lang="Bash">
chmod 755 SIMU/meso_install.sh
</syntaxhighlight>

Make a link (e.g. where you are, in the parent directory of /data) to the main script in this SIMU directory
<syntaxhighlight lang="Bash">
ln -sf SIMU/meso_install.sh .
</syntaxhighlight>

Run the installer with a simple display of possible options
<syntaxhighlight lang="Bash">
./meso_install.sh -h
</syntaxhighlight>

== Install the code ==

Update to the latest version of installer
<syntaxhighlight lang="Bash">
cd SIMU
svn update
chmod 755 meso_install.sh
cd ..
</syntaxhighlight>

Run the installer by providing a name for your specific directory
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT
</syntaxhighlight>
''Important'': This will only work if you have access (i.e. an account) to the IN2P3 Gitlab project "La communauté des modèles atmosphériques planétaires" AND if you have added your personal ssh key there. Otherwise proceed as indicated below.

''Special case'': In case you do not have a gitlab account, ask for an archive (tar.gz) of the code.
Let us assume the name is git-trunk-mesoscale-compile-run-spirit.tar.gz
and the file is in the current directory (for instance in /homedata/_MY_LOGIN_)
then run the installer with the following command
<syntaxhighlight lang="Bash">
./meso_install.sh -n DESCRIBE_YOUR_RESEARCH_PROJECT -a git-trunk-mesoscale-compile-run-spirit
</syntaxhighlight>

=== Troubleshooting (in case this happens to you) ===
If GCM compilation fails with error message "Can't locate Fcm/Config.pm in @INC (you may need to install the Fcm::Config module)", this is because "." is in your PATH before "FCM_V1.2/bin".
You can fix it by either adapting the PATH in the environment file by adding
<syntaxhighlight lang="Bash">
declare -x PATH=/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>
or by removing the symbolic link to "fcm" in "/homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/code/LMDZ.COMMON/".

Once you have fixed the problem you can recompile the GCM (which had failed previously) by doing:
<syntaxhighlight lang="Bash">
cd /homedata/_MY_LOGIN_/DESCRIBE_YOUR_RESEARCH_PROJECT/
./compile_gcm.sh
</syntaxhighlight>
and recreate start files from a sample start_archive.nc by doing (in subdirectory gcm/newstart)
<syntaxhighlight lang="Bash">
./mini_startbase.sh
</syntaxhighlight>

A different option is to fix the problem directly in the meso_install.sh script, by adding this line (anywhere below the definition of $refrepo )
<syntaxhighlight lang="Bash">
declare -x PATH=$refrepo/code/LMDZ.COMMON/FCM_V1.2/bin/:$PATH
</syntaxhighlight>

=== Extra technical stuff ===

* in meso_install.sh is hard coded the git tag of the version that will be installed e.g. version="tags/mesoscale-compile-run_MESOIPSL_exploration". the tags point to specific versions which have been tested and are thus reference. e.g. mesoscale_compile-run_MESOIPSL on the git-trunk

* To recompile WRF (see "readme" file)
<syntaxhighlight lang="Bash">
cd code/MESOSCALE/LMD_MM_MARS
makemeso -p mars_lmd_new
</syntaxhighlight>
To recompile WRF in debug mode:
<syntaxhighlight lang="Bash">
cd code/MESOSCALE/LMD_MM_MARS
makemeso -p mars_lmd_new -g
</syntaxhighlight>
The compilation script (and options) is in MESOSCALE/LMD_MM_MARS/SRC/WRFV2/mars_lmd_new/makegcm_mpifort for physics
And in MESOSCALE/LMD_MM_MARS/makemeso for WRF

== Run the full workflow GCM + initialization + mesoscale model ==

Have a look in the script named launch just for info or to change the number of processors or the step at which you start. Send the launch job to the cluster by typing (note that you can change the number of core to run with in the header of the script, e.g. ''#SBATCH --ntasks=24'' to use 24 cores, but this doesn't work for now...)
<syntaxhighlight lang="Bash">
sbatch launch
</syntaxhighlight>
IMPORTANT: if you have used "Option 2" in the setup/environment, i.e. creating a dedicated "mesoscale.env" file, then you should source it in the "launch" script with something of the likes of:
<syntaxhighlight lang="Bash">
source ../mesoscale.env
</syntaxhighlight>

You can check the status of the run by typing
<syntaxhighlight lang="Bash">
squeue -u $USER
</syntaxhighlight>

=== Extra technical stuff ===
* The namelist.input file contains inputs for WRF. One can change output rate by specifying "history_interval_s" in seconds (instead of "history_interval"), e.g. set to the timestep for an output at every step to debug.
<syntaxhighlight lang="Bash">
history_interval_s=20
</syntaxhighlight>
* to run in hydrostatic mode: it is a parameter for "&dynamics" namelist
<syntaxhighlight lang="Bash">
non_hydrostatic=F
</syntaxhighlight>
* Note that the full list of options for namelist.in can be found in "SIMU/namelist.input_full"

== A more detailed run ==

The best is probably to use a more complete startbase than the minimal one that was created. For instance, to get a more complete startbase, link 'data_gcm' to point towards '/data/spiga/2021_STARTBASES_rev2460/MY35'

To use the tyler cap setting in namelist.wps, download the tylerall archive here 'https://web.lmd.jussieu.fr/~aslmd/mesoscale_model/data_static/' and extract the content in the folder named data_static

[[Category:Mars-Mesoscale]]