spinup stop - need to confirm the % variation accepted for the soil carbon pools to stop spinup

[cboisvenue]

There is a threshold (which I think is +/- 10% in soil pools) at which spinup stop the simulations. This is embedded in the c++ scripts. We need to confirm: 1) what is that threshold, 2) can we change it, and 3) can we make is a sim parameter.

The controls for the max and min number of iterations for the spinup can be controlled via $maxRotations and $minRotations set by the user in CBM_dataPrep_SK.

[cboisvenue]

Compared one sim with SK default runs (which have the max rotations set to 30) and a sim (SK) with default set to 15000. Maximum rotation is the number of times each pixel group is burnt during spinup simulations. The resulting pools (sim$cbmPools) and the spinupResults (sim$spinupResult) from each simulations were equal. The Cache() call around the Spinup() c++ function was removed. This result (spinup with 30 or 15000 max rotation) either means that the threshold to stop spinup (stabilization of the soil pools) is reached before 30 rotation OR that we cannot really change the default number of rotations for the spinup in the R scripts. The changes were made in in two places: CBM_defaults, right after the creation of sim$cbmData, the last column of sim$cbmData@spinupParameters was change from 30 to 15000 (30X500) and in the CBM_dataPrep_SK, the sim$maxRotations (line 327) was set to a vector of 15000. Test to check which of these it is: when the max rotations was set to 15, with minimum rotation to 5, the sim$spinupResult and the sim$cbmPools were not equal. Hence, we can assume that the min and maximum rotations for the spinup can be set in the R script and that a threshold (+ or - 10%) is set in the c++ scripts.

[cboisvenue]

I asked Mark Hafer (in charge of reporting for CAT). Here is his answer:
Hi Celine,

The Kurz et al 2009 paper says that the spin-up iterations stop when the sum of aboveground and below ground slow DOM pools differs by less than 1% over two successive rotations (not timesteps). I don’t see this threshold as a definable parameter in any of the Makelist input files, so it must be buried in the code. I haven’t confirmed this with Scott, though I have no reason to doubt it.

I’m just speculating, but I wonder if Doug’s mention of 80/20 had to do with the assumptions used by CAT’s inventory roll-back tool to allocate the final stand-replacing disturbance to wildfire or clearcut? I know Werner has been trying to explain to Doug why the final stand-replacing disturbance type assumptions in NFCMARS are so drastically different from what our recent analysis of actual disturbance history data found.

Mark