RotationPyomo module

author: young

AfoLogic.RotationPyomo.f_con_area(model)

Creates the constraint between farm area and rotation area on each LMU.

Constrains the maximum area of all rotations on each lmu by the area of each LMU on the modelled property. The area of rotation on a given soil can’t be more than the amount of that soil available on the farm.

AfoLogic.RotationPyomo.f_con_history_between(params, model)

Creates the constraint between history provided at the end of the year and the history required at the beginning of the year for each rotation phase on each LMU.

The rotation constraints are to ensure that the rotation phases that are selected in the optimisation can be arranged into an actual rotation. All phases except the continuous rotations require at least one other phase. Eg. a canola(z)-wheat(w) rotation would be generated from 2 phases Y Y N E z and Y Y E N w. To represent this requires ensuring that each rotaion phase selected has a preceding phase that has landuses in the same order as the target rotation phase (except for year 0). This is called the history required and history required.

Note: This constraint is skipped in the period between season start and season break to allow last years landuse to carry over in the medium and late breaks, so that dry pasture and stubble can be grazed. Because there is no history constraint in those period v_phase_change_increase has been masked so that the only phases that can change are dry sown ones (the dry sown phases will be forced to have the right history once the season has broken and due to the seeding cost it will select a dry phase with the correct history from the start).

AfoLogic.RotationPyomo.f_con_history_within(params, model)

Creates the within year history constraint that links the history between growing season 0 and growing season 1 for each rotation phase on each LMU. Note this constraint is skipped if there is only one growing season.

The rotation constraints are to ensure that the rotation phases that are selected in the optimisation can be arranged into an actual rotation. All phases except the continuous rotations require at least one other phase. Eg. a canola(z)-wheat(w) rotation would be generated from 2 phases Y Y N E z and Y Y E N w. To represent this requires ensuring that each rotaion phase selected has a preceding phase that has landuses in the same order as the target rotation phase (except for year 0). This is called the history required and history required.

AfoLogic.RotationPyomo.f_phase_history4_within(model)

Within weather-year constraints for season 2 constrained by the immediately preceding season 1 - for now all this does is allow/constrain the selection of a dual land-use phase based on the phase in season 1. Eg. sorghum after canola can only be selected if canola was the season 1 land-use.

Note: k is the same as h4 so just use landuse as the h4 set

This is the between year version of above. This is required because in the late breaks the phase from the previous year needs to carry over so that dry pasture and stubble can exist.

The phase link constraint is used to force the selection of v_phase_change when a phase change is required. This is necessary because v_phase_change incurs costs and includes the requirement for seeding.

The phase area selected in each phase_period must be at least the area selected in the previous period and the increment area incurs the costs to date (so that selection at later nodes is not ‘cheaper’ than earlier selection).

The transfer of the phases selected in the parent weather-year to the child weather-years is achieved in the same manner as the transfers of stock, pasture and cashflow with 2 differences:

  1. the inclusion of v_phase_change_increase which allows extra area of a phase to be selected in each node.

  2. the constraint is equal-to rather than less-than. This is necessary to cover a situation in which the cashflow parameter of v_phase_change_increase is earning money. In this situation the model would be unbounded with a less-than constraint.

AfoLogic.RotationPyomo.rotation_precalcs(params, report)

Call rotation precalc functions.

Parameters:

  • params – dictionary which stores all arrays used to populate pyomo parameters.

  • report – dictionary which stores all report values.