Question

"How to compile and run DSSAT v4.5 on Linux?" Good question.

Questions

  • "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

Answer

This post assumes:

  • You have a valid license of DSSAT and access to the source code of v4.5 (commercial open-source project).
  • 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)
  • 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 (dscsm045.exe in this case), you can run it on Linux (or any other platform). Here are few minor tricks that you'd need to know.

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.v45)

This file indicates 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 (.) in the place of , indicating Hey, it's in the same directory. For example, from MBA C:\DSSAT45\DSCSM045.EXE CSCER045 to MBA .DSCSM045.EXE CSCER045. Make this change throughout the file (or, you can take a look at mine here as an example; may or may not work on your system).

Settings for Forward Slash

There are two places in the source to take care of the slash direction difference between Windows and Linux. Just switch the comment (! symbol) between [DOS, Windows] and [Linux, UNIX].

ModuleDefs.for

! CHARACTER(LEN=5), PARAMETER :: OPSYS = 'WINDO'   !DOS, Windows
CHARACTER(LEN=5), PARAMETER :: OPSYS = 'LINUX'   !Linux, UNIX

CRSIMDEF.for

! CHARACTER(LEN=1),PARAMETER::SLASH = '\' !DOS, Windows
CHARACTER(LEN=1),PARAMETER::SLASH = '/' !Linux, Unix

Weather file path

When you have all the files in the same directory, you don't need to have PATHWT attached to the weather file name (in the INP file). It's not an official fix, but I found it was causing problem finding the weather file. Find the appropriate line (line 154 in my case; may be different depending on your build number) and take [PATHWT]

out.optempy2k.for (L154)

! WRITE (LUNIO,2800,IOSTAT=ERRNUM) FILEW,PATHWT
WRITE (LUNIO,2800,IOSTAT=ERRNUM) FILEW

Keep file extensions in lower case

The Fortran files have inconsistence extensions (.FOR or .for), which is fine on Windows but not on Linux.  So, let's keep them all in lowercase .for not to confuse the compiler (or ourselves).

Compiling order matters (or not?)

By definition, modules are better to be compiled first. In fact the compiler is smart enough to take care of this, but if you get annoyed by warning messages popping up..

Debug or Release?

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. Bash scripts to do this work included here.

Few final steps

Now, remaining steps should be straightforward - rename the executable as dscsm045.exe, change permission to executable, copy it to your workspace, and run it from the command line using the batch mode. Of course, you'll also have to manipulate the DSSBatch.v45 file manually: For example, change C:\DSSAT45\maize\BRPI0202.MZXto just BRPI0202.MZX. Outside of shell, you're now on your own!

Worth it?

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!

Let's talk

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.

Special Thanks

I must say that 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.

Citation

HarvestChoice, 2011. "[Q] DSSAT v4.5 on Linux?." International Food Policy Research Institute, Washington, DC., and University of Minnesota, St. Paul, MN. Available online at http://harvestchoice.org/node/1427.

Feb 12, 2011