[Q] Weather generation in DSSAT?



I have been spending time the last few days trying to understand the kind of inputs that DSSAT requires to run it from the command line.  I hope you can coach me at the places I get stuck.  I have discovered that the DSSAT documentation lags years behind the program.  So in looking at the 3.5 manuals, they look at the inputs for FileX.  But I have not been able to see how FileX knows what climate variables to use in a simulation.  Could you please let me know where that occurs when using the command line?  Thanks!!!



Crop models in DSSAT operate on daily basis, thus daily weather data is needed. However, for future climate conditions, we only have monthly mean of climate variables (solar radiation, min/max temperature, rainfall, and rainy days) – so we are using a weather generator program to generate daily weather data. DSSAT conveniently comes with two weather generators, WGEN and SIMMETEO, and we’ve been using SIMMETEO, which uses monthly summaries to estimate parameters. Descriptions of the two weather generators can be found in the second volume of DSSAT v3.5 (yeah…) documentation. Soltani and Hoogenboom have published a number of articles on the comparison of two methodologies.

Opting to use SIMMETEO instead of recorded daily weather data is quite simple:

  1. Name your climate profile with four-character code (e.g., CLIM.CLI)
  2. In your X-file, in the FIELDS block, put the four-character code as the weather station ID [WSTA]
  3. In your X-file, in the SIMULATION CONTROLS block, set the option of WTHER to S (simulated)
  4. In your X-file, in the SIMULATION CONTROLS block, set the random seed value to your favorite 5-digit number

By the way, at this point I presume you constructed the climate profile for each grid cell. Just in case, the climate profile is a small text file containing monthly summary of climate variables (which are all included in the FutureClim database), and it should look like this:

  UFGA   29.630  -82.370    10  20.9   7.3  16.6  27.4  14.4  1310
  1958    49  0.25  0.50   2.0   3.0
     1   365
     1  10.9  19.6   6.0  86.4   8.1
     2  13.5  21.4   7.3 107.9   7.6
     3  17.3  24.5  10.1 101.7   7.8
     4  21.4  27.9  13.3  75.1   5.7
     5  22.3  31.0  17.0  95.3   7.6
     6  20.8  32.6  20.6 164.1  11.9
     7  20.5  33.1  21.8 166.9  15.8
     8  19.1  32.9  21.7 195.2  15.4
     9  16.7  31.6  20.5 134.5  11.1
    10  14.6  28.4  16.2  56.7   6.3
    11  11.9  24.4  11.1  57.4   6.0
    12   9.8  21.1   7.6  68.9   7.4

See DSSAT vol3 to learn more about this file format.

Couple of things to note:

  • Due to the nature of stochastic method, you won’t get any spatial correlation on daily weather. If you look at the generated daily data, you can easily spot that one grid cell has flood and its neighbor cell has drought in a same year.
  • Crop growth/water stress and yield are very sensitive to the rainfall distribution during the season, not necessarily to the total amount of rainfall. To (partly) overcome this, we run a number of realizations (about >100).
  • Especially, not having spatial correlation of rainfall is particularly problematic if you need to analyze yearly production from region to region and conduct trade/policy analysis, for example. One common method to address this is using a delta method. Which means, shift historic climatology (observed daily weather, if available) to the future condition (e.g., In January in this grid cell, temperature increases by 1 C and rainfall decreases by 5%). You can implement this by re-generating daily weather data (WTH file) or embedding the “shifters” in the ENVIRONMENTAL MODIFICATIONS block of X-file (see the second volume and find examples). For HarvestChoice studies, I pre-generated 100-year daily weather data for SSA countries (see here for more information) and use this method when I need to run under future climate conditions.

Hope this helps your understanding. I’ll be happy to discuss what’d be best for your particular study.


About Jawoo Koo

Research Fellow at International Food Policy Research Institute (IFPRI), Washington, DC. Working on the meso-scale crop systems modeling applicaitons for Sub-Saharan Africa region.

6 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Dr.Saeed
    February 25, 2019 at 2:32 am #

    Dear All, Have a good day….

    I have annual weather data and already imported to WeatherMan 4.7 successfully but new weather station is not showing in input X files can some one guide me complete procedure how to create new weather station which could appear in xfile while making X file…..

    • Gerrit Hoogenboom
      April 29, 2019 at 3:09 pm #

      Dr. Saeed,

      When adding new weather data or new soil profiles, you need to update the internal database of XBuild. Please use the Refresh option that can be found on the top bar of XBuild.


  2. Jyoti Singh
    March 11, 2019 at 2:16 am #

    Your answer is very useful in understanding the limitation and advantages of using weather generator. My question is regarding the generation of solar irradiance. Let’s assume I have all the daily Tmax, Tmin and rainfall but not solar irradiance and DSSAT generate it. How does it take into consideration the consistency of cloudy day and solar irradiance? According to my understanding, this could cause a considerable inconsistency in the photosynthesis rate.

    • Gerrit Hoogenboom
      April 29, 2019 at 3:08 pm #

      WeatherMan has an option for generating solar radiation data if you do not have measurements. We always recommend for people to use observed solar radiation data. A cloudy day is not really the same as a day with rainfall, so in many cases we use the difference between Tmax and Tmin to account for clear days and cloudy days.

  3. Jose Ma Luis Montesclaros
    April 3, 2019 at 12:53 am #

    Hi! I’m using NASA’s POWER database to generate daily weather data for my target area. It can be accessed here:

    My issue is that the POWER database does not have information on sunhours, so I had to derive it from another source, i.e. a public website, which indicates that peak sun hours can be calculated directly from the SRAD, i.e. in KWH. (copied below this message).

    Anyway, I already started using the database without sunhours, and using only SRAD data. I wonder, though, what DSSAT’s mechanism/assumption is for sunhours, if only srad data is available? I ask because the model output seemed quite sensitive to the number of hours I would input under “environmental modifications”.

    Thank you!

    “Peak Sun Hours
    The average daily solar insolation in units of kWh/m2 per day is sometimes referred to as “peak sun hours”. The term “peak sun hours” refers to the solar insolation which a particular location would receive if the sun were shining at its maximum value for a certain number of hours. Since the peak solar radiation is 1 kW/m2, the number of peak sun hours is numerically identical to the average daily solar insolation. For example, a location that receives 8 kWh/m2 per day can be said to have received 8 hours of sun per day at 1 kW/m2. Being able to calculate the peak sun hours is useful because PV modules are often rated at an input rating of 1kW/m2.”

    • Gerrit Hoogenboom
      April 29, 2019 at 2:40 pm #

      DSSAT calculates daylength as a function of sunset and sunrise. This is not related to the total of sunshine hours. The latter is not used as an input in DSSAT.

Leave a Comment

Remember to play nicely folks, nobody likes a troll.