11. Terminal conditions
A perfect-foresight simulation over periods 1 to T is a stacked system, and the equations of the last period reach one step beyond it. Something has to supply that step. Whatever supplies it is the terminal condition, and it is an assumption about where the economy ends up.
RISE offers three, through one option:
perfect_foresight(m, 'simul_terminal_condition', 'steadystate') % default
perfect_foresight(m, 'simul_terminal_condition', 'stationary')
perfect_foresight(m, 'simul_terminal_condition', 'firstorder')
11.1. What each one asserts
steadystate y(T+1) = ybar the economy has arrived
stationary y(T+1) = y(T) it has stopped moving
firstorder y(T+1) = ybar + S*(y(T) - ybar) nothing: the model decides
steadystate is the default and remains so. It is the right choice
whenever the horizon is long enough that the economy really has settled by
T, and it needs no first-order solution.
stationary exists for commitment and optimal-policy models, whose
terminal steady state is not unique because the policy multipliers carry a
unit root. It frees the terminal and pins it by stationarity, solving the
whole boundary-value problem jointly.
firstorder closes the system with the model’s own first-order solution.
The terminal leads stop being numbers and become a function of the terminal
state, so the economy is allowed to still be away from the steady state at
T, as long as it is close enough to behave linearly.
11.2. Why the third one saves horizon
Under steadystate the last period is told that the economy has arrived.
If it has not, that mistake propagates backwards, which is why long-horizon
work pads the simulation and throws the tail away.
Under firstorder there is nothing to pad. On a linear model the closed
path is the model’s first-order solution, exactly, at any horizon. On a
nonlinear one the near window is typically one to three orders of magnitude
closer to a long-horizon reference than the steady-state close gets it, and
the gap widens as the horizon grows.
Use it when:
the simulation genuinely does not end at the steady state — a long transition, or a permanent shock still working through at T;
a shorter horizon is worth having, since a stacked solve is roughly linear in the number of periods;
the three modes should agree and you want to know whether they do. Disagreement where they should agree is a diagnostic.
11.3. Regime switching
In a deterministic simulation the sequence of regimes is data. The plan carries it:
p = simplan(m, [0, 40], 1);
p = append(p, 'regime', 0:6, 1);
p = append(p, 'regime', 7:40, 2);
So the stacked system is already a stack of regime-specific systems, one per period, and the terminal condition inherits the same treatment: it is built from the regime the path ends in, and holds that regime from the terminal date onward. That is the only continuation the path itself declares. Ending the same simulation in a different regime gives a different terminal law, as it should.
A path that switches is not described by either regime’s law on its own before the switch, because agents see the change coming. It settles onto the terminal regime’s law once the regime has been constant for a period or two.
Note
A perfect-foresight stack over a model with endogenous switching, where
the transition probabilities depend on the state, is refused under analytic
derivatives with
RISE:perfectForesight:endogenousSwitchingDerivatives. Pass
'solve_derivatives_type', 'numerical' there, which differentiates the
equations the solver actually evaluates. Constant transition probabilities
need nothing.
11.4. What it refuses
Each of these has a silent alternative — close at the steady state and say nothing — which would hand back a path you believe the model closed when it did not.
terminalLawNotFound no stable continuation to rest on
terminalLawExplosive the continuation explodes
terminalRegimeCannotPersist the chain forbids that regime to persist
terminalPinnedAndFirstOrder a terminal value was also set by hand
terminalNotForConditional a conditional forecast with freed shocks
terminalNotForRecursiveBlocks a lead-only block solved by recursion
terminalStructureUnavailable no first-order solution could be obtained
All carry the prefix RISE:perfectForesight:.
11.5. Two consequences worth knowing
The stack is solved as one block. The terminal law is dense across every endogenous variable at the terminal date, so the terminal lead of a variable in an early block depends on the terminal state of variables in later ones. Block triangularization cannot express that, so this mode solves the whole stack together. Blocks remain the default in every other mode.
A terminal value set by hand is refused, not blended. endval and the
first-order close are two different answers to the same question. Pick one.
11.6. Watching a stacked solve
Unrelated to the terminal condition, but reached through the same command. Ask the stacked Newton solver to show its work and each iteration prints a row:
algo = rise.engine.generic_tools.reset_optim_options('sparse', 'solve');
algo{2}.Display = 'iter';
perfect_foresight(m, 'simul_historical_data', p, ...
'simul_stack_solve_algo', algo);
Iter Residual worst equation Step largest move Back
---------------------------------------------------------------------------------------
1 0.182325 C+K=K{-1}^alpha~ t=2 16.7542 K t=1 0
2 0.000948618 C^(-gamma)=beta~ t=1 0.670519 K t=29 0
The residual and step columns say how badly the solve is going. The two name columns say why: which equation is the obstacle, and which variable is moving, each with the period it happened in. A solve that fails to converge is one of the least pleasant failures in this kind of work, and being told live which equation is fighting usually identifies the problem at once.
Names are clipped to a fixed width so the table stays aligned whatever the model calls things.