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).
Currently two threads are used (one for the dynamic MEX, one for the static
MEX). When the sparse representation is implemented, four threads will be used.
Closes: #41
This is unsafe since the find() method can return a past-the-end iterator,
which should be tested for.
Replace most instances by calls to the std::map::at() method (which throws if
the key is unknown), and which is incidentally more readable.
Elements of params_derivatives could be accessed without them being defined,
thus causing illegal memory read.
Ensure that these elements always exist. By the way, use std::map::at() instead
of std::map::find() to trigger an exception instead of an illegal memory read
in that case.
When computing the derivatives or block decomposition of the planner objective,
the epilogue or the original Ramsey model, the preprocessor would talk about
dynamic/static model, which was confusing. It now uses the right terminology.
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.
– factorize common code between the static and the dynamic version
– reorganise language-specific code into dedicated functions
– use a function template in the main helper to do some computations
at compile-time (using constexpr features)
– a generic one: CommonEnums.hh
– and a bytecode-specific one: Bytecode.hh
By the way, rename global constant “near_zero” into “power_deriv_near_zero”,
for clarity.
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.
– Indicate whether we are trying to normalize the static or dynamic model
– If failed to normalize the static model, suggest to use the “no_static”
option
– Remove a superfluous error message
In a model with [static]/[dynamic] equations, if the user was using include_eqs
with a list of equations that does *not* contain equations marked
[static]/[dynamic], then the call to ModelTree::includeExcludeEquations(…,
static_equations=true) would have an empty list of equation tags (as stored
in tag_eqns).
The right behaviour in this case is to exclude all static equations. However,
the code would exclude none, and this would disrupt the equilibrium between
[static] and [dynamic] equations (since all [dynamic] equations were excluded
by the other call to the same method).
The fix consists in removing the shortcut that returns from the method if
tag_eqns is empty.
Consequently drop “occbin” option to “model”.
Incidentally, allow more values in equation tag names (previously some keywords
such as “alpha” were disallowed).
Ref. #68
Sébastien Villemot
MichelJuillard
Willi Mutschler