Thank you for the reply! I think I have worked around this issue.
Basically, I assign: CESOEoutputs = oo_
such that when I run RamSOE code and clear M_ oo_ options, CESOEoutputs will still be maintained in the workspace.

But there exists one new error, which seems to less apppear in the forum.

Index in position 1 exceeds array bounds.
Error in evaluate_planner_objective (line 47)
Gy = dr.ghx(nstatic+(1:nspred),:);
Error in RamSOE.driver (line 692)
oo_.planner_objective_value = evaluate_planner_objective(M_, options_, oo_);
Error in dynare (line 293)
evalin('base',[fname '.driver']) ;
Error in RamSOE (line 80)
dynare RamSOE.mod noclearall

Index 1 here represents Welf. If I erase this variable and relevant equations, steady states, then the code performs well, that is, it can do optimal problem, but fails to calculate welfares.

I do not answer the question. I’m a beginner as well
Allow me to leave some messages here. Hope they are helpful.

First, this BK violation means there exists at least one error in your model.
One strategy is to go backward. Simplify your model until the new one can actually work.
However, as you said, if in Ramsey scenario, removing the equation of Welf_t = U_t+\beta Welf_{t+1}
(and its variable, steady state claims,) it will work.
So the current version of code has already been a Minimal Working Example (MWE)

They give me the impression that the Ramsey case does not couple with the welfare equation: Welf_t = U_t+\beta Welf_{t+1}??
But I really saw some optimal Ramsey papers contain it, at least when they apply Levin’s package.

I also notice a post below:

The author calculates the recursive conditional welfare only in the Taylor rule, while keeping it absent in the Ramsey policy.

@HelloDynare is correct. I missed that part. You must not include the welfare definition in the model when using Ramsey as this will create a singularity. The reason is that the planner objective will use that equation as well, so you will have it twice.

I briefly construct CESOE for Competitive Equilibrium and RamSOE for optimal Ramsey policy, and intend to compare unconditional and conditional welfares between them. Please use updated codes attached here. CESOE.m (3.2 KB) CESOE.mod (6.1 KB) RamSOE.m (3.1 KB) RamSOE.mod (5.2 KB) F_QYH.m (1.1 KB) find_QYH.m (888 Bytes) table_vol_welf.m (591 Bytes)

I haven’t finished all parts, but results regarding welfare are clear.
The unconditional welfare of CESOE is roughly -164.9607
The conditional welfare of CESOE is around -165.0010
Approximated value of planner objective function (RamSOE)
- with initial Lagrange multipliers set to 0: -228.5360
- with initial Lagrange multipliers set to steady state: -228.5360
No matter -228 is conditional or unconditional, unfortunately, RamSOE is very likely to be beaten by CESOE!! Why?

Your reposting “oo_.planner_objective_value” link looks a little disappointing. We’ve realized the small problem regarding the final evaluation function, as in my reposting zolnier’s reply. But before that everything is well designed in Dynare. So our macro strategy is still following what Dynare reports us, and slightly modify the last step.

Let’s focus on UNCONDITIONAL welfare. Your codes suggest using Utility instead of Welfare to work around this issue We employ this idea. Here are latest version: CESOE.m (3.2 KB) CESOE.mod (6.2 KB) RamSOE.m (3.1 KB) RamSOE.mod (5.3 KB) table_vol_welf.m (588 Bytes)
in which I changed the parameters of Taylor rule, such that actually CESOE is a kind of OSR-SOE. Unconditional welfare of RamSOE now is around -163, much more approaching CESOE than in the previous post.

QUESTION:
compared with the previous post, we revised line 70-71 in CESOE.mod from

RHO_P = 1.5; % monetary policy response to inflation
RHO_Y = 0.5; % monetary policy response to outputs

BUT, the welfare are
old CESOE -164.9607
OSR CESOE -163.3676
RamSOE -163.7630
Ramsey welfare is less than OSR welfare!! WHY?

BTW, we have included a second instrument into RamSOE framework (not in the attachment here), the welfare is (far) larger than -163, very promising. So I believe these codes are robust, to some extent. The model is based on CEE2005 and SW2007.

order = 2 is still not supported in the latest 4.6.1 version for Ramsey. I tried it before.

And if my understanding is correct, the manual or you mentioned that order = 1 for Ramsey is not pure first order. It can conduct the mission of second order perturbation in terms of SGU and Kim and Kim.

evaluate_planner_objective: order>1 not yet supported

But except the last function, previous codes can be executed under the order = 2? I get it.

The result is improved, nevertheless does not reverse the rank:

You compute both Utility and Recursive_natural_welfare_equivalent via oo_.mean.

For CONDitional Welfare,

y_sim = simult_(M_,options_,initial_condition_states,oo_.dr,shock_matrix,options_.order); %simulate one period to get value
Recursive_natural_welfare_equivalent=y_sim(strmatch('Recursive_natural_welfare_equivalent',M_.endo_names,'exact'),2);
oo_.planner_objective_value = evaluate_planner_objective(M_,options_,oo_);
outvalue=(oo_.planner_objective_value(1)-Recursive_natural_welfare_equivalent)*100;

You compute the welfare of alternative policy and the benchmark via evaluate_planner_objective and simult_ respectively.

But MATLAB pops up that the former function does not support order = 2.
In the old post, you said:

I saw it is second order approximation. So what is "does not support order = 2" real meaning?

My question is: is oo_.planner_objective_value(1) accurate upto second order?
Moreover Can we approach the planner objective value via simult_ as well? such that we compute conditional welfare both of alternative policy and of the benchmark by the same method, just like what you do in the UNconditional welfare case.

If order = 1, the output of evaluate_planner_objective currently is not comparable with conditional welfare of non-Ramsey policies,
and when order = 2, this function is invalid, I got the same error as reported by @HelloDynare

evaluate_planner_objective: order>1 not yet supported,

Do you or Dynare team has any m-file / fractional codes such that we can continue some sort of comparison “manually”? Or do you have any reference / study material that I can follow up in a relatively easy way to code it by myself?

Otherwise, I worry I have to go back to the very early yet cumbersome math derivations developed by Benigno and Woodford (2005) or SGU(2004)…

BTW1, deterministic SS, stochastic SS, ergodic SS, zero shocks, etc. do you have any working sample visualizing these concepts? I think I know them, in an unclear way.

BTW2, I checked simult_, conditional on being steady state, it can produce exact the same value of conditional welfare of the benchmark, say, competitive equilibrium, via oo_.dr.ys(Welf_pos) + 0.5*oo_.dr.ghs2(oo_.dr.inv_order_var(Welf_pos))
Thank you sooo much!

@littlemacro@HelloDynare This is a tricky and complicated issue that has been on my to-do-list for quite some time. A couple of notes:

The Born_Pfeifer_2018/Welfare codes are not applicable for Ramsey. In the paper, you will not see Ramsey results. The reason is that the planner_objective-values that you get out of Dynare do not conform to what you should get for a meaningful comparison. Essentially, we had the same problem as you did. The reason is that some second order terms you require are not entering the planner objective.

While the planner objective itself is correctly expanded, some inner derivatives related to the private sector FOCs are set to 0. The problem is that Dynare as of version 4.6 computes

A second order approximation of the objective function, conditional on a first order approximation of the solution function

while you would like to have a second order approximation of the solution function as well.

I any case, using defining utility and then using that unconditionally, W_t=U_t/(1-\beta) should be unaffected by the issue at hand. Unfortunately, that does not work for conditional welfare as the trick relies on W_t and W_{t+1} being the same unconditionally.

The problems with Ramsey in your mod-file are:

You are using simulated instead of theoretical moments.

It is not clear that the Ramsey steady state is unique, i.e. you may approximate around a wrong point. Using RamSOE.mod (5.2 KB) yielded
-163.345 for Ramsey.

Very immature thought and tempt reply:
In your post

simult_ seems very powerful. Though we have no correct Welf term in .mod (dynare computes it wrongly), we definitely have the correct Utility sequence. I’m not sure whether we are/were able to pin down the correct Welf via:
manually inputing

Welf = Utility + BETA*Welf(1);

into simult_ ?? After all, it is very likely that all the rest variables are unaffected. The only minor modification is this recursive form.

However I guess it’s difficult, because simult_ needs arguments of M_, oo_, options_ (I learned this function today ), which contain erroneous Welf. We have to first remove the wrong one, then insert the recursive form. How to remove and insert??

For reversing the welfare rank of OSR-SOE and Ramsey-SOE:
I’m now doing my modification on OSR-SOE.mod instead of Ramsey-SOE.mod
( wrong direction? ) Because,

In @littlemacro CESOE or OSRSOE files (they only vary with Taylor params), the steady_state_model; session closes to RamSOE. But comparing with your Born_Pfeifer_2018/Welfare, they still involve rooms to improve.

You may have answered these doubts in your latest post. I’ll take a careful look in following days!

Dynare finds the result more quickly than a two-instrument version of RamseySOE, so we didn’t notice the uniqueness. However, in the two-instrument version, we indeed realized it, very sensitive to our initval guess. So here is my question:

Will CMAES be helpful in Ramsey problem?
(I plan to substitute CMAES for fminsearch function)

Besides, your reply gives me the impression that the upper bound of the welfare of OSR-SOE, by deliberately choosing Taylor parameters, can dominate the lower bound of the welfare of Ramsey-SOE, by arbitrarily guessing initial values. Is it true?

It’s not that Welfare is wrongly simulated. The problem is that when using Ramsey in Dynare, you cannot enter a recursive definition of welfare in the mod-file as it will create a singularity. That’s why there is a separate function to evaluate the planner objective. For that reason, simult_ will not be helpful unless you use it to integrate out future shocks using simulations. My hunch is that this will be infeasible.

CMAES will not help. It’s not about your optimizer in the steady state file converging to something only locally optimal. It’s about Dynare’s routines internally converging to a local optimum. As of right now, there is no way to change this other than trying different initial conditions. But even with a global optimizer, that would be someone should do to make sure results are not driven by initial conditions.

Yes, Taylor can dominate the lower bound of Ramsey results. One of the theoretical reasons can be that we do not check second order conditions. So you may end up approximating around a local minimum instead of a maximum. But there are no general results available for this. If you have multiplicity, quite often anything goes.