Mass conservation check failed when running with a resprouting oak

[XiulinGao]

I'm running with a resprouting oak using Adam's post-fire resprout scheme. Simulation includes two parts: 1) model spin-up under constant CO2 at 280ppm for 350 years from bare ground; 2) transient CO2 with recycled climate driver using rest file from the spin up.

I ran into 2 errors during this set of simulations. First, model failed during the spin up stage with an error pointing to the Forced DBH subroutine, which basically says that structural biomass is overshooting and the model cannot converge on DBH reset. I 'fixed' this error by restarting the run with a rest file and it ran passed the model time when the error occurred and finished the rest of the spin up (only 30 years left, so didn't run long enough to see if this is a recurrent error). The second error, which stays even restart the run, is this mass conservation check failed error, and it also points to structural biomass, see below:

PARTEH mass conservation check failed

142: Change in mass over control period should

142: always equal the integrated fluxes.

142: pft id: 1

142: position id: 5

142: organ id: 6

142: element_id: 1

142: position id: 1

142: symbol: struct_c

142: longname: Structural Carbon

142: err: 1.109128788812086E-009 max error: 1.000000000000000E-009

142: terms: 16778903.1432404 16778005.0976600

142: 1204.49316201732 306.447581692421 0.000000000000000E+000

142: 0.000000000000000E+000

142: Exiting.

10: error fraction: 0.000000000000000E+000

113: error fraction: 0.000000000000000E+000

82: error fraction: 0.000000000000000E+000

14: error fraction: 0.000000000000000E+000

142: ENDRUN:

142: ERROR in PRTGenericMod.F90 at line 1004

My thoughts on this is that this mass conservation error might be carried over from the first DBH reset error; and might be related to the resprouting scheme I'm using.

I'm working on doing another run by turning off resprouting to see if this error goes away, but appreciate any thoughts on this!

Thanks!

[rgknox]

interacting with @XiulinGao on this.

investigating ForceDBH, seems the two errors are related, seeing how the second error is related to structural biomass

[rgknox]

Here is the location of the call: https://github.com/NGEET/fates/blob/main/main/EDMainMod.F90#L633

So it looks like this is not associated with a fusion or a dbh correction throwing off the carbon balance...

One thing that I'm seeing is that this is an absolutely massive plant, the plant has 16,778,903.1432404 Kg of mass.... Like thats a mountain. It could be that the integrator is doing an ok job with relative error, but when applied to such a large plant... 1e-9 kg is a relative error of 1e-16 of this plant. I suppose that would not affect round-off, but I do suspect this is just an incredibly large plant that is overly stressing the allocation integration routine.

[XiulinGao]

want to say that turning off resprouting does not fix the problem, so the two might not be related. bumping up iteration number during DBH reset does not solve the problem, but it seems it's not related to the integrator anyways. I guess my question now is what might be causing such unrealistic, massive plant? Does this have something to do with cohort fusion? One thing I noticed is that I'm using very small d2ca_coefficient_min (max) values for the oak, 0.012, which generally means that with very large crown area after cohort fusion (i just saw that cohort fusion is conserving crown area and the crown area -DBH allometric reationship), the new cohort DBH can be very large. Not sure if this makes sense.

follow up: well, looks like it's averaged by the number of the plant when back calculating new DBH? which should not result in huge DBH