Actually I’m wondering whether it’s really a good idea to assign those variables in the main workspace. Beyond dyn2vec, there is also the preprocessor automatically assigning parameters in the global workspace (unless the minimal_workspace option is given to the dynare command). So we may also consider stopping doing this for version 6, unless there is a good use case for those assignments.
It would imply a pretty big break in backward compatibility. But I would be all for that change due to assignin and duplicating outputs being bad practices.
@sebastien We should discuss the exact implementation. I see two separate issues:
Having parameters in the base workspace under their name and the resulting assignin. This creates a mess. See e.g. set_param_value.m and update_all_parameters_in_workspace.m. I would remove the minimal_workspace-option and make it the default.
The calls to dyn2vec in stoch_simul and perfect_foresight_solver. We should have a Boolean output_vars_to_base_workspace-option mapping to options_.output_vars_to_base_workspace that is false by default and allows to invoke the dyn2vec-commands currently on by default.
if ~options_.minimal_workspace dyn2vec(M_, oo_, options_); end
I envision turning the default around to have
if options_.output_vars_to_base_workspace dyn2vec(M_, oo_, options_);end
In that case, the user must explicitly request to duplicate the data series from oo_.endo_simul in the base workspace. Similarly, for other assignin-related commands currently triggered by default. That way, there can also be no interference between our default setting and parallel executions.