Welfare comparison - replicating Born and Pfeifer (2018)

Hi all,

I am trying to compare environmental policy instruments in an NK model using the standard consumption-equivalent measure. I found the mod file for Born and Pfeifer (2018) and have been working to replicate it. I have attached my files below. I have two questions:

  1. I try to define four different policy scenarios (baseline, tax, intensity, cap) using if conditions throughout the mod file. However, the code as it is only performs estimation on the ‘tax’ scenario. How should I specify multiple policy regimes within a single mod file, and where are the estimation results for each regime reflected in the output?

  2. In BP (2018), natural output Y_nat and hours worked N_nat are explicitly defined. Therefore, ‘Recursive_natural_welfare_equivalent’ is specified as follows. It is consistent across policy regimes and the welfare differences are always calculated using reductions in the flex-price natural consumption. In my case, however, baseline consumption and labor are not separately defined. How would I reflect in the code that for each policy, (1-lamda_utility) should always be applied to the baseline consumption, rather than the ‘c’ that arises in each policy scenario?

[name=‘Natural Recursive Welfare’]

Thank you in advance.


cn_test_one_sided.xlsx (15.4 KB) cn_welfare.mod (12.9 KB) get_consumption_equivalent_conditional_welfare.m (2.4 KB) get_consumption_equivalent_unconditional_welfare.m (2.2 KB)

I am not sure I fully understand the question.
Part 2 is straightforward: in your mod-file, you the baseline takes the place of the flex-price outcome. See also

Regarding Part 1: the macro language essentially allows you to combine several mod-files in one. You can use the savemacro= option to see the mod-file that results in this case. Because of this setup, you will always get the same structure of results, because you only change some equations and parameter-related statements in your file.

Dear Professor Pfeifer,

Thank you for your reply and sorry about the confusion! I hope I can clarify on my questions a bit:

Regarding Part 1:

My understanding of the BP (2018) code was that through the macro language of ‘@#if’ and such, it essentially performs estimation for each policy regime in one single mod file. Therefore I was expecting a separate set of output for ‘baseline,’ ‘tax,’ ‘intensity,’ and ‘cap,’ respectively. For example, I specified the estimated_parameters block as follows:

@#if tax
@#if intensity
@#if cap

and got the output:

I am not really sure how to interpret this in context of the @#if conditions. It seems like the @#if conditions were ignored and estimation was performed as if all policy regimes were present at the same time… (Some identification problems also arose that weren’t present when I estimated each policy in their independent mod file.)

Regarding Part 2:

The approach in SW (2007) makes sense to me, but I have some follow-up concerns about applying it here. The baseline here is not a flex-price allocation or anything, just a benchmark with no policy. Therefore the model equations between baseline and other policies are mostly the same. For example, the only difference between ‘baseline’ and ‘tax’ is that the price of emissions for firms pz changes from 0 to the tax rate taulz. From my understanding, implementing SW (2007) would require me to add an almost identical set of variables and equations for ‘baseline’ to the current mod file, and the number of relevant model variables would be twice the number of observables, since each model variable would have a baseline ‘twin’… I am not sure how estimation could still work then.

Hope this makes more sense. As always, thank you for your time!


  1. You are calling the file wrong, I guess. You have
@#ifndef baseline
    @#define baseline=1

@#ifndef tax
    @#define tax=1

@#ifndef intensity
    @#define intensity=1

@#ifndef cap
    @#define cap=1

So unless you use the -D option to pass flags to your model, all dummies are set to 1, instead of just one of them.

  1. Indeed, that model version will be almost twice as big. But usually there is no way around this. But estimation should still be feasible. Linearized models can handle hundreds of equations.

I wrote out the mod file as per part 2, and estimation works just fine now. However, I get the following errors when I try to calculate lamda_utility using the solver:

Error using stoch_simul
Too many input arguments.
Error in get_consumption_equivalent_unconditional_welfare (line 32)
[info, oo_, options_] = stoch_simul(M_, options_, oo_, var_list_); %get decision rules and moments
Error in csolve (line 60)
Error in cn_welfare_bl_sep (line 799)
Error in dynare (line 235)
evalin(‘base’,fname) ;

I tried to search up on what these errors mean but it’s still not very clear to me. I have attached the updated mod file and m file. Could you please take another look and suggest on what I should try next? Thank you!

cn_welfare_bl_sep.mod (15.2 KB) get_consumption_equivalent_conditional_welfare.m (2.4 KB)

Are you using Dynare 4.6.1?

I’m using Dynare version 4.5.7.

Then that is the explanation. My example codes are compatible with Dynare 4.6. The 4.5 compatible ones are in the 4.5 branch at https://github.com/JohannesPfeifer/DSGE_mod/tree/4.5/Born_Pfeifer_2018/Welfare

1 Like

Dear Prof Pfeifer,
I have one question regarding this replicating code (Born and Pfeifer, 2018): can you please explain why in computing the consumption equivalent you use the unconditional welfare cost/gain value as an argument in the conditional welfare cost solving ? as in the following code lines:

For any solver, you need to pass a starting value. For the first call, I pass the value of 0, because I don’t know any better value. For the second one, instead of 0 I use the previously computed value from the unconditional measure, which worked better in our application. But you could also use 0 again.

1 Like