Allow the Steady state function capable of accepting various number of euler equations.

We need a formal write up of this choice by the firms.

Our model will not match CBO forecasts exactly because it is OLG and the CBO model is not. We need a method of ensuring that our model generates as close to the same tax revenues as possible in the same categories as the CBO model generates when its assumptions are run through the MicroSim model. A document "HittingCBOTargets" details how to ensure our model does this over a chosen time horizon.

We need to calibrate the responsiveness of world interest rates to changes in the US net supply/demand of savings for each period in the model. This is potentially time-varying since foreign supplydemand are likely to grow faster than US net supply/demand.

We also need calibrations of the responsiveness of world prices to changes in the US net supply/demand for tradable goods.

How do we handle consumption goods imports/exports vs production goods imports/exports?

Do we want to deal with labor migration?

Generalize the function in wealth_data to accept any vector of bin weights. Currently, the function is not used, and instead wealth_data.py outputs the 7 data vectors needed by the wealth tax paper automatically.

The minimizer is not changing the values after iterating with method 2. I think this is either a problem with xtol and mindist in the SS.py file, or the scaling and tol in the minimizer.

Make the parameters no longer globals. This will be accomplished easiest as we go through and make separate files for the different functions.

Make a pickle just for the exogenous parameters, and another for just endogenous variables. There is currently one for parameters, and another for parameters and endogenous variables. Remove the overlap.

Treat states as small open economies which take the aggregate macro effects as given. With detailed demographic information on each state, we can see how their set of households evolve over time and the federal tax burdens each household will pay. Similarly, we should be able to find out the mix of industries in each state and approximate taxes from each of these.

Note we will need migration estimates into and out of each state, including (primarily) migration between states, but within the US.

Make the code Python 3 compatible.

Condense all the total_taxes functions into one function, with multiple methods for the various shapes of inputs/outputs needed.

Back in October, using the old SS solution method, we had to take out the consumption tax because of a fixed point in the solution method. In order to know consumption, we had to know the lump sum tax, but we could know the lump sum tax unless we knew consumption, since consumption times the consumption tax was needed to compute the lump sum. To avoid a nested fsolve, we removed the consumption tax from the paper. However, Isaac noted that now that we are guessing the lump sum tax (T_H) in an outer loop, this problem no longer exists in SS or TPI. If @rickecon or @kerkphil can retype up the euler equations with the consumption tax (they should be saved somewhere, but we should make sure they're right), I think it would be really easy to put that back in on the household side.

@evan-magnusson Can you check that C+I=Y (where I=delta*K in the SS) from the solution to SS.py (i.e., using Kss, Yss, cssmat, and omega_SS). I did this and didn't find the constraint satisfied, but I may have done something wrong.

Currently, we use the excel spreadsheet to calibrate the wealth tax to the baseline distribution of wealth. Move this to a python file that can be called within run_tax_experiments.py to skip this step.

Many parts of the code, especially those dealing with the calibration (such as func_to_min in SS.py) only work for J=7 or S=80. We need to go through the code and get rid of these problems eventually.

Income.py has a better fit, using polynomials which Jason computed. However, we only have the polynomials for the 7 percentile groups used in the wealth tax paper. Unless we can get polynomial fits for all percentile groups, we should stop using income.py, and move to income_nopoly, which just uses the raw data.

In TPI, all the euler equations are not functions. We might want to change this so we only have to change the euler equations in one place.

Condense the graphing files back down to just 2 files: SS_graph.py and TPI_graph.py

We talked about an alternative model with the assumed demographics are used to age the microsim sample. A write up of this is found in the document "AlternativeSimpleDynamicModel".

Instead of unpickling these values in SS.py as globals, unpickle them just as the dictionary. Then, define the variables.

In 2.3.1-2.3.3 put the tax treatment type as a subscript. Also fix some missing \tau superscripts.

Create a new SS solver that is more robust that only needs guesses for w, r, and BQj (and T_H). Make sure it includes the market clearing conditions.

It's typically quite helpful to have a 'toy' dataset around that one can quickly use execute the code from start to finish. This serves as a reasonable 'smoke test' that lets one know that some code refactoring didn't do major damage. After such a 'smoke test', one would then typically go run the real test (which may take tens of minutes or more). This dataset only has to achieve two goals:

• it must be acceptable input for the code
• it should execute fairly quickly

It doesn't have to make mathematical sense as input, nor produce reasonable output. Issue #42 seems to indicate that we could now choose a very small J and S - is that correct? If so, is this likely to make the fsolves faster? For example, we could set J=3 and S=8. Is it easy to describe how one would create such a 'mini-input'? If so, could someone sketch out the necessary steps? I could dig in here, I just wonder how much expertise one would need to create such an input dataset.

Find a different way to update the guesses for b and n in the minimizer, without calling pickle twice per iteration, as this slows it down.

First, the nothing folder should be renamed (perhaps to pickle_storage), and then any reference to that folder in the code should be changed.

Also, there are currently 3 output folders: OUTPUT, OUTPUT_incometax, and OUTPUT_wealthtax. These should be changed/renamed to OUTPUT_tax1 and OUTPUT_tax2 (we only need 2, not 3).

The individual pieces of the extended model need to be folded into a single document that lays out the model in its entirety.

The arctan fit does not converge for a few of the groups -- fix the code so that it does.

Rename b1, b2, b3, b1_2, and b2_2, as well as Kssmat2, 3, etc, to more descriptive names.

Also, rename euler1 and other functions with more descriptive names.

Add comments to why c and b are constrained to be positive (according to the Euler equations, they can go negative, but theoretically they shouldn't). Test to see if the n constraints bind, if not, delete those constraints.

Check the derivation of the price of the composite consumption good for age s households in period t, p_{s,t}. Derived in Equation 1.18 in Section 1.2.1 of AEIBYUDyn.pdf. Without the sol'n of FR1993, the problem becomes difficult and maybe intractable.

We need a formal write up of the financial intermediary sector which accepts deposits from households and diversifies investment over the various firms in the model.

Make calibration.py its own function. Also, in SS.py there is code that calculates the percent differences between the data and the model moments. Move this to calibration.py as well.

Use the alternative model forecast method for the first guess. When this gets close to convergence, switch to full AK time-path iteration.

Change theta from a parameter to a variable, and then let it be calibrated within the SS solver.

Make a .py file that contains all the python functions used by SS and TPI to prevent overlap and condense the code. The functions will most likely need to be altered to take the parameters as inputs, as they might not work if the parameters are simply globals.

In the replacement_rate_vals() function in the tax.py file there is a bug of sorts. When we get the replacement rates, all but the lowest 25% of individuals hit the maximum payment. It is unlikely that the bottom 50% and above are making more than 30K a month, so there must be either a problem in the code itself, or the data/method we used to calculate the bins of the PIA.

In SS.py and TPI.py, variables and parameters are unpickled and put in globals namespace. We need to figure out another way to do this that is more...elegant.

Write up the model with these two taxes being imposed separately. The tax rate on wage income will differ from that on capital income, but both will be functions of total income.

We already have calibrated functions for these based on 2012 data in the Excel file, CalibratingTwoIncomeTaxes.xlsx.

My understanding is that in the current version of the dynamic model, if tax schedules are
not uniformly progressive, then a model solution cannot be found because there are
multiple roots. It seems to me that the size of the OASDI payroll tax and its sharp
discontinuity at the maximum taxable earnings level (with the MTE wage indexed) implies
a need to spend the extra computation time to handle this situation correctly. It would
seem that the first priority is to get this logically correct, then worry about how long it
takes the dynamic model to execute. Remember that for many people (a majority?)
their payroll tax liability is greater than their income tax liability, and that the nonlinearity
is substantial: a marginal tax rate of 12.4 percent below the MTE and a marginal tax
rate of zero percent above the MTE. Do my concerns make sense? Or, is there a way
to work around this without changing the root-finding algorithm?

In the comments for get_e, we see that the returned matrix e of shape SxJ is "normalized so the mean is one." However, neither the rows nor the columns of e have mean 1, which can be seen easily just by running the latest master and setting a breakpoint before return e_final. This is likely a trivial issue, but I just wanted to point it out. Perhaps I'm missing something eles?....

It's best to work with Python code as a package. It's easier to call certain pieces of the code and share it with others. I'll have a go at making a package. I intend to start with the code in Python/TESTED_DONT_TOUCH, since the goal is to create a Python package of the current "gold standard" version of the model. Let me know if I should start somewhere else @evan-magnusson @rickecon @isaacswift @jdebacker

Add description to the get_e() function in income_polynomial.py to add more description on what is going on. Also, pull the parameters to the top of the file.

Rename all of the variables in all of the code files to match the names of those variables in the document to improve readability and debugging later on.

What value of the Frisch elasticity to we want to use for the approximation?

There are multiple ways we can parallelize SS.py and TPI.py.

SS.py:
In the SS_solver() function, the for loop {for j in xrange(J)} on line 157 can be parallelized, as each j index of the array does not rely on anything that happens before it. J is 7 right now, and so the speedup wouldn't be huge right now. However, this would allow us to easily set J=100, and not have massive slowdowns. Also, if there is a way to parallelize the minimizer, huge speed ups would be had. The minimizer tests each element of the gradient (there are 87 elements to test), jumps, tests each element, jumps, etc. However, testing each of the elements does not require any info from testing the previous element. So it could test each element in parallel, jump, test each element in parallel, jump, etc. This would be much faster. So we either need to build a minimizer or find one that is parallelized.

TPI.py:
In the while loop that starts on line 275, there are a couple for loops that can be parallelized. The easiest would be the for loop on line 287 {for j in xrange(J)}. As in SS.py, this can be parallelized. Within this for loop (for each j), there are two for loops (not nested, separate) on line 288 and 299. These can happen at the same time, and these loops themselves can be parallelized for each s and t. So, we can parallize the J for loop, and then each processor can spawn 2 processes, for the S-2 loop and the T loop. Then, those can also spawn S-2 or T processes, respectively. We might not want to parallelize this much, as this is hundreds of processors. We might want to just parallelize the T for loop, as T is the largest. But we have lots of options here.

There are warnings being issued when demographics.py is run. It would appear that the way we are splicing arrays will not be valid in the future, so we should fix this soon.

We don't want the graphs generated in regular runs, so add flags to each graphing function in demographics and income to prevent this from happening. Also, in labor and wealth, make functions that control graphing. In labor, write a function that produces the data array.

Need to work on Extended Firms Problem.tex to include the firm's choice of equity shares outstanding.

We need to calibrate a response of profit-shifting to tax changes for each industry. The easiest way is with an elasticity assumption. However, a mean-variance risk aversion model on the part of the firms could generate this response function endogenously as a function of home and foreign rates of return, home and foreign taxes, home and foreign variances on returns, and a risk aversion parameter. I quick writeup of such a model and a calibrating spreadsheet has been added under the Model Writeup folder with the titles ProfitSharingModel.

Need to look into estimating the distribution of bequest from agent j,s,t who dies to agents next period over all types, j, and all ages, s,.