det_cond_forecast() depends on oo_.dr.state_var but this is not always available

det_cond_forecast() depends on oo_.dr.state_var but this variable is computed by dyn_first_order_solver. So it isn't available for a purely backward or purely forward model

changed milestone to %4.6

added bug label

There is something weird with state_var. It is both in oo_.dr and in M_ As I imagine the M_ version is computed by the preprocessor it would make more sense to always use that version and replace all occurences of oo_.dr.state_var

That is a complicated issue. As far as I know, M_.state_var is indeed created by the preprocessor based on the entered model-information - regardless of whether variables may drop out due to e.g. particular parameterizations. But in the past, we sometimes updated state_var based on the computed model solution. Here it could happen that variables dropped out. We had this a long time ago in discretionary_policy where it caused a bug so that we had to get rid of it. We should check whether oo_.dr.state_var can ever have different values than M_.state_var.

Related to #637 (closed)

assigned to @MichelJuillard

@MichelJuillard Do you have a test case for this ticket?

We removed the interface at preprocessor#39 (closed)

closed

We remove the interface but the .m function is still there. So should this bug really be closed?

reopened

I grep state_var in all *.m files of ./matlab. As far as I can see

1. M_.state_var is set by the preprocessor
2. dr.state_var is set in dr_block.m and in dyn_first_order_solver.m
3. I couldn't find code which would make dr.state_var different from M_.state_var

It seems possible to replace everywhere dr.state_var``` by M_.state_var, but we need to check every concerned function to make sure that M_`` is passed as argument.

This issue is about the fact that dr.state_var isn't set for all first order models, only for models with both forward and looking variables, the only kind handled by dyn_first_order_solver.m

The solution is to add dr.state_var = M_.state_var to resol.m that should handle all stochastic models. We keep the statement in dr_blocks.m and dyn_first_order_solver.m in the remote case that these functions are called without calling first resol.m

dyn_first_order_solver makes dr.state_var differ from M_.state_var. fs2000.mod has

M_.state_var = [1 2 7  13];
dr.state_var = [1 7 13 2];

so there is some resorting happening.

Yes indeed. This is consistent with the way dr.state_var is constructed in dyn_first_order_solver

• M_.state_var is ordered in var declaration order
• dr.state_var is ordered in dr.order_var This is one more reason to be careful with replacing dr.state_var by M_.state_var

Finally, I set dr.state_var for purely backward model in stochastic_solvers.m. det_cond_forecast.m requires much more efforts to make it work for purely backward models. I leave it for a comprehensive rework of conditional forecasting in Dynare.

@MichelJuillard Is there a branch with this fix?

@JohannesPfeifer : you can find it here: https://git.dynare.org/MichelJuillard/dynare/-/tree/state_var

mentioned in commit JohannesPfeifer/dynare@57bbec1f

mentioned in merge request !1928 (merged)

closed with commit 57bbec1f

mentioned in commit afeddc66