Raising for discussion, not proposing — this is a breaking change and belongs to a major version if it happens at all.
Two pieces of mizer's own documentation currently say, in effect, that the default is the worse choice:
- The
run-simulation guidance says the default first-order upwind flux carries substantial numerical diffusion that smears cohorts and travelling waves and can completely damp real oscillations and limit cycles — a correctness issue for any study of dynamics, not an accuracy trade-off. Anyone doing that work is told to build with second_order_w = TRUE and project with method = "tr_bdf2".
- The
extend-mizer guidance says extension code that ignores the bin_average scheme looks correct, passes its tests (because the default is first-order), and is then silently wrong by around 10% for anyone who switched second order on.
Both warnings exist because the better scheme is not the default. Making it the default would collapse the first into "mizer does the right thing" and would make the second self-correcting, since the hazardous path would be the one everybody's tests run on.
The cost
Every unnormalised quantity moves. A bare second_order_w = TRUE also switches integrals over the size grid from a left-edge Riemann sum to a proper bin average, so biomass, yield and getDiet(proportion = FALSE) shift by roughly (1 + beta) / 2 — about 10% on a typical grid. Proportions and ratios largely cancel. Every published model's numbers change, every calibration needs redoing, and every snapshot test in every extension package breaks.
The current default exists so that older mizer versions reproduce byte-for-byte, which is a real virtue.
Questions
- Is byte-for-byte reproduction of pre-3.2 results still a goal, or has enough changed that a 4.0 could let it go?
- If it were switched, is a
defaults_edition()-style opt-out the right migration path — old models keep their scheme, new ones get the better one?
- Is there a middle option: keep
flux first-order by default but make bin_average second-order, since the ~10% integral shift is the part that silently poisons extension code?
Raised while auditing why several agent skills need long warnings about the numerical scheme.
Raising for discussion, not proposing — this is a breaking change and belongs to a major version if it happens at all.
Two pieces of mizer's own documentation currently say, in effect, that the default is the worse choice:
run-simulationguidance says the default first-order upwind flux carries substantial numerical diffusion that smears cohorts and travelling waves and can completely damp real oscillations and limit cycles — a correctness issue for any study of dynamics, not an accuracy trade-off. Anyone doing that work is told to build withsecond_order_w = TRUEand project withmethod = "tr_bdf2".extend-mizerguidance says extension code that ignores thebin_averagescheme looks correct, passes its tests (because the default is first-order), and is then silently wrong by around 10% for anyone who switched second order on.Both warnings exist because the better scheme is not the default. Making it the default would collapse the first into "mizer does the right thing" and would make the second self-correcting, since the hazardous path would be the one everybody's tests run on.
The cost
Every unnormalised quantity moves. A bare
second_order_w = TRUEalso switches integrals over the size grid from a left-edge Riemann sum to a proper bin average, so biomass, yield andgetDiet(proportion = FALSE)shift by roughly(1 + beta) / 2— about 10% on a typical grid. Proportions and ratios largely cancel. Every published model's numbers change, every calibration needs redoing, and every snapshot test in every extension package breaks.The current default exists so that older mizer versions reproduce byte-for-byte, which is a real virtue.
Questions
defaults_edition()-style opt-out the right migration path — old models keep their scheme, new ones get the better one?fluxfirst-order by default but makebin_averagesecond-order, since the ~10% integral shift is the part that silently poisons extension code?Raised while auditing why several agent skills need long warnings about the numerical scheme.