bradduthie/resevol

Crop growth option in resevol?

Closed this issue · 2 comments

A good point raised by @MattTinsleyStirling is that there is no option for a cells crop value to increase over time following crop rotation. This made me think that it might be easy to add such an option . The default value could be zero, but nonzero values could specify the proportion to add in each time step. For example, if there are two crops and we set the argument crop_growth = c(0.25, 0.5), then in each time step, the cell values for crop 1 could increase by 25 per cent, and the cell values for crop 2 could increase by 50 per cent. I actually don' t think that this would take too long to code (few hours, maybe?). Is it worth doing, you think, before submitting?

I have addressed this issue in commit d0c87b4daae391a1e4098e7d93ffbaa4b697eac8. This adds the new feature that @MattTinsleyStirling suggested. I've recorded the details in a journal currently on the dev branch (will publish later). Here they are:

During the revision process of the software note, Matt suggested another feature that I really should have thought of making earlier. In version 0.3.3.0, after crop rotation, landscape cell values are initialised with whatever value is used for crop_per_cell. This means that there is no way to simulate crop growth on a landscape in between crop rotations. In version 0.3.4.0, I have fixed this with two new arguments, crop_growth and crop_growth_type.

24 November 2022

The argument crop_growth indicates how much a cell value representing a given crop should change from one time step to the next (before the potential effects of feeding by pests). By default, this value is crop_growth = 0, meaning that all biomass on a cell will be initialised at the start of a new crop rotation. Nonzero values will affect the change of a cell's crop value in a way dependent up on crop_growth_type. Note that crop_growth can either take a single value, or a vector of the same length as crop_number. If, for example, there are two crops (crop_number = 2), then we could set crop_growth = c(0.1, 0.4), meaning that crop 1 would increase by a value of 0.1 each time step, and crop 2 would increase by a value of 0.4 each time step. If we set a crop_growth to a single value (e.g., crop_growth = 0.1), then all crops grow at the same rate of crop_growth.

The argument crop_growth_type specifies how growth is enacted (i.e., how the value on the landscape changes). The default option is crop_growth_type = "none", in which case, no growth occurs. If crop_growth_type = "geometric", then the value of crop_growth specifies the proportion by which the landscape value increases in a time step,

$$value_{t+1} = value_{t} \left(1 + crop_growth \right).$$

So if we initialise a crop amount at 2 on the landscape cell, and crop_growth = 0.1, then in the next time step (unless some crop is eaten by pests), we can predict that the crop amount will be r 2 * (1 + 0.1) (i.e., an increase of 10 per cent).

If crop_growth_type = "linear", then the increment crop_growth is simply added to the existing cell value in each time step.

$$value_{t+1} = value_{t} + crop_growth.$$

My hope is that these options will be useful for a lot of purposes, but there is plenty of room for expanding the package with different rules for crop growth.

Okay, I've added the new features to the manuscript in a very short paragraph in commit a803be55eab270745a19bce47827a778b522b966. I think that should be Issue #47 taken care of, unless anyone objects to its inclusion in the package! It offers some nice new options, and the default is no growth between crop rotations, so nothing has actually changed unless you want it to change.