As a consequence, a new “block_decomposed” option of the bytecode MEX has been
introduced to explicitly select the block-decomposed version.
Note that we do not always use the “block_decomposed” option even when the
“block” option has been passed to the user, in situations where the block
decomposition brings nothing (e.g. when evaluating the residuals of the whole
model).
Use the new time-recursive block decomposition computed by the preprocessor
for:
- the simulation of backward models with “simul_backward”
- the perfect foresight simulation of purely backward/forward/static models
Also note that in this case, the preprocessor now defaults to “mfs=3” (i.e. it
minimizes the set of feedback variables and tries to renormalize equations).
This replaces the previous algorithm based on Dulmage-Mendelsohn (dmperm), plus
an ad hoc identification of some equations that can be evaluated (those with a
LHS equal to a variable, the log of a variable, or the diff-log of a variable).
By the way, the block_trust_region MEX has been modified so that it accepts a
boolean argument to decide whether it performs a Dulmage-Mendelsohn
decomposition (if not, then it performs a simple trust region on the whole
nonlinear system).
This provides a significant performance improvement (of almost an order of
magnitude for solve_algo=14 on a 700 equations model).
Previously, LBJ was available:
– under stack_solve_algo=6 when neither block nor bytecode were present
– under stack_solve_algo=1 with either block or bytecode (but the documentation
was not making it clear that it was LBJ)
This commit merges the two values for the option, and makes them
interchangeable. LBJ should now be invoked with stack_solve_algo=1 (but
stack_solve_algo=6 is kept for compatibility, and is a synonymous).
This is more logical, since those values are constraints from the point of view
of the solver.
Also, this allows to have maxit and tolf options for the steady state solver,
at the level of the setup command, without a clash with the same option names
for the deterministic solver at the level of the solver command.
It is now supported by the MATLAB editor (as of R2022a).
The old ASCII notation is left in some files that we copy as-is from other
sources (e.g. in the contrib/ and m4/ subdirectories).
The particles submodule is not updated at this point, because it is in an
inconsistent state.
[skip ci]
There was no user interface, and the feature that it provides has lost
relevance over time.
Note that algorithms for block and/or bytecode still internally use some
equivalent of this parameter, but its initial value will no longer be
modifiable (which could lead to bugs, see commit
e49e7e906f).
Also adjust the periods in Simulated_time_series (output of the perfect
foresight solver in the workspace). Note that this dseries object contains the
observations for the initial condition (M_.orig_maximum_lag observations) and
for the terminal condition (M_.orig_maximum_lead observations).
See #1838.
Fix testsuite (wrong file name)
These command solve the problem where agents think they know perfectly the
future (they behave as in perfect foresight), but make expectation errors.
Hence they can potentially be surprised in every period, and their expectations
about the future (incl. the final steady state) may change.
Currently the sequence of information sets needs to be passed through a CSV
file. Another interface may be added in the future.
The algorithm uses a sequence of (true) perfect foresight simulations (not
necessarily as many as there are periods, because if the information set does
not change between two periods, there is no need to do a new computation).
There are two possibilities for guess values:
— the default is to use the initial steady state for the simulation using the
first-period information set; then use previously simulated values as guess
values
— alternatively, with the terminal_steady_state_as_guess_value option, use the
terminal steady state as guess value for all future periods (this is actually
what the “true” perfect foresight solver does by default)
Several tests need to be adapted, because they were implicitly making the
assumption that there is no auxiliary variable.
Incidentally, this closes#1731. This commit therefore also removes the
workaround introduced in 0391dbbeb1.
The routines use the find() function applied to a subset of columns of the
Jacobian, which in this case is a row vector. When passed a row vector, find()
returns row vectors (while it returns column vectors when passed a column
vector or a matrix). This case was not correctly handled.
By the way, fix bug where oo_ was not modified by solve_one_boundary.
Also convert oo_.deterministic_simulations.status to a boolean in the block
routines, for consistency with the non-block case.
Because at some point throwing exceptions from MEX files (with mexErrMsgTxt())
was not working under Windows 64-bit, we had designed a workaround to avoid
using exceptions.
Most MEX files were returning an error code as their first (or sometimes last)
argument, and that code would have to be checked from the MATLAB code.
Since this workaround is no longer needed, this commit removes it. As a
consequence, the interface of many MEX files is modified.
For some background, see https://www.dynare.org/pipermail/dev/2010-September/000895.html
It constructs the stacked residuals and jacobian of the perfect foresight
problem.
It is an almost perfect replacement for the perfect_foresight_problem.m
routine, while being much more efficient.
Note however that the DLL never return complex numbers (it instead puts NaNs at
the place where there would have been complex). This may create problems for
some MOD files; the algorithms will need to be adapted to use a more
line-search method.
Sébastien Villemot
Johannes Pfeifer
Stéphane Adjemian (Ryûk)
MichelJuillard
Michel Juillard
Houtan Bastani