Set starting aNrm for Lucas population near equilibrium

[sbenthall]

Related to #204

solve_distributed_agents calls solve() on each AgentType

SHARKFin/sharkfin/population.py

Lines 258 to 262 in cd70a7a

	def solve_distributed_agents(self):
	# see Market class for an example of how to solve distributed agents in parallel
	for agent in self.agents:
	agent.solve()

When we have multiple AgentTypes 'per type' (i.e. num_per_type), this introduces unnecessary computation, because the same solution can be used across different AgentTypes.

[alanlujan91]

SHARKFin/simulate/parameters.py

Lines 10 to 32 in 9140b17

	def build_population(agent_type, parameters, rng=None, dphm=1500):
	num_per_type = parameters.get("num_per_type", 1)
	pop = AgentPopulation(
	agent_type(), parameters, rng=rng, dollars_per_hark_money_unit=dphm
	)
	if "approx_params" in parameters:
	pop.approx_distributions(parameters["approx_params"])
	pop.parse_params()
	pop.create_distributed_agents()
	pop.create_database()
	pop.solve_distributed_agents()
	pop.solve(merge_by=parameters["ex_post"])
	pop.explode_agents(num_per_type)
	# initialize population model
	pop.init_simulation()
	return pop

This depends on the ordering of the methods. If you see the method above, solve happens before explode_agents, so this should only be solving the unique agents with ex_ante heterogeneity. In the Lucas case, this should be 1 agent.

However, I notice that there are more than 1 build_population methods on the codebase, we should probably get rid of those and just use the one above.

[sbenthall]

Hmm.

I think 'solve' got called 10 times when I ran:

$ python run_any_simulation.py --quarters 1 --dphm 500000 ../output/20230321_o

(I got 10 copies of the Thorn, etc., output)

I think that's using the build_population in parameters.py

I wonder if this is slowing down the tests as well.

[alanlujan91]

Are we solving anywhere else after creating the population?

[alanlujan91]

SHARKFin/sharkfin/population.py

Lines 280 to 299 in 9140b17

	def init_simulation(self, T_sim=1000):
	"""
	Sets up the agents with their state for the state of the simulation
	"""
	for agent in self.agents:
	agent.track_vars += ["pLvl", "mNrm", "cNrm", "Share", "Risky"]
	agent.T_sim = T_sim
	agent.initialize_sim()
	if self.stored_class_stats is None:
	## build an IndShockConsumerType "double" of this agent, with the same parameters
	parameters = agent.parameters.copy()
	if "Rfree" in parameters and isinstance(parameters["Rfree"], list):
	# patch potential bug until HARK is updated
	parameters["Rfree"] = parameters["Rfree"][0]
	ind_shock_double = cism.IndShockConsumerType(**parameters)
	## solve to get the mNrmStE value
	## that is, the Steady-state Equilibrium value of mNrm, for the IndShockModel
	ind_shock_double.solve()

Seems like we are solving the equivalent ind_shock agent for every agent, this probably shouldn't be happening

[sbenthall]

Aha. That could be it.

I think we're doing this because @llorracc was interested in the mNrmStE value for some reason.
But we haven't used it in any analysis and it adds a lot of overhead....

I guess it could be done once for each agent class/type, if needed.

[sbenthall]

I've tested commenting out that 'solve' use, and that's indeed it.
Thanks for catching that!

For G.G. Shark I'm going to hackily disable this code. We should figure out how to really fix this for FIRE SHARK.

[ccarrollATjhuecon]

Yes, I am interested in mNrmStE. But there's a unique answer to that which gets constructed automatically when the agent's problem is solved. I can't see any reason to recompute it. Why doesn't it just automatically transfer when the agent is duplicated?

[sbenthall]

Monday's discussion, and especially @alanlujan91 's point about starting wealth values, reminded me why we computed this:
#199 (comment)

I think the idea was that we would initialize agents with starting wealth calibrated to the normalized market asset holdings at steady state equilibrium (mNrmStE) so that we avoid the effects that @alanlujan91 was pointing to. See #30

I believe the reason why we were solving the agent twice is that mNrmStE is computed when an IndShockConsumerType is solved. But it is not computed when a RiskyPortfolioConsumerType (or whatever) is solved. (I believe the mNrmStE value of the IndShockConsumerType is only approximately correct for the equivalent RiskyPortfolioConsumer).

[llorracc]

Well, if we don't compute mNrmStE for the PortfolioConsumerType, we should. It's a pretty easy calculation (as long as the parameters satisfy all the required patience conditions).

…

On Tue, Apr 4, 2023 at 2:59 PM Sebastian Benthall ***@***.***> wrote: Monday's discussion, and especially @alanlujan91 <https://github.com/alanlujan91> 's point about starting wealth values, reminded me why we computed this: #199 (comment) <#199 (comment)> I think the idea was that we would initialize agents with starting wealth calibrated to the normalized market asset holdings at steady state equilibrium (mNrmStE) so that we avoid the effects that @alanlujan91 <https://github.com/alanlujan91> was pointing to. See #30 <#30> I believe the reason why we were solving the agent twice is that mNrmStE is computed when an IndShockConsumerType is solved. But it is not computed when a RiskyPortfolioConsumerType (or whatever) is solved. (I believe the mNrmStE value of the IndShockConsumerType is only approximately correct for the equivalent RiskyPortfolioConsumer). — Reply to this email directly, view it on GitHub <#205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK75YNSAL4CMQUYN7BWLW7RVPPANCNFSM6AAAAAAWC3MG4Y> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- - Chris Carroll

[alanlujan91]

I can add including the calculation of mNrmStE to PortfolioConsumerType to my to do list. I agree that it would be more efficient for Portfolio agent to do this calculation rather than having to create and solve a separate IndShock agent just for this calculation.

[sbenthall]

Thank you @alanlujan91 !

I wonder what the right general way to architect this sort of thing is.
Maybe something better to discuss on the HARK issue tracker.

[sbenthall]

@alanlujan91 Is the formula for mNrmStE written out anywhere?
I looked for it in the BufferStockTheory paper but couldn't find it.

I'm wondering because I'm wondering how this interacts with the near-zero income point. #208

[sbenthall]

mNrmStE is not analytically defined for the Portfolio or ConsInd shock models, but Tractable Buffer Stock has an analytic formula which is insightful for analysis:

http://www.econ2.jhu.edu/people/ccarroll/papers/ctdiscrete/

[sbenthall]

What if rather than trying to do something too clever, we got the equilibrium/starting wealth value by:

• solving the (homogeneous) agent type
• Just once, simulate forward until aNrm converges with:
  • Arbitrary starting wealth (I think starting high would converge faster than starting low, because income is very low)
  • Setting the risky mean and standard deviation to match the USUAL expectations

Then take that aNrm value and use it as the initial aNrm for all the agents in the big simulation.

Do you think that would work, @alanlujan91 ?

[alanlujan91]

this could work, although I'm not sure if we have infrastructure for simulate until aNrmAvg converges

[llorracc]

Well, the easiest way to do it is just to find the intersection of the consumption function and the "expected sustainable consumption" locus. The latter is defined by c = 1 + E[R-1]/E[R]. where E[R] is the expected portfolio weighted rate of return. This is basically the $\Delta m^{e}=0$ locus in [TractableBufferStock]( https://llorracc.github.io/TractableBufferStock/#x1-130002.2.9). Requires no simulation. It's not exactly "mNrmStE" but very close to it.

…

On Thu, Apr 20, 2023 at 2:08 PM Alan Lujan ***@***.***> wrote: this could work, although I'm not sure if we have infrastructure for simulate until aNrmAvg converges — Reply to this email directly, view it on GitHub <#205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK72RFWCTXQIXC6VI3QLXCF3SVANCNFSM6AAAAAAWC3MG4Y> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- - Chris Carroll

[sbenthall]

Cool thanks for pointing that out @llorracc

[sbenthall]

Just as a short term fix....

This script simulates forward 3000 agents of our Lucas configuration for 3000 time periods, then plots the mean of their (natural) log mNrm over the course of the simulation.

https://github.com/sbenthall/SHARKFin/blob/master/macro/steady_state_mNrm.py

Here is the output from that:

While it's still quite choppy, I'll set the starting aNrmInitMean to 6, which is where the process seems to settle given the current parameters.

@alanlujan91 any improvement on this rough cut is of course most welcome.

[alanlujan91]

@sbenthall this is a good start, although now that we have this we should set aNrmIntMean to 6 and see if it stays around 6.