Multi-modal with mode_compute = 4

Hi all,

I have a DSGE model with more than 30 parameters to estimate, including the persistence and standard deviations of seven shocks. I am taking Bayesian estimation strategy to estimate the model. At the first stage to find the mode, I take “mode_compute = 4” in Dynare 4.4.3, which is essentially to use the Chris Sim’s optimization function “csminwel” to search for the mode. Yet, something strange comes out. There is one estimated parameter (not shock process), which is specified with relatively loose prior. It turns out that, under this loose prior, the estimated mode value of this parameter is highly depends on the choice of its initial value in the “estimated_params” block. If I start with a low initial value (around 2 or 3), the estimated mode is around 10; If I start with a high initial value (around 30), the estimated mode rises up to more than 50. The discrepancy is very much significant. Moreover, for both cases, the “model_check” plots indicate this parameter is well identified, evidenced by the facts that each of the mode standing at the peak of the associated posterior likelihood function (a parabola going downwards).

I have several puzzling issues
1, Does that mean there are something wrong with my model setup?
2, Can we say this parameter have two modes?
3, Is this parameter poorly identified, maybe not locally but globally?
4, In general, what would be the reason for this situation to happen?
5, Could you give some suggestions on how to deal with this issue?

Many thanks in advance!


It is not unusual for the posterior to have several modes. This is not a problem with identification but the fact that you are using a local mode finder. Newton-type optimizer use the steepest ascent to find the nearest optimum. But your goal usually is to find the global mode, so you should compare the posterior density at the respective modes. Is there a significant difference?

Hi Johannes,

Thank you so much for your help. I am very sorry for my late reply.

You are totally right, it seems the “mode_compute = 4” option will find a local optimum which has no problem with identification but depends very much on the choice of initial values. I did the experiment you suggested:

I am estimating the price stickiness and wage stickiness parameters, but I am using Rotemberg price setting. Thus, the parameters are the price adjustment cost (dubbed as “psip”) and wage adjustment cost (dubbed as “psiw”), of course in combination with the estimation of many other structure parameters of the model. I specify the prior for both price adjustment cost “psip” and wage adjustment cost “psiw” as normal distribution with mean 100 and standard deviation 50, i.e., (NORMAL_PDF,100,50) in the “estimated_params” block. I tried three different cases:

(1), With initial value (psip,psiw) = (10,2), the estimated mode of (psip,psiw) = (19.4920,5.5919), and Log data density [Laplace approximation] is -1077.881561.

(2), With initial value (psip,psiw) = (100,10), the estimated mode of (psip,psiw) = (59.2364,9.1490), and Log data density [Laplace approximation] is -1075.317601.

(3), With initial value (psip,psiw) = (100,100), the estimated mode of (psip,psiw) = (97.7771,104.1616), and Log data density [Laplace approximation] is -1072.975624.

How to interpret these results? Do you think the posterior density at the three respective modes have a significant difference?

One additional questions:
(1), Are there some global method to find the mode? Is “mode_compute = 6” a global method?

Many thanks!



  1. We are not looking for the marginal data density, but for the posterior. There should be somewhere
Final value of minus the log posterior (or likelihood): xxx 
  1. mode_compute=9 is designed to be a global optimizer.

Hi Johannes,

You are absolutely right. We should look at the log posterior or log likelihood rather than marginal data density. I checked that what has been printed by running mode computation in Dynare is “Fval obtained by the minimization routine: XXX”. For the three cases:

(1), With initial value (psip,psiw) = (10,2), the estimated mode of (psip,psiw) = (19.4920,5.5919), and “Fval obtained by the minimization routine: 1009.485985”.

(2), With initial value (psip,psiw) = (100,10), the estimated mode of (psip,psiw) = (59.2364,9.1490), and “Fval obtained by the minimization routine: 1009.103915”.

(3), With initial value (psip,psiw) = (100,100), the estimated mode of (psip,psiw) = (97.7771,104.1616), and “Fval obtained by the minimization routine: 1008.189997”.

Do you think the log likelihood numbers have a significant difference?

I tried to run mode_computation = 9 following your suggestion. For all the above three cases, I get the same warning messages:

(minus) the hessian matrix at the “mode” is not positive definite!
=> posterior variance of the estimated parameters are not positive.
You should try to change the initial values of the parameters using
the estimated_params_init block, or use another optimization routine.
Warning: The results below are most likely wrong!”

But these warning messages do not show up when I run “mode_compute=4”. What does that mean? Does it mean the priors (NORMAL_PDF,100,50) for (psip,psiw) have some problems? maybe the priors specification are too loose?

Thank you so much for your help!


What was the value of the log posterior from mode_compute=9? And what do the mode_check-plots show?
If the reported values are minus the posterior, then the mode of (psip,psiw) = (97.7771,104.1616) dominates the other ones and should be used.

Hi Johannes,

Under mode_compute =9, the values of log posterior are 1112.837076, 1037.023100, 1081.629964 respectively. However, the mode_check_plots do not seem to display good shape.

Thank you so much for your patient! I have learned a lot under your help, many thanks!


Hi Prof Pfeifer, how should we think about these errors?
"Warning: The results below are most likely wrong! " and "Warning: Matrix is singular, close to singular or badly scaled. Results may be inaccurate. RCOND = NaN. "
This error appears in implementing the Chari_et_al_2007 BCA replications mod file. Mode check plots are not really good and all the MLE results contains a lot of NaNs.

                          Estimate    s.d. t-stat

P0_z_bar                   -0.6866     NaN     NaN 
P0_tau_l_bar               -0.3107     NaN     NaN 
P0_tau_x_bar                0.2533     NaN     NaN

Does it mean we can sometimes ignore these warnings as the MLE estimation is not the best even in the original paper (using their estimated parameters as initial values).

In that case, you most probably did not find the mode. No, you cannot trust the results.

Thanks. It is strange though that dynare cannot find the mode although the initial parameters in your replication mod file are exactly those in the original paper.

So I guess the optimization routine used by Chari_et_al_2007 is not yet available in dynare, and although the mode sometimes exist, dynare is not always able to find it. For example, in this case, maybe we can still trust the results of the replication, although there is a problem with finding the mode. Or perhaps there is a problem in the replication mode file, causing dynare not to find the mode.

You should inspect the mode_check-plots. We do not really care about the Hessian in this context. A corner solution would be fine.

Yes, the replication files replicate their results (figure 5), but the mode check plots seem not great in dynare. My thinking was that if the mode check plots are not great when replicating the results in dynare (using the original parameter values in the paper as initial values), then perhaps, the mode check plots won’t be great either when applying the model to different data in dynare.

Screenshot from 2021-10-21 10-10-37

Maybe. There is a reason people nowadays don’t use MLE, but rather Bayesian estimation.

1 Like