DSSAT Crop Modelling for Beginners: CSM, CERES vs CROPGRO, Inputs, Calibration and Evaluation

What is DSSAT?

DSSAT, the Decision Support System for Agrotechnology Transfer, is a Windows-based software package that bundles dynamic crop growth simulation models with tools for preparing weather, soil, crop management and experimental data. According to the official DSSAT site, it covers more than 45 crops and its models "simulate growth, development and yield as a function of the soil-plant-atmosphere dynamics." The site describes DSSAT as one of the oldest and most widely used crop modelling platforms in the world.

The crop models sit inside a common framework called the Cropping System Model (CSM). CSM shares one soil water, soil nitrogen and weather engine across crops, and plugs in a crop-specific plant growth module. That is why a maize run and a soybean run use the same input file formats even though the plant biology underneath is different.

Version 4.8.5 was released in December 2024 and is the version taught in many recent trainings, including the one this guide draws on; dssat.net lists version 4.8.6 as released on 1 July 2026. Everything below applies to both.

CERES vs CROPGRO: which module simulates your crop?

The two plant module families beginners meet first are CERES and CROPGRO. CERES models were developed for cereals; CROPGRO is a generic module for grain legumes that DSSAT has since parameterised for several other crops. DSSAT's list of plant growth modules sets a default module for each crop:

A practical point for Nepal: not every crop grown here has a module. Okra, for example, does not appear in DSSAT's list of plant growth modules, so field trials on okra are analysed statistically rather than simulated. Rice, maize and wheat, the staples of the Terai and mid-hills, are all covered.

What inputs does DSSAT need?

The DSSAT overview is explicit: the crop models "require daily weather data, soil surface and profile information, and detailed crop management as input," while crop genetic information comes partly from species files shipped with DSSAT and partly from cultivar information "that should be provided by the user." In practice that means four groups of inputs.

Observed data from the field trial (dates of flowering and maturity, final yield, biomass, and ideally time-series of leaf area or dry matter) go into separate observation files, entered with ATCreate. Without observations you can run the model, but you cannot calibrate or evaluate it.

What are genetic coefficients, and how are they calibrated?

Genetic coefficients are the cultivar-specific parameters that make CERES-Rice behave like Hardinath-1 rather than a long-duration monsoon variety. For CERES-Rice they include the juvenile phase duration (P1), photoperiod sensitivity (P2R), grain-filling duration (P5) and critical photoperiod (P2O), along with growth coefficients such as potential spikelet number (G1) and single grain weight (G2). CERES-Maize uses a parallel set (P1, P2, P5, G2, G3, PHINT). New local varieties do not come with these numbers; they must be estimated from field data.

DSSAT provides two estimators, both described on its tools page:

• GENCALC, set up through the GenSelect interface. You choose a crop and cultivar, GENCALC shows all experiments and treatments for that cultivar, and you select the treatments to calibrate against, preferably the non-stressed ones.
• GLUE (Generalized Likelihood Uncertainty Estimation), set up through GLUESelect. It is a pseudo-Bayesian method that runs a very large number of simulations and returns coefficient values with an estimate of their uncertainty. It requires R. DSSAT advises that treatments used for GLUE should not have been exposed to water or nutrient stress, pests, weeds or diseases. A parallelised version, GLUEP, was introduced to cut calibration time and can also calibrate ecotype parameters.

The sensible order is to calibrate phenology first (flowering and maturity dates), then growth and yield coefficients, and only then judge the model. Calibrating everything at once usually produces coefficients that fit one season and fail the next.

How do you evaluate a DSSAT simulation?

Calibration uses one set of data; evaluation must use a different, independent set (another season, site or treatment). DSSAT's GBuild and EasyGrapher tools calculate the standard statistics, and they are also easy to compute in R.

Here P is the simulated and O the observed value. A minimal R version, with example numbers only:

obs <- c(5.1, 4.6, 6.0, 5.4, 4.9) # observed grain yield, t/ha (example) sim <- c(5.4, 4.3, 5.7, 5.9, 5.0) # simulated by DSSAT for the same treatments rmse <- sqrt(mean((sim - obs)^2)) nrmse <- 100 * rmse / mean(obs) d <- 1 - sum((sim - obs)^2) / sum((abs(sim - mean(obs)) + abs(obs - mean(obs)))^2) round(c(RMSE = rmse, nRMSE = nrmse, d = d), 3)

Report RMSE and d together. A high d with a large RMSE usually means the model follows the trend between treatments but is biased in level, which points back to calibration.

A beginner's workflow for a first DSSAT project

1. Pick a crop with a CSM module and a field experiment you have good records for: dates, management, yields.
2. Prepare daily weather for the site and season in WeatherMan and a soil profile in SBuild.
3. Describe the experiment and treatments in XBuild to create the FileX.
4. Enter observed phenology and yield with ATCreate.
5. Start from a similar cultivar in the .CUL file, then calibrate with GENCALC or GLUE on non-stressed treatments.
6. Evaluate against independent data with RMSE, nRMSE and d.
7. Only then run scenarios such as shifted sowing dates or warmer seasons, and analyse the outputs statistically.

The last step is where crop modelling meets field statistics. Simulated yields across scenarios can be exported and analysed in R with the same tidyverse and agricolae tools used for field trials; the RCBD analysis guide shows that workflow.

Why this matters for climate-resilient crop research in Nepal

Field trials in Nepal are expensive and usually run for one or two seasons. A calibrated crop model lets a researcher ask what the same variety would do under a different sowing date, irrigation schedule or temperature regime without waiting years for the weather to cooperate. That is the reasoning behind the first theme on Bishal Neupane's research-fit page: using field observations, crop modelling and management data to identify practical pathways to more resilient crop production.

Neupane completed the five-day online course "Basics of Crop Modeling: Fundamentals and Applications," conducted by NAXA with YES Agriculture from 10 to 14 February 2025. The training, listed on his publications page under certifications, covered the CROPGRO and CERES modules in DSSAT v4.8.5, genetic coefficient calibration for local varieties, model validation against field data, and linking DSSAT outputs to an R pipeline for ANOVA. His field background includes co-authoring the spring rice genotype trial in eastern Terai, the kind of multi-genotype phenology and yield dataset from which cultivar coefficients are estimated.

Common beginner mistakes

• Calibrating and evaluating on the same data, then reporting the fit as validation.
• Using weather from a distant station without checking for gaps or unit errors in WeatherMan.
• Calibrating on stressed treatments, so that genetic coefficients absorb a drought or pest effect.
• Treating a generic soil profile as site data when soil water limits drive most of the yield response.
• Citing "DSSAT" without the version number, which appears in the header of every output file.

Supervisors working on crop modelling, climate adaptation or remote sensing who want to discuss collaboration can reach Bishal through the contact page.