initval must come before endval

Dynare assumes that in the *.mod file the initval block comes before the endval block. This is not checked by the preprocessor

What do you mean with "assume"? My impression is that the problem is about implicit functionality. How about finally implementing the new syntax proposed at https://archives.dynare.org/DynareWiki/DeterministicSimulationBlocks

The Dynare code is written in such a way that initval must come before endval otherwise the initialization isn't correct.

OK for https://archives.dynare.org/DynareWiki/DeterministicSimulationBlocks, but computing the steady state after historical_conditions isn't that simple because the values may be different for different lags. historical_conditions(steady_state) instead of a block would work but we also need guess values for the nonlinear solver.

1. With incorrect, you mean that initval will overwrite whatever an earlier endval set for the terminal periods?
2. I amended the wiki. historical_conditions(steady_state) is a good idea. It also allows using the values in the block as starting values for numerical steady state finding. But I don't get the point about values may be different for different lags. That violates being in a steady state where variables do not change over time.

1. I didn't analyze in details but for sure it doesn't work.
2. If historical_conditions replaces histval, it is meant to specify initial conditions possibly out of the steady state and different values for different lags

assigned to @sebastien

added bug label

mentioned in issue dynare#1867

changed milestone to %6.x

closed with commit ac35ef61

mentioned in commit dynare@0e5f9def

mentioned in commit ac35ef61

@sebastien I think the current implementation is wrong. If there are two separate sets of simulations in a file, you will get an error message because the second initval will be following an endval, although it correctly proceeds another endval. Solow_growth_rate_changes.mod

reopened

It is true that having two simulations with initval/endval blocks in the same file was accepted (even if undocumented), but it would have incorrect semantics.

For example, if a variable was not declared in the second initval block, then its default value would be the value given in the first endval block, and not 0 as documented in the reference manual.

Fixing this is not trivial, so I’m more inclined to forbid that combination. Do you think that having two simulations in the same .mod file is important enough?

How about erroring out by default, but allowing to override this with nostrict ? That would allow to preserve backward compatibility if explicitly desired, but would enforce thinking about the issue going forward.

I’m not super enthusiast at the idea of adding more stuff to the nostrict option, because one may want to disable some checks without risking incorrect results as in the present case. And adding a new option just for the present issue seems like an overkill.

Ok. But is it possible to provide a meaningful error message? That is, provide an error that only one such statement is allowed instead of wrongly claiming the ordering is not correct?

Actually, even if it’s undocumented, it should be ok to have several initval blocks. So the problem is really the ordering: an initval block cannot follow an endval block. I thus think the error message is correct.

closed