Error in get_consumption_equivalent

Hello everyone

I have been asking recently in the forum about welfare analysis, this time I am trying to obtain the consumption equivalent (CE), my utility function is of the form:

E_t\sum_{t=0}^{\infty}\beta^t\left[\xi_tlog\left(C_t\right)-\vartheta\frac{L_{j,\ t}^{1+\varphi}}{1+\varphi}\right]

Due to the consumption preference shock \xi_t, I can’t solve the infinite sum so I’m trying to get the CE numerically, I followed Professor Pfeifer’s link DSGE_mod/Born_Pfeifer_2018/Welfare at master · JohannesPfeifer/DSGE_mod · GitHub and I think I found a mistake, in the file Born_Pfeifer_2018_welfare.mod On the line


I think it should be


I am right?

I have an additional doubt related to the calculation of the CE, imagine that I have a given reference welfare level, say, -99.50…, I tried to modify the files of professor Pfeifer to consider this fact, in the part of the csolve that goes in the mod file , I have the following lines

%computed consumption equivalent

because I am interested in conditional welfare, however, I have more doubts in the file get_consumption_equivalent_conditional_welfare. Professor Pfeifer adds two options, use Ramsey or generate the Welfare_gap variable. Since I already have the reference level of welfare (i.e. -99.50…) I think that neither of the two applies. I modified the Ramsey option because I think it is closer to what I want to do, but I don’t know if I did it correctly, I attach the file, however I am almost sure that I have something wrong, since my Recursive_natural_welfare_equivalent variable tells me that the conditional welfare is lower than the wellfare I put as a reference, but the CE I get is negative and the results don’t seem consistent, the biggest change I made to the get_consumption_equivalent_conditional_welfare file was to put


instead of


Is this correct? If someone could help me to know how to modify the file considering that I already have the reference level of welfare as given, I would greatly appreciate it.

Greetings to all

get_consumption_equivalent_conditional_welfare.m (2.3 KB)

  1. No, the first issue is not a bug, but a deliberate choice. Instead of starting with a 0 difference for the conditional case, we use the previously found CE for the unconditional case as the starting value. The working assumption is that the latter is reasonably close to the value for the conditional one. If the CE is unique, the starting value should not play a role.
  2. Without the full files, it is impossible to tell.

Thanks professor

  1. Great

  2. Sorry, I attach the mod file and again the get_consumption_equivalent

get_consumption_equivalent_conditional_welfare.m (2.4 KB)

Your comparison is wrong. You are currently asking how much consumption you need to add to get to the welfare in the Ramsey economy.

And how could I modify that last part of the get_consumption_equivalent file to consider that I already have a given reference level of welfare (i.e. -99.50)? It’s what I’m having trouble with.

Thank you

Doing tests with your file and the results of your paper Born/Pfeifer (2018), I think I was able to solve the problem. What I did with my model was calculate welfare for a given regime in a separate mod file and get the reference welfare value -99.5934, then I wanted to use your get_consumption_equivalent file but incorporating this reference value as already given. To make sure the changes I made to your file were correct, I did the following: I turned off the \xi_t shock so I could calculate CE analytically with the formula:
CE=(1-exp((1-betta)*(Welfare_con - (-99.593445526787140))))*100

Then I recalculated the EC but now with the file get_consumption_equivalent_conditional_welfare changing the last part of the code in the following way

global oo_ M_ options_

if par_value_lambda>1 %do not allow negative consumption

set_param_value('lambda_utility',par_value_lambda)  %set consumption equivalent lambda
if isempty(options_.qz_criterium)
    options_.qz_criterium = 1+1e-6;
[oo_.dr,info,M_,oo_] = resol(0,M_,options_,oo_); %get decision rules
if info(1) %filter out error codes
    %%%%%%%I changed the code starting from this part%%%%
    Welfare_con= oo_.dr.ys(Welfare_obs)+0.5*oo_.dr.ghs2(oo_.dr.inv_order_var(Welfare_obs));


and both analytically and numerically I get the same value for de CE, so I guess it’s correct. I’m just curious about two things from your files.

  1. What is the function of the term *100 in the line outvalue=(Welfare_con-(-99.593445526787140)*100? I noticed that if I increase it nothing happens with the result of lambda_utility i.e. the result of the CE is the same.

  2. I also noticed that it doesn’t matter if I put




My result for lambda_utility always has a negative sign (when it should be positive) and using your example of Born_Pfeifer_2018_welfare.mod the opposite happens, no matter how I arrange it, I always get the correct (positive) sign, What is the reason?

I hope I have explained myself, I attach files just in case
Thanks in advance


  1. The 100 is simply for scaling the residual. In my own codes, the welfare levels were rather small. Multiplying by 100 moved the numerical operations to a more reasonable range and facilitated the numerical solver. If you find a root of the equation, it should not matter.
  2. Again, we are looking for a zero value for outvalue. Putting a minus in front of everything does not matter.
  3. The reason is again in the question you are asking. The Ramey welfare level is higher. So you need to add consumption in the baseline to achieve that level. If you start with (1-\lambda)c_t, obviously \lambda<0 means more consumption.


For some reasons, I keep getting this " Reference to non-existent field ‘dr’. " warning when the code run over get_consumption_equivalent_conditional_welfare. I think there might be a problem with the resol command in my matlab (which doesn’t sound sensible to me)? I would truly appreciate if anyone could help me with this.

Thank you.

Can you provide the codes to replicate the issue?

Thank you for your reply. I figured out! It’s a syntax problem arising from different Dynare versions I guess. Thank you anyway!