dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-11-24T10:32:33Zhttps://git.dynare.org/Dynare/dynare/-/issues/1823Fix or block interplay of stochastic Ramsey and block2021-11-24T10:32:33ZJohannes PfeiferFix or block interplay of stochastic Ramsey and block1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. Whe...1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. When overriding this and moving into `dyn_ramsey_static`, the `nblock`-input of the `+FNAME.static.m`-file is not set, suggesting that `block` is not supported in the first place.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2021-05-07T17:10:32ZSébastien VillemotOption mfs=3 gives wrong resultThe `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible ...The `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2021-05-04T09:21:20ZSébastien VillemotBetter interface for mfs optionThe `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is t...The `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1243Allow model-local variables with block and bytecode2020-11-13T09:06:11ZJohannes PfeiferAllow model-local variables with block and bytecodeWe currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variable...We currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1727Blocks of type "evaluate backward" are not correctly simulated2020-09-23T13:29:57ZSébastien VillemotBlocks of type "evaluate backward" are not correctly simulatedThe testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The t...The testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [x] Fix the bug in bytecode
- [x] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1710num_procs doesn't exist in Matalb R2019b anymore2020-02-22T17:49:35ZMichelJuillardnum_procs doesn't exist in Matalb R2019b anymoreThere is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_o...There is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_order_perturbation``
A possible alternative would be an undocumented Matlab feature: ``feature('numcores')``
Undocumented Matlab features are discussed in this old document: http://undocumentedmatlab.com/articles/undocumented-feature-function/ but is still working.https://git.dynare.org/Dynare/dynare/-/issues/1245Make sure _dynamic-file from block returns with proper arguments2019-12-04T14:52:11ZJohannes PfeiferMake sure _dynamic-file from block returns with proper argumentsCurrently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
Currently, there are a few `return` statements where `varargout` has not been set, leading to crashes instead of proper switching to homotopy.
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/407Test for block with stack_solve_algo=3 is broken2019-06-19T15:38:18ZSébastien VillemotTest for block with stack_solve_algo=3 is brokenIt enters an infinite loop, and has therefore been disabled in 25269c3c6bb608f3295c308c156ce7bac2836d6a.
It enters an infinite loop, and has therefore been disabled in 25269c3c6bb608f3295c308c156ce7bac2836d6a.
4.4https://git.dynare.org/Dynare/dynare/-/issues/148Integrate dr_block.m into the new structure for stochastic solvers2016-06-10T12:49:08ZSébastien VillemotIntegrate dr_block.m into the new structure for stochastic solvers4.5https://git.dynare.org/Dynare/dynare/-/issues/77provide all solve_algo for all representations of the model2013-02-21T15:07:22ZSébastien Villemotprovide all solve_algo for all representations of the modelFor the moment, only some combinations of block, bytecode and stack_solve_algo are available. Allow for the possibility to use all the algorithms for all model representation.
For the moment, only some combinations of block, bytecode and stack_solve_algo are available. Allow for the possibility to use all the algorithms for all model representation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/134Reorganize M-structures used for storing block decomposition information2013-02-21T15:05:28ZSébastien VillemotReorganize M-structures used for storing block decomposition informationSee the following page for the current state:
http://www.dynare.org/DynareWiki/GlobalVariableBD
See the following page for the current state:
http://www.dynare.org/DynareWiki/GlobalVariableBD
4.3https://git.dynare.org/Dynare/dynare/-/issues/253bytecode: implement the possibility of handling complex numbers2013-02-21T14:56:04ZSébastien Villemotbytecode: implement the possibility of handling complex numbersFor some models (GIMF in particular), it would be interesting if the bytecode DLL could switch to complex numbers when the solver go into an area outside the domain of definition of functions in the real numbers.
MATLAB routines already...For some models (GIMF in particular), it would be interesting if the bytecode DLL could switch to complex numbers when the solver go into an area outside the domain of definition of functions in the real numbers.
MATLAB routines already do this, and it helps a lot solving complicated problems.
https://git.dynare.org/Dynare/dynare/-/issues/292model_diagnostics and lead/lag on exogenous variables2013-02-21T14:54:09ZSébastien Villemotmodel_diagnostics and lead/lag on exogenous variablesmodel_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones
model_diagnostics breaks when there are longer lead/lag on exogenous variables than endogenous ones