In particular, makes clearer the distinction between configuration and
configuration file. The former includes information that is not in the
latter (command-line options.)
The implementation no longer relies on ramsey_policy.m at the MATLAB/Octave
level.
By the way, drop ModFileStructure::ramsey_model_present, which is now
redundant.
– M_.ramsey_orig_endo_nbr is the number of endogenous variables in the model
present just before adding the Lagrange multipliers and computing the Ramsey
FOC; it is by construction equal to the number of equations that will be added
by the process of computing the FOCs
– M_.ramsey_orig_eq_nbr is the number of equations in the model present just
before adding the Lagrange multipliers and computing the Ramsey FOC; it is by
construction equal to the number of Lagrange multipliers that will be added by
the process of computing the FOCs
Note that both may be greater than the number of endogenous/equations written
by the user, because some auxiliary variables may have already been added.
Also note that the number of policy instruments in M_.ramsey_orig_endo_nbr −
M_.ramsey_orig_eq_nbr
As a consequence, drop M_.ramsey_eq_nbr (which was actually equal to
M_.ramsey_orig_endo_nbr) and M_.orig_eq_nbr (which was actually equal to
M_.ramsey_orig_eq_nbr, but would also be set in the non-Ramsey case). The new
names are clearer.
The computing of the Ramsey steady state relies on the fact that Lagrange
multipliers appear linearly in the system to be solved. Instead of directly
solving for the Lagrange multipliers along with the other variables,
dyn_ramsey_static.m reduces the size of the problem by always computing the
value of the multipliers that minimizes the residuals, given the other
variables (using a minimum norm solution, easy to compute because of the
linearity property). That function thus needs the derivatives of the optimality
FOCs with respect to the multipliers. The problem is that, when multipliers
appear in an auxiliary variable related to a lead/lag, then those derivatives
need to be retrieved by a chain rule derivation, which cannot be easily done
with the regular static file.
This commit implements the creation of a new file,
ramsey_multipliers_static_g1.{m,mex}, that provides exactly the needed
derivatives w.r.t. Lagrange multipliers through chain rule derivation.
Ref. dynare#633, dynare#1119, dynare#1133
It was erroneously using MATLAB costs, leading to possible
inefficiencies (though those cost tables are probably not very accurate and
should be revised).
Previously, the MinGW location was appended multiple times to the PATH
variable, which in some cases would make the variable too long and thus
dysfunctional.
The variable is now initialized once when the worker threads are created.
By the way, move the macOS+Octave environment variable initializations to the
same place, for consistency.
As a consequence, and as a temporary measure, always output the
non-block-decomposed legacy representation.
Also drop the block kalman filter output, and drop now useless variables in
M_.block_structure.
It is no longer used in the new implementation of solve_algo={12,14}.
However, the M_.lhs field that was created by setup_solvers.m is used from
other places, so reimplement it at the preprocessor level.
The new representation is only supported for MATLAB/Octave, C and Julia output
for the time being. Bytecode and JSON are unsupported.
This commit adds new fields in M_.
This is a preliminary step for dynare#1859.
– DataTree::packageDir() now takes a std::string_view, returns a
std::filesystem::path, and no longer creates that directory
– DataTree::writeToFileIfModified() now takes a std::filesystem::path as
argument
– Do not call DataTree::writeToFileIfModified() for generating MATLAB/Octave
files, since it does not work (the directory inside which the file is written
has been deleted by the preprocessor just before)
– Consistently use DataTree::packageDir() everywhere (for compatibility with
planner_objective)
If block decomposition fails, error out if “block” option was passed, but not
otherwise.
This commit does not modify the generated files.
This is a preliminary step for dynare#1859.
In particular, use this feature in many loops which feature a special treatment
for the first iteration, using a boolean variable (replacing iterator
manipulation). By the way, also use std::exchange() to simultaneously test the
value of this variable and update it.
And, symmetrically, when the “bytecode” option is requested by the user, always
create the .m static/dynamic files.
The “bytecode” option therefore no longer modifies the preprocessor output.
Sébastien Villemot
MichelJuillard
Willi Mutschler
Johannes Pfeifer