Technical Q&As
General Questions
How are the historical term premiums of long-term interest rates constructed in the FRB/US model?
I have run a simulation under VAR expectations. Can I also run it under MC expectations?
EViews Package Questions
How do I set up a simulation in which one or more FRB/US equations are replaced or modified?
What can be done when a FRB/US simulation encounters a "solver stalled" error?
General Questions
Does FRB/US contain a variable for the equilibrium level of the real federal funds rate? What is RSTAR?
In FRB/US, the equilibrium value of the real federal funds rate is implicit in the model's structure and depends on various factors that shift the position of its long-run IS curve, such as the stance of fiscal policy. The equilibrium rate does not appear as an explicit variable. The FRB/US variable RSTAR should not be confused with the equilibrium real interest rate. RSTAR, which is the policymakers' estimate of the equilibrium real rate, is included in FRB/US to permit the intercept of various monetary policy reaction functions to adapt in simulations to persistent movements in the simulated level of the implicit equilibrium rate.
How are the historical term premiums of long-term interest rates constructed in the FRB/US model?
The interest rate term premiums are calculated as residuals in accordance with the long-term interest rate equations of the model. For instance, for the 10-year Treasury yield (RG10), the term premium stored in the data set is the difference between the yield to maturity and a weighted average of the short-term interest rate over a 10-year period as predicted by the model's VAR-based equation of that variable (ZRFF10). This difference, RG10-ZRFF10, is what enters the historical data set as the term premium. One should not necessarily expect this mechanical procedure to mimic closely any other publicly available estimate of the term premium. At the same time, to the extent that the forecasts of future short-term rates are similar, the estimates of the term premium will be as well.
The trajectories of some variables in the longbase database contain wobbles ten years in the future. What causes this?
The construction of future part of the database involves two mechanical procedures, one for the first ten years (which includes aligning the projections of five key macro variables with their SEP projections) and one for the remaining years. The "data" created by the two procedures satisfy all identities in FRB/US but differ in the extent to which they adhere to the model's other equations. As a result, the transition from the first to second steps may not be smooth for some variables. Because the programs in the FRB/US Package focus on simulations that are expressed as deviations from baseline, any wobbles in the baseline are relatively unimportant.
How are the historical and future values of the FRB/US expectations variables in the longbase database calculated?
For each expectations variable, historical observations equal the fitted values of its VAR expectations equation. Because each VAR equation is a function of only contemporaneous and lagged observables, these fitted values are easily calculated one equation at a time.
Future observations for expectations that are weighted averages of future federal funds rates (ZRFF5, ZRFF10, ZRFF30) and future PCE inflation (ZPI5, ZPI10, ZPIC30) are constructed to satisfy their FRB/US MCE equations, given the SEP projections for the federal funds rate and PCE inflation as extended in the longbase database to converge gradually to the corresponding long-run SEP values. Future observations of all other expectations variables satisfy their VAR expectations equations.
In a FRB/US simulation with model-consistent expectations, what exactly does the term "model-consistent" (MC) mean?
The solution algorithms used in EViews for FRB/US simulations with model-consistent (MC) expectations impose the condition that each MC expectation must equal the future simulated value of the variable or discounted sum of variables that it is associated with, aside from a possible baseline tracking add factor. In this expectations framework, which is frequently termed perfect foresight, the values of future shocks are known in advance, unless a rolling simulation approach is used. For an expectations variable whose tracking add factor is zero, both its baseline and simulated values are MC. If the add factor is not zero, then the baseline values are not MC and the simulated values are MC only when measured as deviations from baseline. In the longbase database, baseline values are MC (and tracking add factors are zero) only for those expectations that are weighted averages of future federal funds rates (ZRFF5, ZRFF10, ZRFF30) and future PCE inflation (ZPI5, ZPI10, ZPIC30) and, for these expectations, only in the future part of the database.
When the baseline value of the funds rate is at the zero lower bound (ZLB), how should the add factors on the equations in the FRB/US monetary policy sector be set in a simulation whose effects, in the absence of the ZLB, tend to raise the federal funds rate?
The answer to this question requires knowledge of or an assumption about the policy rule that would have determined the federal funds rate in the absence of the ZLB. If this rule is one of the ones available in FRB/US without any adjustments, then all add factors in the sequence of equations that determines the federal funds rate should be set to zero after the calculation of any tracking add factors. This sequence of equations includes the equation for the policy rule (such as RFFINTAY) along with the equations for RFFRULE and RFF. A slightly more complex case arises when the unconstrained federal funds rate is assumed to be determined by a FRB/US rule with add-factor adjustments. In this situation, these add factors need to be imposed on the equation for the policy rule, while the equations for RFFRULE and RFF should remain unadjusted.
What is assumed about the cross and serial correlation of the shocks used in the stochastic simulation program?
In most FRB/US equations, errors are serially uncorrelated; an exception is a few financial equations (REQP, RG5P, RG10P, RG30P, RBBBP) whose error are AR(1) processes. The equation-by-equation approach to the estimation of most equations makes no specific assumption about error cross-correlation. The bootstrap procedure used in stochsims to draw stochastic shocks from the set of historical residuals of the model's stochastic equations is consistent with these estimation assumptions. This procedure, which is based on grouping together the shocks of all equations for each of a random sequence of historical quarters, preserves whatever cross-correlation is present in the historical residuals. The design of the procedure assumes the absence of any series correlation in the equation residuals or, in the handful of equations with AR(1) errors, in the innovations to the AR(1) processes.
The stochastic simulation program that is part of the FRB/US package assumes the VAR form of expectations. Is it possible to run stochastic simulations of FRB/US under MC expectations?
Stochastic MCE simulations of FRB/US can be run with the algorithms provided in the FRB/US Model Package, but they are computationally very costly for two reasons. One is the cost that the MC assumption adds to a simple simulation. And, if the stochastic MCE simulation involves imposing unexpected shocks over m periods, each stochastic MCE replication requires a rolling sequence of m simulations rather than the single simulation that is needed in the VAR case.
I have run a simulation under VAR expectations. Can I also run it under MC expectations?
In order to lay out the issues that arise in converting a simulation from VAR to MC expectations, consider an experiment in which the simulated values of some or all of the endogenous variables in FRB/US are needed from quarter 1 to quarter m. Under VAR expectations, this requires an m-quarter simulation. Simply rerunning this m-quarter experiment under MC expectations is not sensible, given that the MC algorithms used to simulate FRB/US in EViews are extended path methods and, as such, require simulation periods that extend well beyond the m quarters of interest. The standard criteria for determining the total length, m+n, of an MC simulation is that extending the length by an additional period has negligible effects on the relevant solution values through quarter m. For FRB/US MCE simulations, the value of n that satisfies this criteria is likely to be at least 150 quarters, subject to the requirement that both fiscal and monetary policy be set in the extension period in a manner consistent with the movement of the extended FRB/US solution toward a steady-state equilibrium. This requirement rules out monetary policies that permanently hold the (nominal or real) level of the federal funds rate fixed and excludes the fiscal policy option in which the personal income tax rate is permanently exogenous.
EViews Package Questions
When I choose the VAR expectations option in pings.prg, the program stops executing with the error message "the mce_vars group specification none is incorrect..."
The version of pings.prg in the releases of the FRB/US model package dated January 31, 2017 and February 10, 2017 does not execute properly when the VAR expectations option (%mcegroup = "none") is chosen. This problem will be fixed in the next regular release of the package. In the meantime, users can modify the program as follows to correct the faulty code.
- Change all instances of "%mcevars" to "%mcegroup".
- Replace the single line of code appearing immediately after "Load equations and coefficients" with the following block of code.
if %mcegroup = "none" then
%exp = "var"
%mcegroup = "zpic58"
else
%exp = "mc"
endif
read_xml_model(path=%model_path,mce_vars=%mcegroup,mod_f=%mcemod) - Replace the second line of code in subroutine simit with the following.
if %exp = "var" then
My FRB/US simulation program stops executing with the error message "LD.FRBUS_EQS is not defined or is an illegal command ..." What does this mean?
This (or a similar) error message occurs when the simulation program cannot find one of the add-in commands used to load FRB/US equations and coefficients. Either the FRB/US add-in commands have not been properly installed (see the "ADDINS" part of section III of README.TXT) or the program is not being run from the correct EViews default directory (see section II.3 of README.TXT).
How do I set up a simulation in which one or more FRB/US equations are replaced or modified?
There are two approaches to making changes to FRB/US equations. In one approach, changes are made after the standard add-ins (ld_frbus_eqs and ld_frbus_cfs, or mce_load_frbus) have been used to load the model into the workfile. This approach applies to modifications to an equation's coefficient values, which can be entered directly in the appropriate coefficient vector after it has been loaded (for example, y_rfftay(3) = 2). This approach can also be used for changes to the functional forms of equations when running EViews 8, which has the built-in replace, append, merge, and drop procedures for working with the equations of a model.
In the second approach to making changes to FRB/US equations, the add-in commands supplied in the FRB/US Model Package are used to load only those equations that do not need modifications. Then, additional EViews commands are used to "append" or "merge" the new specifications of the remaining equations. This approach must be used when making changes to functional forms in EViews 7 and may be optionally used for this purpose in EViews 8. For a simulation under VAR expectations, the ld_some_eqs add-in loads a subset of FRB/US equations. With this add-in, only those equations whose names match or do not match the names in the string assigned to the eqnames keyword are loaded. If the first "word" in the string is "allbut", then all equations but those listed are loaded. Otherwise, only those equations listed are loaded.
%eqs = "allbut rffe"
ld_some_eqs(modelname=%varmod,modelpath=%varpath,eqnames=%eqs)
{%varmod}.append rffe = <an alternative text specification
In this example, all equations but the one for RFFE are loaded and an alternative specification for RFFE is appended. (Because of the ease of changing coefficients after they have been loaded, there is no need to have an add-in that loads a subset of coefficients.)
In the case of a simulation with model-consistent expectations, the second approach to changing functional forms uses the optional "allbut" and "only" keywords of the mce_load_frbus add-in to load a subset of equations. The following example, which is taken from example4.prg, loads all but the RFFGEN equation.
%eqs = "rffgen"
call mce_load_frbus("mce_vars=%zvars,mod_b=%varmod,path_b=%varpath,
mod_f=%mcemod,path_f=%mcepath,allbut=%eqs")
{%varmod}.append rffgen = <an alternative text specification>
How do I set up a simulation of a modified version of FRB/US with model-consistent expectations (MCE) in which one of the modifications adds another MCE variable?
See example4.prg for a concrete demonstration of how to add an MCE variable to FRB/US. The code in the example is guided by the following aspects of the design of the MCE algorithms supplied in the FRB/US Model Package. These algorithms require two models, one containing the full set of FRB/US equations in which all expectations are coded using backward-looking identities, and one with a partial set of equations consisting of the forward-looking MCE identities and an associated set of identities that defines expectations errors as the difference between the forward-and backward-looking solutions. In this framework, each MCE variable is associated with three equations and three variable names. The name of an expectations variable when it appears as the dependent variable in its backward-looking equation in the first model (and when it appears as an explanatory variable in other equations in that model) should start with the letter "z". Its name when it appears as the dependent variable in its forward-looking equation should replace the initial "z" with a "w". And the name of its expectations error should be formed by appending an "e" to the "z" form of its name.
In addition to the three equations that must be added for each new expectations variable, baseline data must also be created, and the string that is assigned to the keyword mce_vars when executing the mce_run add-in must be augmented to include the name of each new expectations variable.
Why does the example program that characterizes monetary policy as an optimal-control problem (ocpolicy.prg) use a penalty function to impose the zero lower bound (ZLB) on the federal funds rate?
Inclusion of the ZLB constraint directly in the interest rate equation leads to severe solution problems with the OC procedure when the ZLB is binding, because the algebraic code that determines the search direction and step length for the policy instrument does not take account of the ZLB. The OC program gets around this problem in a simple way that adds a nonlinear ZLB penalty variable to FRB/US and includes the square of this variable in the overall loss function. The advantage of this approach is that it keeps the analysis entirely in EViews. A disadvantage is that it imposes the ZLB only approximately, but tests have shown that the approximation error is small. An alternative approach, which imposes the ZLB exactly and is available as an option in the FRB/US Package, organizes the OC solution as an inequality-constrained quadratic programming problem to be solved with a sequence of calls from EViews to either Matlab or R. For more information on this, see the "MCE Solve Users Guide".
What can be done when a FRB/US simulation encounters a "solver stalled" error?
A "solver stalled" error may occur when the EViews model solver gets stuck at a kink in one of the handful of inequality constraints coded into FRB/US equations. Such convergence problems are rare and can usually be resolved by instructing the EViews solver to use its Newton algorithm rather than the quasi-Newton Broyden algorithm typically chosen for FRB/US simulations. Although both the Newton and quasi-Newton methods may fail when functions are not continuously differentiable—which is the case with those FRB/US equations that contain constraints—the simultaneous failure of both algorithms to solve a specific FRB/US simulation is exceedingly rare. In this unlikely event, switching to the Gauss-Seidel algorithm is recommended.