Crop sequencing and manager2

The “new” simulations have an increasing number of .NET management components that work in both single and multiple crop configurations. They all use a convention that if there is a “sequencer” plugged into the system, then they listen to it – if there’s no sequencer, they do what they want when they want. The presence of a sequencer is announced by the existence of the variable “currentPaddock”. So, if a crop management component in a single paddock, single crop simulation is trying to decide whether to plant its associated plant module, it will ask the system for the variable “currentPaddock”, receive no responses, rightly assume that it is the only crop in the system and act accordingly: whenever its planting conditions are met, it will sow or harvest that crop.

In a multiple crop simulation, a sequencer is present in the system to provide the plant management components direction as to when they can or cannot plant – and it does so via the variable “currentPaddock”. If the plant management component finds that variable in the system, it will not do anything until it’s told: it then relies on the sequencer to

determine whether a particular crop can be planted (eg via canEnter)
plant the crop (via Enter)
determine whether the crop can be harvested (eg via canLeave)
harvest the crop (via Leave)

These Enter/Leave names are not hardwired – just common to both the sequencer’s rules and the crop management component.

In single paddock configurations, the sequencer has only one paddock to care about.

In multiple paddocks, the sequencer manages each paddock by setting the currentPaddock variable before calling the same crop management code.

There are two sequencers in the management toolbox: A monoculture and a directed graph rotation.