When parsing the FSTPG{2,3} opcodes, the bytecode MEX internally constructs a
Jacobian with as many lines as feedback variables. But the preprocessor would
also output instructions for filling derivatives of equations corresponding to
recursive variables in the “evaluate” mode, thus leading to memory corruption
in the bytecode MEX.
Instead of crashing the preprocessor (because DataTree::DivisionByZeroException
is not caught), just abort the normalization and mark it as failed.
Ref. #92
Those models do not have as many variables as equations, and this case is not
supported by bytecode.
The present commit is an improvement over commit
a8ea57dd63, which had already removed bytecode
for the planner objective model.
The preprocessor would try to write bytecode for the planner objective. But
bytecode only works when there are as many endogenous as equations, which is
not the case for the PlannerObjective object derived from StaticModel.
This prevents destruction through a base pointer, which would a memory leak
since the destructor is not virtual (and we cannot make it virtual because it
would break our crude serialization strategy).
Temporary terms computed in previous blocks were not used in the bytecode
output of a given block. This was inefficient (because this means that
expressions already computed and store in the temporary terms vector would be
recomputed), and incidentally it would break the external functions
output (because it would trigger a lookup in the “TEF terms”, which would thus
fail).
Closes: #115
If the model is purely backward, determine whether all original equations have
a single contemporaneous endogenous on the LHS. If this is the case, then first
try a normalization by enforcing that each original equation is matched with
the endogenous on the LHS.
This helps with the simulation of purely backward models, where equations are
renormalized with mfs=3, since it produces a simpler system to be recursively
evaluated/solved.
It would previously return a boolean. The exception is more convenient for
producing a different error message in the case of the specialized algorithm
introduced in the next commit.
The C99 copysign() function was used in the generated C output, but that
function does not correctly handle zero. Replace it by a custom sign()
function.
Improve performance on very large models (⩾ 5000 equations).
Note that std::unordered_set cannot be used for the temporary_terms_t type,
because ordering is needed there (for writing the output files).
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.
Options “order”, “partial_information” and “k_order_solver” are not accepted by
the command (this code is probably a remnant of the deprecated “ramsey_policy”
command).
– 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
This is effectively a revert of commits 1b4f68f934,
32fb90d5f3 and f6f4ea70fb.
This transformation had been introduced in order to fix the computation of the
Ramsey steady state in the case where Lagrange multipliers appeared with a lead
or lag ⩾ 2 (and where thus part of the definition of an auxiliary variable).
But this transformation had introduced bugs in the handling of external
functions which were difficult to tackle.
Moreover, it seems preferable to keep the strict correspondence between the
dynamic and static model, in order to make reasoning about the preprocessor
internals easier (in particular, for this reason this transformation was not
implemented in ModFile::transformPass() but in ModFile::computingPass(), which
was a bit confusing).
A better solution for the Ramsey steady state issue will is implemented in the
descendent of the present commit.
Ref. dynare#633, dynare#1119, dynare#1133
If a given external function was called two times with different arguments,
then the second call would always be computed in the same temporary terms
chunk (derivation order or block) as the first call, even if this was not
necessary (technically, the second call would be promoted in the temporary
terms computation in the same category as the first call).
This could possibly lead to an inefficiency.
If an endogenous with a lead ⩾ 2 or an exogenous with a lead ⩾ 1 appeared in
the argument(s) of a call to an external function, the auxiliary variable
transformation was incorrect (the variable was replaced inside the function
call, while it is the whole function call that has to be replaced).
This could lead to incorrect results in stochastic contexts, when the external
function is nonlinear.
The first argument to ExprNode::computeTemporaryTerms() is supposed to be a
pair (endo derivation order, param derivation order). The two elements were
interverted in the call. This would not affect the result, because parameter
derivatives are not computed there and what matters is the lexical ordering
which remains the same. But fixing the order is better, for consistency with
the method description.
It was erroneously using MATLAB costs, leading to possible
inefficiencies (though those cost tables are probably not very accurate and
should be revised).
The argument had the same name as the data member “datatree”, so this could
lead to confusion (though there was no bug, since the argument was masking
the data member).
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.
Variable indices would be incorrect in the evaluated Jacobian if recursive
variables were present. This would lead to incorrect results and/or crashes in
bytecode MEX. This bug has been exposed by commit
f45a99fc68, which actually enabled mfs>0 for
static models.
Sébastien Villemot
Johannes Pfeifer
Willi Mutschler