Number of periods until terminal conditions for Stacked solution method

[PatMcFarlane]

Is there a way to set the number of periods until the terminal condition is assumed to be met when using the stacked time solution method? If not, how is that number of periods currently set by IRIS?

I have a model converges to 99% of its steady-state within a short number of periods, but then takes a long-time to converge the rest of the way and I'm finding that the stacked time solution method is extremely slow...in fact I haven't been able to get it to solve after hours of computing time. I'm wondering if this is because the number of periods until the terminal condition is derived from the first-order solution method.

[jaromir-benes]

Hi

First of all, IRIS uses the first-order approximate solution to compute the terminal condition. Hence the terminal condition is something fixed. Let's say you use a simulate command like this one

s = simulate(m, d, 1:30, 'Method=', 'Stacked', ...)

The 30 periods are simulated using the nonlinear stacked-time method. Any leads (i.e. t+1, t+2, etc.) pointing behind the last period (here, 30) are then calculated using the first-order approximate solution, in other words, running a linearized simulation starting in period 31 and ending wherever it needs to end, using the initial condition (t-1, t-2, etc... that means periods 30, 29, etc.) from the nonlinear iteration. Things become a little bit more complicated when there are unanticipated shocks down the way, but we don't need to cover that here....

Second, because everything is implemented as Matlab functions, the nonlinear solution methods are indeed slow, and the Stacked method is really convenient only for smaller models. Sorry about that....

If you have just a smaller number of critical nonlinearities (being happy to have the other equations solved first-order approximately), I would recommend using the Selective method (let me know if you're not familiar with it). Also, if you have a fully backward looking model, there is the Period method, which calculates the simulation period by period.

Best Jaromi

On Mon, Apr 27, 2020 at 10:14 PM Pat-Mac notifications@github.com wrote:

Is there a way to set the number of periods until the terminal condition is assumed to be met when using the stacked time solution method? If not, how is that number of periods currently set by IRIS?

I have a model converges to 99% of its steady-state within a short number of periods, but then takes a long-time to converge the rest of the way and I'm finding that the stacked time solution method is extremely slow...in fact I haven't been able to get it to solve after hours of computing time. I'm wondering if this is because the number of periods until the terminal condition is derived from the first-order solution method.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKT4LSTU6P7EYGEXZSTROXRSJANCNFSM4MSHLD7Q .

[PatMcFarlane]

Hi Jaromir,

Thanks for the prompt reply. I am familiar with the Selective method. I use it regularly for imposing a zero lower bound in my model. Unfortunately I have on the order of 10 equations for which I am interested in their nonlinear behaviour. I'll try using the selective method and see how that goes. Otherwise, I'll just have to wait it out.

I'm curious about why the Matlab routines take so long to run. I have a colleague that uses Portable Troll for solving DSGE models and he reports that the stacked time algorithms in that software are very fast (e.g., minutes), even with much larger models than the one I'm using. I wonder if a MEX implementation of the IRIS stacked time simulation method would make it much faster.

Thanks again,

Patrick

[jaromir-benes]

Hi Patrick

If it's 10 nonlinear equations, the Selective should be able to handle them alright (we use that method for much larger numbers of nonlinearities). Another trick up my sleeve is setting LastJacobUpdate in the Solver= options. This setting controls the last iteration in which the Jacobian is to be actually updated -- with the Jacobian being, of coure, by far the costliest thing that's going on during the iterations. By default, it is, obviously, Inf for the Stacked method (meaning the Jacobian is recalculated in all iterations). Sometimes, it's surprisingly robust to simply start reusing a Jacobian from some N-th iteration for the remaining iterations (N+1-th, N+2-th, etc. until the end). The syntax would be e.g. simulate(m, d, range, ..., 'Solver=', {'IRIS-Newton', 'LastJacobUpdate=', 10});

And yes, Troll is insanely fast -- even in comparison wtih other modeling software packages. Always blows my mind... (too bad the Troll language itself is such a mess:)). And yes, it equally blows my mind how surprisingly slow some tasks run in Matlab (to be fair though, they've been doing a great job accelerating the JITC and the execution engine in general).

Please feel free to upload your files or email them to me unless there's confidentiality issues. I would have a look...

Best Jaromir

On Tue, Apr 28, 2020 at 1:03 AM Pat-Mac notifications@github.com wrote:

Hi Jaromir,

Thanks for the prompt reply. I am familiar with the Selective method. I use it regularly for imposing a zero lower bound in my model. Unfortunately I have on the order of 10 equations for which I am interested in their nonlinear behaviour. I'll try using the selective method and see how that goes. Otherwise, I'll just have to wait it out.

I'm curious about why the Matlab routines take so long to run. I have a colleague that uses Portable Troll for solving DSGE models and he reports that the stacked time algorithms in that software are very fast (e.g., minutes), even with much larger models than the one I'm using. I wonder if a MEX implementation of the IRIS stacked time simulation method would make it much faster.

Thanks again,

Patrick

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246#issuecomment-620280327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKWOCRT53BSBCRLUDVTROYFLZANCNFSM4MSHLD7Q .

[PatMcFarlane]

Thank you, I will try that modification. What are your thoughts on the different solver options? Should 'IRIS-Newton' generally be expected to be faster than 'IRIS-qnsd' or fsolve? Unfortunately, confidentiality is definitely an issue so I won't be able to upload the files...I work for the Government of Canada and the modelling I am doing is supporting policy decisions that are actively under consideration.

[PatMcFarlane]

I ran this overnight last night and it reached the maximum number of iterations without converging so I will probably need to increase that maximum as well.

[jaromir-benes]

Hi Patrick

Yes, IRIS-Newton should be faster (but it won't make a great deal of difference in your case), and this should be the default option of dynamic simulations (where the system is usually exactly determined -- unlike the steady state calculations for models with nonzero growth). Also make sure you always run the latest IRIS - this is actually one of the areas we continuously develop these days (although the improvements are just marginal most of the time).

Definitely go and try the Selected method. How big's the model? More than a 1,000 equations? Forward looking? Mostly close-to-(log)linear? How many blocks is the model split into? Can you at least post the screenshot showing the beginning of the iterative process (with the header and a few initial iterations...)?

If this is a longer term priority project, one option might be setting up a formal contract with OGResearch (where I'm partner) and sign an NDA. That way, we could help you more directly...

Jaromir

On Tue, Apr 28, 2020 at 3:07 PM Pat-Mac notifications@github.com wrote:

I ran this overnight last night and it reached the maximum number of iterations without converging so I will probably need to increase that maximum as well.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246#issuecomment-620594677, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKQXZULAVLMDPLTKLFDRO3IHZANCNFSM4MSHLD7Q .

[PatMcFarlane]

Hi Jaromir,

The model has about 650 equations split into about 390 blocks. I should note though that we had trouble getting the steady-state to solve so we coded a quasi-analytical solution for it and then fed that in as the steady-state, using the chkstate command to verify the accuracy. Most of the equations are approximately log-linear.

Screenshot of the first few iterations is included below

Thank you for the pointer about contracting OGResearch. I'll make sure my superiors are aware of that option. It's probably not something we will have time to set up right now but it could be a valuable resource in the future. If there are any training opportunities, there might be an interest in taking advantage of those as well. Not sure if that is something you can set up virtually? ...it will probably be a long while before we could participate in any in person training.

[PatMcFarlane]

Sorry I forgot to add that yes the model is forward looking.

[jaromir-benes]

Hi Patrick

Could you please at least post a vector of the steady state levels for all variables (you don't have to include the variable names, just the numbers:)) - for me to see if ill-conditioning might be an issue here. Also

• how much forward looking is the model? E.g. could you post also the vector of unstable eigenvalues, i.e. get(m, 'unstableRoots')? And what version of Iris do you use?

Regarding the training opportunities - absolutely, we do a lot of virtual seminars, indeed (e.g. one of the big projects we're working on now is reimplementing a number of models to IRIS for the ECB, and with the coronavirus travel bans, webex seminars are now the only option to proceed...)

Best Jaromir

On Tue, Apr 28, 2020 at 5:12 PM Pat-Mac notifications@github.com wrote:

Hi Jaromir,

The model has about 650 equations split into about 390 blocks. I should note though that we had trouble getting the steady-state to solve so we coded a quasi-analytical solution for it and then fed that in as the steady-state, using the chkstate command to verify the accuracy. Most of the equations are approximately log-linear.

Screenshot of the first few iterations is included below

[image: image] https://user-images.githubusercontent.com/64423829/80503577-0e5b5400-8940-11ea-8a2a-fb78a2fa50f7.png

Thank you for the pointer about contracting OGResearch. I'll make sure my superiors are aware of that option. It's probably not something we will have time to set up right now but it could be a valuable resource in the future. If there are any training opportunities, there might be an interest in taking advantage of those as well. Not sure if that is something you can set up virtually? ...it will probably be a long while before we could participate in any in person training.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246#issuecomment-620668533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKXSBU3TXUPUZUWIPODRO3W6XANCNFSM4MSHLD7Q .

[PatMcFarlane]

Steady-state values (Column A) and unstable roots (Column C) are attached. The string of zeros at the bottom of the steady-states are steady-states values for mean zero AR1 shock processes. The last two numbers are the steady-state values of some test variables we use to ensure there are no leakages or double counting in the model. One is the difference in GDP measured by two different approaches (value-added vs final expenditure). The second is the residual on a household budget constraint. When everything is working correctly they should be close to zero.

Steady_State Values.xlsx

[jaromir-benes]

I see some steady state levels around +/-20,+/-30, +/-80, etc... while other numbers are around 0, 1, etc... Are the former ones 100*log of some variables, while the others are plain levels of something? Can you give an example of the structure of say two or three "typical" equations (feel free to obfuscate the names of variables... like Tom and Ray in CarTalk, if you happen to know the show:)))

On Tue, Apr 28, 2020 at 6:01 PM Pat-Mac notifications@github.com wrote:

Steady-state values (Column A) and unstable roots (Column C) are attached. The string of zeros at the bottom of the steady-states are steady-states values for mean zero AR1 shock processes. The last two numbers are the steady-state values of some test variables we use to ensure there are no leakages or double counting in the model. One is the difference in GDP measured by two different approaches (value-added vs final expenditure). The second is the residual on a household budget constraint. When everything is working correctly they should be close to zero.

Steady_State Values.xlsx https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/files/4547025/Steady_State.Values.xlsx

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246#issuecomment-620698060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKW5UU6RBYTGMYSV7Q3RO34UZANCNFSM4MSHLD7Q .

[PatMcFarlane]

Yes the larger values are of the 100log(x) type. There are also a few that are values of "endogenous" parameters (i.e., parameters that we sometimes shock). For example, ETA=rho PARAM_ETA _SS+ E_ETA.

Some typical equations are:

First-order condition for firms' optimal employment decision (CES production function with an adjustment cost on labour):

(1-T) W = PSI PARAM_ALPHA (PROD/(L))^(1+PARAM_ETA) A G_K{-1}^PARAM_ETA_GK)^(-PARAM_ETA)-PSI PARAM_ZETA_L (L/L{-1} - 1) PROD/L{-1}+PARAM_BETAELAMBDA{1}/LAMBDA PSI{1} PARAM_ZETA_L (L{1}/L - 1) (L{1}/L^2) PROD{1}

First-order conditions for capital and capital utilization are of a similar form.

Monetary policy rule:

INOM =# max(PARAM_THETA_R INOM{-1} + (1-PARAM_THETA_R) (&INOM+PARAM_THETA_PI (PHI_C - &PHI_C) + PARAM_THETA_T1 (YGAP))+ZESP_INOM,0)

Euler Equation:

P_C (1+TC) LAMBDA = (1+ESP_UTIL) (CPR - PARAM_HAB_C CPR{-1})^(-PARAM_SIGMAE);

Wholesaler optimal price setting equation (Rotemberg style price rigidity):

(1-TPROFIT_RENT) (-ETA_D (1-P_IG)+1-PARAM_ZETA_P (PHI_C-1) PHI_C) + LAMBDA{1}/LAMBDA PARAM_BETAE (1-TPROFIT_RENT{1}) (Y{1}/Y PARAM_ZETA_P (PHI_C{1}-1) PHI_C{1})=0

[jaromir-benes]

Hi Patrick - a numerically much sounder approach usually is to simply have X instead of x=100*log(X) in the model, putting X on the list of !log-variables. I would definitely recommend rewriting the model this way. This also goes, e.g., for the interest rates, growth rates, inflation rates etc. Introducing gross rates of interest, not multiplied by 100 (e.g. 1.05 insteady of 5), redefining gaps into gross rates of gaps (i.e. YGAP = Y/YPOT) etc. usually improves numerical robustness in these kinds of models...

Best Jaromir

On Tue, Apr 28, 2020 at 7:28 PM Pat-Mac notifications@github.com wrote:

Yes the larger values are of the 100log(x) type. There are also a few that are values of "endogenous" parameters (i.e., parameters that we sometimes shock). For example, ETA=rho PARAM_ETA _SS+ E_ETA.

Some typical equations are:

First-order condition for firms' optimal employment decision (CES production function with an adjustment cost on labour):

(1-T) W = PSI PARAM_ALPHA (PROD/(L))^(1+PARAM_ETA) A G_K{-1}^PARAM_ETA_GK)^(-PARAM_ETA)-PSI PARAM_ZETA_L (L/L{-1} - 1) PROD/L{-1}+PARAM_BETAELAMBDA{1}/LAMBDA PSI{1} PARAM_ZETA_L (L{1}/L

• 1) (L{1}/L^2) PROD{1}

First-order conditions for capital and capital utilization are of a similar form.

Monetary policy rule:

INOM =# max(PARAM_THETA_R INOM{-1} + (1-PARAM_THETA_R) (&INOM+PARAM_THETA_PI (PHI_C - &PHI_C) + PARAM_THETA_T1 (YGAP))+ZESP_INOM,0)

Euler Equation:

P_C (1+TC) LAMBDA = (1+ESP_UTIL) (CPR - PARAM_HAB_C CPR{-1})^(-PARAM_SIGMAE);

Wholesaler optimal price setting equation (Rotemberg style price rigidity):

(1-TPROFIT_RENT) (-ETA_D (1-P_IG)+1-PARAM_ZETA_P (PHI_C-1) PHI_C)

• LAMBDA{1}/LAMBDA PARAM_BETAE (1-TPROFIT_RENT{1}) (Y{1}/Y PARAM_ZETA_P (PHI_C{1}-1) PHI_C{1})=0

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/IRIS-Solutions-Team/IRIS-Toolbox/issues/246#issuecomment-620747495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCVKKXYXALUI6W7SGRVG73RO4G3JANCNFSM4MSHLD7Q .

[PatMcFarlane]

Hi Jaromir,

Thank you for that advice. We often write variables that way out of convenience since we are often asked to produce results under tight time constraints and it helps to have the variables come out of the model in the form that our superiors want to see them (as opposed to having to do some processing of the simulation results). Do you have any suggestions on a fast way to do that processing? I guess one could write a script that would do it and just run that script after each simulation.

I was able to get the equation-selective method working just fine...turns out that the non-linearities don't really matter that much. I have another question now...but I'll start a new thread for it.

-Patrick

[PatMcFarlane]

OGResearch

Hi Jaromir,

The government institution I work for is interested in perhaps setting up a seminar for us to learn about some specific IRIS features. What's the best way to go about that? Can I email you somehow?

Thanks,

Patrick

[jaromir-benes]

Hi Patrick - please email me at jaromir dot benes at ogresearch dot com. J