The state of Crop Modelling
The ability to know your crops yield potential at any point in the season is a great asset. It improves your ability to make future economic decisions, such as forward selling grain or purchasing next years inputs, as well as decisions right now, which are generally nitrogen application timings and amounts.
There’s currently one major crop simulator used within Australia to model wheat, lupin and canola crops; the Agricultural Production Systems sIMulator, which is more commonly known as APSIM. Development and commercialisation of APSIM is overseen by the APSIM Initiative, which is a joint venture between the CSIRO, Queensland’s Department of Agriculture, and the University of Queensland. You can find more information about the initiative here.
APSIM is the model that powers both Yield Prophet (Birchip Cropping Group) and ProductionWise (Grain Growers). Along with the two companies mentioned, there are only two other entities that hold commercial APSIM licenses, and they are Limagrain Europe and Pioneer Hi-Bred International.
This is how crop modelling currently works:
- Pick a point on your farm. If your only going to model one point, you’d try and pick one that is most representative of the entire farm. If your not planning on doing any soil testing, APSIM has a database of pre configured soil types which you can try and pick a soil type from. This method may be the quickest, and easiest way to get started, but has some obvious drawbacks, which I’ll cover.
- Conduct extensive soil testing to a depth of at least 1.0 metre at the chosen point. 1.0m is the minimum as APSIM requires data at intervals (0–10cm, 10–40, 40–70, 70–100) to that depth.
- You might already have, or choose to install a weather station on farm. Otherwise you pick the closest BOM/DAFWA station for weather data.
- Upload the soil information, as well as any other model inputs (this is a combination of crop, soil, weather and application data) to whichever product your using for yield modelling.
- At certain points during the season, or anytime something changes (N application, new rainfall data), the model will run and you’ll receive a new report outlining your predicted crop condition, which, if your using Yield Prophet, will look very similar to the images below. A full example Yield Prophet report is available here.


You might think it’s hard to have gone wrong in those few (simplified) steps, but let’s look at some of the problems you could face.
Growing your crop in someone else’s paddock (wrong inputs)
If you choose to use one of APSIMs preconfigured soil types, rather than choosing a point on your own farm and conducting soil testing, you’re now trying to model your crop in someone else’s paddock. But that’s ok you say, “that paddock’s only a couple kms the road, it’s the same soil type”. We know that variability exists within paddocks on a sub 20m scale, let alone across multiple paddocks, and between farms.
If you’re going to pick a preconfigured soil type, you also need to look at when it was created. If it was done recently, the soil that you thought was the closest match to yours, may be even further wrong than you’d expect. If your neighbour has undertaken a deep ripping program, spread clay, lime or other soil fixers, and then taken the soil samples and other measurements required by APSIM; the soil that you thought was a match for your paddock definitely won’t be, unless you also happened to undertake all the same operations on your own farm to make it so.
Growing your crops under someone else’s rainfall (wrong inputs)
At this stage, most farmers are manually entering weather data into their chosen product, which is mainly rainfall measurements. Any other weather inputs, such as solar radiation or min/max temperatures, are either taken from a local BOM/ DAFWA station, or inferred from historical data. Manual entry of weather data is an issue that should be eliminated in the near future, as modelling tools (hopefully!) begin exposing APIs, which will allow your soil probes, and weather stations to send data directly to your chosen products account.
However, if you decided to use the nearest BOM/DAFWA station for rainfall, you face another potential problem. Our closest BOM station is ~20km away, and I’ll guarantee you that our rainfall, measured in multiple gauges over our farm, never matches what’s recorded at the BOM station. If you decided to use that station as the weather input for your model, you’re now growing your crop using someone else’s rainfall..
A single point for an entire paddock
How can a model based on a single point be expected to give you a reliable estimated yield over an entire paddock? How can that single point capture all the variability we know exists?
Take a look at the image below. It’s showing yield data from last year. The location of a fully categorised Yield Prophet point is indicated by the arrow. We manually enter rainfall data. The non-harvested area towards the top of the paddock was burnt after a lighting strike.


The Yield Profit predicted yield was ~2.3t/ha. The actual yield at that point was between 2.99 and 3.27t/ha. The avg yield across the whole paddock was 3.07t/ha.
Yield profit correctly predicted the yield for the lowest 11% of the paddock. Under estimation may be better than over estimation, but it still leads to missed opportunities.
Let’s look at a second paddock on a different farm. Again the location of a fully categorised Yield Profit point is shown by the arrow. Rainfall is also manually entered.


The predicted yield at this site was 3.6t/ha, and you can see the actual yield for the point was between 2.5t/ha and 2.72t/ha. The average over the whole paddock was 2.85t/ha.
So we have two different modelled points, with two very different outcomes. One under estimated yield by ~700kg, where the other over estimated yield by ~1000kg.
However, the point to be made here, is not about wether the single points modelled were individually correct or not, it’s that by only modelling a single point, you cannot reliably predict yield across the entire paddock. If you’re using that single point for time/value critical decisions, you probably won’t get the outcome you expected at the end of the season.
Where to from here?
Improving model inputs with management zones
You might already be using “zones” to manage the variability within your paddocks. If not, zones are basically breaking down the paddock according to some differentiator, it could be soil type, pH, or previous yields, and using those values as a guide for inputs. Zones are the driver behind variable rate applications.
If we’re already breaking down our paddocks into different areas to streamline applications and input management, it makes sense to start using those zones as the inputs for our crop models, it’s the easiest & simplest next step.
An alternative to historical weather data
If you live in the Northern Ag Region, you’d probably agree that the weather, and seasons over the past 10 years have been anything but ordinary. Changing environmental conditions means our reliance on historical weather data as an input to simulations could be decreasing. But what can we replace it with?
Future of APSIM
Work is currently underway to rewrite APSIM from scratch, with the new model being called APSIM Next Gen. In a paper published as part of the International Congress of Modelling and Simulation, held on the Gold Coast late last year, Dean Holzworth outlined the steps being taken by him and his team to modernise the model.
A first version of APSIM Next Gen. …a light weight kernel with a simple inter-model API… ran approximately 7 times quicker than the current released version of APSIM (7.7).
Some of the major changes made by the team are:
- Switching to C# and MONO for cross platform development
- Moving the development process to GitHub
- Using a continuous integration system, Jenkins CI
The hope is that in three to five years, APSIM Next Generation will have the required functionality to satisfy the majority of users.