mass balance not maintained in the c transaction matrices

[cboisvenue]

some of the matrices in sim$processes add-up to more than 1 (more than 100% of the carbon at time 0 at time 1 in a non-atmospheric input carbon pool) after a transfer. Here is an example, look at row == 17:

spadesCBMout$allProcesses$SlowMixing$'1'
      row col value
 [1,]   1   1 1.000
 [2,]   2   2 1.000
 [3,]   3   3 1.000
 [4,]   4   4 1.000
 [5,]   5   5 1.000
 [6,]   6   6 1.000
 [7,]   7   7 1.000
 [8,]   8   8 1.000
 [9,]   9   9 1.000
[10,]  10  10 1.000
[11,]  11  11 1.000
[12,]  12  12 1.000
[13,]  13  13 1.000
[14,]  14  14 1.000
[15,]  15  15 1.000
[16,]  16  16 1.000
[17,]  17  17 1.000
[18,]  18  18 1.000
[19,]  19  19 1.000
[20,]  20  20 1.000
[21,]  21  21 1.000
[22,]  22  22 1.000
[23,]  23  23 1.000
[24,]  24  24 1.000
[25,]  25  25 1.000
[26,]  26  26 1.000
[27,]  17  18 0.006
[28,]  17  17 0.994

[cboisvenue]

Interesting note: the disturbance matrices, which are also proportional, do not have that added one. Scott Morken when we built these did not add that initial identity matrix in the same way as as he did with all the other processes. Disturbance matrices which are loaded from the SQL CBM-CFS3 default data base also had the problem that they were not adding to one exactly (range from ~0.9899 to ~1.003). That later problem was fixed in commit 8dadadc (Nov 30, 2020). The former observation means that either they all need the identity matrices (the >1 values for each pool) or the yearly processes with transitional matrices need to be fixed to not have proportions over 1.

[cboisvenue]

problem addressed: all proportional matrices (Disturbances, BioTurnover, DomTurnover, DomDecay, SlowDecay, SlowMixing) rows (source pools) transfers add up to 1. Additive growth matrices have been checked: all carbon coming in comes from row 1 (input, so the atmosphere), while all other rows the value is equal to 1 so no carbon is lost. OvermatureDecline matrices are to be addressed in another issue (#7 ).