It would previously forget to write the indices for the highest derivation
order (e.g. if order=3, then it would only write sparce indices up to 2nd
order).
Ref. dynare#1859
Such a decomposition has to be simulated with periods as the outer loop and
blocks as the inner loop.
It is enabled by default for purely backward/forward/static models, as long as
the “block” option is not given. In that case, “mfs” is also set to 3 by
default (until that value becomes the global default).
M_.time_recursive_block_decomposition is set to “true” when that decomposition
has been performed, “false” otherwise for the traditional decomposition (the
latter has to be simulated with blocks as the outer loop and periods as the
inner loop).
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 files are created under <basename>/+debug/dynamic_resid.m and
<basename>/+debug/static_resid.m.
Their purpose is to evaluate separately the LHS and RHS of each equation.
Within a block, if mfs>0, the recursive variables would not appear in recursive
order. This could lead to wrong results in case of dependency relationships
between recursive variables.
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.
– print the information only for the final matching (and not the intermediary
ones that may have failed);
– print the equation name next to its number.
In an “evaluate” block, the LHS of a renormalized equation (such as “log(x)=…”)
could be associated to a temporary term that would then be incorrectly
computed: that temporary term would be evaluated *before* (and not after) the
evaluation of the associated variable (“x” in the example).
Should have no impact though, since diff nodes are already substituted out at
that point. But it’s better to implement it properly, in case we change the
substitution rules later.
By the way, make the computeSubExprContainingVariable method protected.
The previous system would spawn as many threads as there are object files to be
compiled (which could lead to hundreds of threads for large block-decomposed
models). This could pose a memory usage problem (even when not just waiting,
threads require memory for their own stack).
– 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)
By the way:
– improve the semantics by having a consistent treatment of empty substring
components (previously, only the last one was ignored)
– move it to DataTree to make it more accessible from elsewhere (even though
ideally it should be in a “utilities” namespace).
Sébastien Villemot
Johannes Pfeifer
MichelJuillard