Summary
The resource constraint is violated by ~0.16 at the final period of a transition path, and the only available remedy is to raise RC_TPI far past its own schema maximum.
Downstream, OG-UK sets p.RC_TPI = 0.2 for exactly this reason, with an in-code comment attributing it to "a known boundary-condition discontinuity in fiscal.py". RC_TPI's paramtools validator is range: {min: 1e-13, max: 0.01}, so 0.2 is 20x the declared maximum and only takes effect by direct attribute assignment after update_specifications.
Measured
Benchmarking OG-UK at production shape (S=80, J=7, T=60, M=1, GS tax functions, ogcore 0.17.0), across four runs — baseline and a CIT reform, each under both TPI_outer_method settings:
baseline picard max_RC_error = 0.158020
baseline anderson max_RC_error = 0.158019
reform picard max_RC_error = 0.160140
reform anderson max_RC_error = 0.160146
Identical to six significant figures across solvers, so this is a property of the model at the path boundary, not a solver artifact. Interior periods are reported as well within 1e-4.
Why it is worth fixing rather than tolerating
What would help
Either a diagnosis of the terminal discontinuity — is it the tG2 spending rule, the terminal alpha_G/alpha_I treatment, the capital-good closure, or the truncation itself? — or, if it is inherent to truncating at T, an explicit statement to that effect plus a supported way to exempt the terminal period, rather than every downstream model rediscovering the 0.2 workaround.
Happy to help narrow it down if there is a view on the likeliest culprit. I have the four TPI pickles above and can profile resource_constraint_error by period and industry.
Related: #1210 (the check cannot exempt the terminal period), PSLmodels/OG-UK#72 and OG-UK#75 (the downstream workaround and an interim guard).
Summary
The resource constraint is violated by ~0.16 at the final period of a transition path, and the only available remedy is to raise
RC_TPIfar past its own schema maximum.Downstream, OG-UK sets
p.RC_TPI = 0.2for exactly this reason, with an in-code comment attributing it to "a known boundary-condition discontinuity in fiscal.py".RC_TPI's paramtools validator isrange: {min: 1e-13, max: 0.01}, so 0.2 is 20x the declared maximum and only takes effect by direct attribute assignment afterupdate_specifications.Measured
Benchmarking OG-UK at production shape (S=80, J=7, T=60, M=1, GS tax functions, ogcore 0.17.0), across four runs — baseline and a CIT reform, each under both
TPI_outer_methodsettings:Identical to six significant figures across solvers, so this is a property of the model at the path boundary, not a solver artifact. Interior periods are reported as well within 1e-4.
Why it is worth fixing rather than tolerating
RC_TPIdefault of 1e-4, so the transition path's central accounting identity is unverified at its endpoint.np.anyagainst a single scalar (Resource-constraint check cannot exempt the terminal period without waiving the whole path #1210), accommodating the terminal period waives the interior too. Resource-constraint check cannot exempt the terminal period without waiving the whole path #1210 proposes separating those; that makes the failure visible but does not remove it.RC_TPI.What would help
Either a diagnosis of the terminal discontinuity — is it the
tG2spending rule, the terminalalpha_G/alpha_Itreatment, the capital-good closure, or the truncation itself? — or, if it is inherent to truncating at T, an explicit statement to that effect plus a supported way to exempt the terminal period, rather than every downstream model rediscovering the 0.2 workaround.Happy to help narrow it down if there is a view on the likeliest culprit. I have the four TPI pickles above and can profile
resource_constraint_errorby period and industry.Related: #1210 (the check cannot exempt the terminal period), PSLmodels/OG-UK#72 and OG-UK#75 (the downstream workaround and an interim guard).