Working on an infinite horizon model and I realized that it would be nice to have a command to calibrate the model parameters
I would like to add the calibration targets to the general equilibrium conditions (for simplicity and also because it is faster to do GE and calibration all in once rather than nested). Among the calibration targets I have the transition rate b/w occupations, which is caliculated as follows:
The code shown above calculates the transition from entrepreneur to worker, given by E_to_W (the mass of agents moving from entre to worker) divided by the mass of entrepreneurs.
Is it possible to incoporate tran_E_to_W as a target in the GE conditions using the toolkit as it is now? Or do I have to wait for the calibration command?
Actually because this is just ratio of means you could already do it in a GeneralEqmEqn.
That said, just pushed two features that will make this much easier for all sorts of moments.
First is āintermediateEqnsā. These just allow you to take some of the āAggVarsā and tranform them before you put them into GeneralEqmEqns. As an example, in a closed-economy model with government debt you have K=A-GDebt, where A is total assets (which is a FnsToEvaluate summed over households, so an AggVar) and GDebt is a parameter. You have the standard r=alpha*(K^(alpha-1))*(L^(1-alpha)) as a general eqm condition,
(r equals the Marginal Product of Captial), and K goes into this. You used to have to just substitute K=A-GDebt into the GeneralEqmEqn, which worked but got a bit messy. Now you can set up an intermediateEqn to evaluate K=A-Gdebt, and then pass K into the GeneralEqmEqn. This doesnāt really allow you to solve anything you couldnāt before, but it does make models much easier to write out and is easier to avoid making mistakes.
The other is āCustomModelStatsā, this allows you to calculate any kind of crazy model statistic that will then be passed into GeneralEqmEqns. I do an example where the CustomModelStat is the variance of earnings, and the GeneralEqmEqn is to get this to hit a target, and this is done by choosing ārhoā (the autocorrelation of idiosyncratic shocks) as a general eqm price param. [In Aiyagari model.]
Both intermediateEqns and CustomModelStats should work for InfHorz and FHorz stationary general eqm, including with PTypes.
Anyone who wants, email me and I will send code for Aiyagari model that demos a bunch of this. Proper documentation probably wonāt be released for a month or three. But feel free to ask a question.
Basic setup:
when you set up an intermediateEqn can take AggVars and Parameters as inputs, outputs can go into GeneralEqmEqns
when setting up CustomModelStats, the inputs are hardcoded (covers everything you might want), and then you create a structure as output, and the field names of this structure can then be passed as inputs into GeneralEqmEqns
[CustomModelStats does not yet work with PType, but hopefully that should change in later this month.]
Nope. heteroagentoptions.CustomModelStats is where you put it. Has to be a function that takes a fixed set of inputs (that depends on InfHorz or FHorz, and on if using PType), has to output a structure the field names of which are the custom stats you want to be able to use in the GeneralEqmEqns.
I think you are wrong. In the file HeteroAgentStationaryEqm_Case1_PType_subfn.m I see:
%% Custom Model Stats
if heteroagentoptions.useCustomModelStats==1
error('CustomModelStats not yet implemented for use with permanent types in InfHorz')
% CustomStats=heteroagentoptions.CustomModelStats(V,Policy,StationaryDist,Parameters,FnsToEvaluate,n_d,n_a,n_z,d_grid,a_grid,z_gridvals,pi_z,heteroagentoptions,vfoptions,simoptions);
% % Note: anything else you want, just 'hide' it in heteroagentoptions
% customstatnames=fieldnames(CustomStats);
% for pp=1:length(customstatnames)
% Parameters.(customstatnames{pp})=CustomStats.(customstatnames{pp});
% end
end
The implementation I made for FHorz handles both FHorz and InfHorz cases (since models like OLGModel14 use both FHorz and InfHorz in its household and firm PTypes, respectively). If that PR goes well, it will be trivial to port the code to the InfHorz-only case.
CutsomModelStats() needs to take different inputs in the different situations, InfHorz vs FHorz, and PTypes. Point is to give the user ability to do āany kind of crazy model statisticā using CustomModelStats() so they need āall possible inputs of interestā so they can do anything with the model that can possibly be done with model.
I have implemented CustomModelStats() in InfHorz, but havenāt yet adapted it to PTypes where it will need some additional inputs like N_i/Names_i/etc.
Iām taking the approach of implementing the FHorz version, and creating PType-based CustomModelStats (so one version for households one version for firms). So, like return functions, there is one function per PType.
I did see the pattern of Lifecycle_FHorz vs Lifecycle_FHorz_PType (with Names_i in the latter).
Iām still testing whether Iām barking up the right tree with respect to how I want to use the CustomModelStats function.
As I donāt have a concept how I would want to use all PTypes at the same time, Iāll defer trying to make a pan-PType version until then.
I can see that I got the ordering confused. I implemented heteroagentoptions.CustomModelStats.household when I should have implemented heteroagentoptions.household.CustomModelStats. Iāll rearrange my logic and see whatās left over after that.
Obviouslyheteroagentoptions.CustomModelStats by itself (no firms, no households) should do the full PType thing if there are PTypes. Again, I donāt know if I will get there because Iām not sure thatās what I need. But I am sure that I will hit some interesting corners when it comes to supporting the FHorz and InfHorz cases that are naturally mixed in the normal PType handler that splits them up.
Maybe another dayā¦Iāve got a mix of mixed horizons (which I have now made work) and experience assets (which is a new thing that now needs to be brought in where it never existed before).
Iām guessing that the right place to split the ExpAsset handler is the function TransitionPath_FHorz_PType_singlepath (which would then be TransitionPath_FHorz_PType_singlepath_ExpAsset for the ExpAsset case, which would in turn call various things like TransitionPath_FHorz_PType_singlepath_ExpAsset_raw).
Iām not quite clear where to add ExpAsset to the name (right after FHorz, after PType, or after singlepath), but for now I can just pick a spelling a fix it later.
Related: Iām not sure how to place ExpAsset in the TransitionPaths file hierarchy. It could be a subdir of FHorz or it could be something that gets buried in the subcodes directory. We ultimately need to specialize the logic that is presently in ValueFnIter_FHorz_TPath_SingleStep to work with ExpAssets. But I donāt understand the meaning of subcodes in this particular context, so am reluctant to just randomly create a new ExpAsset directory without at least some guidance as to where to root it.
