- “Does anybody have experience (good or bad) using DSSAT with WINE on Linux. WINE is supposed to allow Windows applications to run under Linux but does not guarantee full Windows emulation.” – JW
- “If it is possible in Linux I think it can also be tried in MAC OS. Will you please share the procedure for compiling it linux, so that I can try in MAC.” – JT
- “I have been looking to run DSSAT models in UNIX platform. I certainly need your help in doing this.” – GA
This post assumes:
- You’re one of the DSSAT developers and have access to the source code of CSM via GitHub.
- You have a valid license of DSSAT.
- You have good knowledge of DSSAT and CSM in general.
- You have good knowledge of running CSM from the command line.
- You have a valid license of Intel Fortran Compiler for Linux (free for non-commercial use) or a GNU Fortran compiler (more information). We recommend having version 4.8 or higher.
- You feel comfortable handling files and executing programs from the command line on Linux.
On Windows, even with the DSSAT shell program, the actual model behind the interface runs on the command line, reading input files in plain ASCII format, writing output files again in plain ASCII format. You might have thought this seemed to be an old-school way (“What is DOS?”, “Who uses Fortran?”); this way in fact provides great flexibility and scalability – including the possibility of porting the program into other operating systems (as long as there is a modern Fortran compiler, that is). Besides, as computer scientists put it, there is only few things in the Earth faster than well-compiled Fortran programs.
The idea is simple: once you can compile the core executable program of DSSAT, you can run it on Linux (or any other platform). Here are few minor tricks that you’d need to know.
Before we begin:
- This post was written based on a working version of DSSAT v4.7 (as of Nov 2017); however, similar compilation/execution of the DSCSM046.exe on Linux is also possible, if you’re familiar with how to execute DSSAT v4 on command line interface and, of course, if you have access to the source code.
- Figuring out all this was not possible without insightful helps and advices from frontiers like Cheryl Porter and Guillermo Baigorria at University of Florida. Also, many thanks always to my colleague/friend Ricky Robertson at IFPRI.
- This post was first published to the HarvestChoice Labs on February 14th, 2011, and moved to the DSSAT.net on October 16, 2011, and updated on November 27, 2017.
Put all the input files into one directory
In case you didn’t know, you can run the model from one directory when you have all the input data files there (weather, soil, cultivar, ecotype, species, standard input, etc). Of course you can maintain the original directory structure as in Windows, but it is a lot easier to manage your set of files in one place per project.
DSSAT Profile (Filename: DSSATPRO.v47 for Windows and DSSATPRO.L47 for Linux/MAC)
These files indicate the paths to find various model executables and input file directory. Once you put everything in one directory, it gets easier in this step: simply put a period+space (. ) in the place of “C:” and remove “\DSSAT47”, indicating “Hey, it’s in the same directory.” For example on DSSAT v4.7, from [MBA C: \DSSAT47 DSCSM047.EXE CSCER047] to [MBA . DSCSM047.EXE CSCER047]. Make this change throughout the file.
Another option, for example, is to have the DSSAT47 folder on the root of the system (/DSSAT47). In this way, you can put “//” in the place of “C:” and keep the “\DSSAT47”.
The source directory structure
DSSAT cropping system model (CSM) design is a modular structure in which components separate along scientific discipline lines and are structured to allow easy replacement or addition of modules. It has one Soil module, a Crop Template module which can simulate different crops by defining species input files, an interface to add individual crop models if they have the same design and interface, a Weather module, and a module for dealing with competition for light and water among the soil, plants, and atmosphere. It is also designed for incorporation into various application packages, ranging from those that help researchers adapt and test the CSM to those that operate the DSSAT /CSM to simulate production over time and space for different purposes (The DSSAT cropping system model).
Compiling the code
The code is compatible with the CMake utility for generating make files and setting up projects for a variety of IDEs and compilers. To use this feature, first download and install CMake. Then set up a CMake project by pointing to the source code directory and the build directory.
Structure of the code
. ├── <source files> ├── CMakeLists.txt ├── distclean.cmake ├── README.md ├── ... ├── cmake │ └── Modules │ ├── SetCompileFlag.cmake │ └── SetFortranFlags.cmake ├── build │ └── ... └── Data ├── Documentation ├── Cotton ├── ... └── Wheat
This file contains all the configuration needed to set up the project.
Edit this file to make your own configuration and add new projects. Comment/Uncomment any lines pertaining to options you may need.
This is a CMake script that will remove all files and folder that are created after running
make. You can run this code in one of two ways:
cmake -P distclean.cmake. (The
cmakewill execute a CMake script)
make distcleanafter your Makefile has been generated.
You shouldn’t need to edit this file.
This directory contains CMake scripts that aid in configuring the build system.
This file defines a function that will test a set of compiler flags to see which one works and adds that flag to a list of compiler flags. This is used to set compile flags when you don’t know which compiler will be used.
This file uses the function from
SetCompilerFlag.cmake to set the DEBUG, TESTING, and RELEASE compile flags for your build. You might want to inspect this file and edit the flags to your liking.
This folder should be created aims to keep all working files inside it, avoiding messing your source folder. During compilation and linking, working folders are created automatically inside this folder. Any libraries created end up in
mod/, as well as compiled Fortran
.mod files. The executable will end up in
This folder contains documentation and experiment files for different crops.
Configuring the build
It is usually preferred that you do an out-of-source build. To do this, create a
build/ directory at the top level of your project and build there.
$ mkdir build $ cd build $ cmake .. $ make
When you do this, temporary CMake files will not be created in your
As written, this template will allow you to specify one of three different sets of compiler flags. Debug-mode compiled program runs slower but gives you more detailed error messages when things go wrong (which file and what line). Release-mode compiled program runs fast. The default is RELEASE. You can change this using to TESTING or DEBUG using
$ cmake .. -DCMAKE_BUILD_TYPE=DEBUG
$ cmake .. -DCMAKE_BUILD_TYPE=TESTING
You can provide all kind of information CMake. Some examples can be find at (CMake Command-Line Options).
One usable examples could be:
$ cmake -G "Unix Makefiles" -DCMAKE_Fortran_COMPILER=ifort ..
In this example we are specifying the fortran compiler and the kind of project we want as result (make file project).
Few final steps
Now, remaining steps should be straightforward – copy the executable build/bin/dscsm047.exe to the prepared folder, change permission to executable, and run it from the command line using the batch mode. Outside of shell, you’re now on your own!
Worth the hassle?
I think there will be many motivations to do this work – but in our case, at IFPRI, this was needed to run DSSAT crop models on a Linux cluster (80-CPU, as of early 2011). With this, we were able to crank out global-scale simulation results on 10 km grids. It was certainly worth the effort!
Now that we all knew that there are many of our colleagues interested in this issue, let’s talk openly. Got stuck? Know a better way (sure there will be!)? Feel free to leave your comment/question below.