Set starting aNrm for Lucas population near equilibrium

[sbenthall]

Related to #204

solve_distributed_agents calls solve() on each AgentType https://github.com/sbenthall/SHARKFin/blob/cd70a7a18282e348738884c60ee8c378c6b99040/sharkfin/population.py#L258-L262

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]

https://github.com/sbenthall/SHARKFin/blob/9140b17ae62fcdb7d33b440d78a394e03bc790f6/simulate/parameters.py#L10-L32

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]

https://github.com/sbenthall/SHARKFin/blob/9140b17ae62fcdb7d33b440d78a394e03bc790f6/sharkfin/population.py#L280-L299

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: https://github.com/sbenthall/SHARKFin/issues/199#issuecomment-1494933613

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)

https://github.com/sbenthall/SHARKFin/issues/199#issuecomment-1494933613

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 https://github.com/sbenthall/SHARKFin/issues/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 https://github.com/sbenthall/SHARKFin/issues/205#issuecomment-1496453774, 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. 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 https://github.com/sbenthall/SHARKFin/issues/205#issuecomment-1516745161, 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.