Block decomposition failure with change_type() in Dynare 6

Hi Dynare Team
I am running into a block decomposition incompatibility issue when running a toolbox that was made to be used for older versions of Dynare (presumably Dynare 4.x); and I am running Dynare 6. The toolbox uses the change_type() command extensively for calibration purposes.

When running models that use change_type() to flip variables between parameters and endogenous variables (for calibration via homotopy), Dynare 6.x’s preprocessing fails during block decomposition with the following error:

Normalizing the dynamic model...
Normalization failed with cutoff, trying symbolic normalisation...
Could not normalise the dynamic model. Variable [VARIABLE NAME] is not in the maximum cardinality matching.
ERROR: Block decomposition requested but failed.  
  • There appears to be no command-line option to disable block decomposition in Dynare 6.x (unlike block=false in older versions);
  • Setting options_.block = false within the mod file does not affect preprocessing
  • The block decomposition is automatically attempted during pre-processing and cannot be bypassed.

So my questions are:

  1. Is there a way to disable block decomposition during preprocessing in Dynare 6?
  2. Are there known incompatibilities between change_type() and Dynare 6’s block decomposition algorithm?
  3. Would this be considered a regression from earlier Dynare versions, or is this an intentional design change?
  4. Are there recommended workarounds for large multi-country models that rely on change_type() for calibration?

Thanks for your time, and DM me if you have any privacy concerns regarding any of the above!

Dear David,
that looks like a bug. Do you have an example to trigger the issue? The default, starting in Dynare 6, is to always compute the block decomposition of the model. I have never seen that type of error before and would view that as a regression.

1 Like

Unfortunately I can’t share the code, and given the size of the toolbox, creating a minimum working example is a bit of a challenge. However, I can share complete error messages from the MATLAB console.
I’ll send this over a DM.

Hi,

has there been progress on this issue? I receive the same error message when I do a perfect foresight simulation with the non-linear solver:

Normalization failed with cutoff, trying symbolic normalization…
Could not normalize the dynamic model. Variable EAA_bf is not in the maximum cardinality matching.
ERROR: Block decomposition requested but failed.
Preprocessing time: 0h00m01s.
Error using dynare (line 295)
Dynare: preprocessing failed

I am wondering: EAA_bf is a stock variable. In the original, working version of the .mod file, EAA_bf is defined as a beginning of period value, by lagging the flow variable in the accumulation equation (e.g., say i is the flow, k is the stock, then the acumulation equation is given by k=i(-1)+k(-1)). I then changed the .mod file such that EAA_bf is now the end of period value (e.g., it is now k=i+k(-1), as we usually do in dynare). This change triggered the error message.

Given that we do not have code to replicate the issue, it is impossible to tell.

Hi Johannes,

true, so here are the files. The steady-state is loated from the .txt file. You have to execute example_shock.mod Many thanks for looking into this!

Best,

Ansgar

eagle_steady.txt (33.2 KB)

example_shock.mod (1.1 KB)

modeqs_CES_eopb.mod (45.0 KB)

initval.mod (16.7 KB)

init.mod (524 Bytes)

Oh, and I am using Dynare 6.5.

Thanks, but it seems a symdecls.mod is missing.

Ah I am sorry! Here it is.

symdecls.mod (6.4 KB)

My hunch is that there is now a fundamental issue in the model. If I remove the block option and check the Blanchard-Kahn conditions, I get

There are 137 eigenvalue(s) larger than 1 in modulus for 136 forward-looking variable(s).
The order condition is NOT verified.

model_diagnostics also complains about a singularity. That looks like the problem is not with the block decomposition but the model.

In Dynare 7 you will get a more explicit message

Could not normalize the dynamic model, i.e. it was not possible to construct a one-to-one matching between variables and equations. More precisely, variable EAB_bf could not be associated to an equation (either it appears nowhere, or the equations in which it appears had to be matched with other variables that appear nowhere else).