Incorporate "arrival" variables in simulation

[mnwhite]

This issue is reproduced from communications among team members.

---

MNWHITE writes:

As is, our simulator methods "start" each period with last period's so-called post-state variables (information at the very end of the period). Specifically, they take these values from the state_prev dictionary and then use them in the simulator method to make things that will go in state_now. E.g. the typical consumption-saving model uses aNrmPrev and pLvlPrev at the very start of a simulated period before using them to get bNrm and pLvl for the current period.

A side effect of this structure is that newborns initialize with "last period" post-state variables for a split second before they are converted to current period values. This is a little awkward and overall not great.

This work item is to implement in HARK something like the "twist" or "connector" concept that we will have in the StageClass / new structure. That is, an explicit mechanism for relabeling (e.g.) aNrm as kNrm "between" periods; nothing can "happen" in this interstitial step other than relabeling.

The general principle we want to adhere to is that symbols are never "recycled" within a period: each symbol means exactly one thing, nothing more and nothing less.

---

LLORRACC writes:

It's not clear to me that we need the "MNW twist" (not a popular new dance) to get started on this. Or even to finish.

The right way to get started is just to modify the model to give a new name (not aNrmPrev) to the incoming state variable. I think this requires any no coding, and so should be the first step.

I use the weasel words 'something related to k' because there's an irritating subtlety here. If the MNW twist says $k_{t+1} = a_{t}$, the problem is that $a_{t}$ is $A_{t}/P_{t}$ and $k_{t+1}$ is therefore $K_{t+1}/P_{t}$, while for every other {t+1}- dated variable we want to think of it as being normalized by $P_{t+1}$. This is particularly awkward in the LaTeX documents because there is no obvious way to notationally signal the point that k is normalized by the previous period's permanent income.

This is easier in the code, because we can just give the variable a name like kNrmPrePermShk to transparently signal the point that when we move from the arrival to the decision stage this variable will evolve according to bNrm=(kNrmPrePermShk/(PermGroFac*PermShk))*Rfree and a code comment explaining what is going on will suffice.

The next step would be to go to the portfolio model(s) and modify them, too, to expect, say, lqd as their input, and to yield, say, bal as their output. (Note that we do not have the awkwardness of having to worry about normalization here because the normalizer, permanent income, is not realized during the course of the stage).

Whatever the variable names we use are, I want to be sure they map to corresponding variable names in SolvingMicroDSOPs-Latest. Unless we use in the code names that correspond to the LaTeX macros in SolvingMicroDSOPs, this will require edits to the SolvingMicroDSOPs.sty file.

---

MNWHITE writes:

This is for the HARK 1.0 project, not StageClass / HARK 2.0. If the "very beginning of period" state is going to be called some variation of k, then something in the code has to relabel a_t into k_t+1 at some point or the
simulation won't work.