BUG: reforms in `get_micro_data` don't catch Growth or Behavior parameters

[talumbau]

in get_mico_data.get_data we accept the user's reform as a dictionary. This dictionary may have parameters in it that are specific to Growth or Behavior objects. Instead of filtering out for those key/value pairs, we pass everything to implement_reform. For example, _factor_target is not known to the Policy object, so it raises an exception.

The solution is to filter out the proper key/value pairs for Growth and Behavior and create those objects separately.

[MattHJensen]

@talumbau suggested in an email:

perhaps the right thing is to catch this sort of thing on TaxBrain (no dynamic jobs if you did a microsim with modified Growth or Behavior parameters).

That seems right to me. What do you think @jdebacker, @rickecon, @kerkphil?

[jdebacker]

This is fine with me.

But to be sure - it sounds like the error is just in how these parameters are passed - and not anything fundamental to the macro model (e.g., we can solve with a growth rate of 3% or 4%)? Is that correct @talumbau ?

[talumbau]

Yes, @jdebacker correct. We could provide three different reform dictionaries to the get_data function (policy, growth, behavior) but it's just that TaxBrain is currently set up to give you one dictionary and you have to split up the parameters somewhere. It might be best to handle this upstream.

[jdebacker]

Thanks, @talumbau Your proposed solution is a good one.

[rickecon]

That is fine with me also. The way input flow is set up on TaxBrain, I don't see any way around dealing with multiple input dictionaries.

[jdebacker]

@talumbau Can we close this issue?

[rickecon]

If behavioral assumptions are important in microsimulation results, then we must use them in our simulations that are incorporated into OG-USA. A fundamental characteristic of the bridge between Tax-Calculator and OG-USA is that their are inconsistencies between the assumptions of the two models. The ideal is to remove as many of these inconsistencies as possible. By putting the behavioral parameters into our Tax-Calculator runs that are called by OG-USA, we make the Tax-Calculator output more consistent with OG-USA. I think we need to be able to pass these elasticity and growth parameters to Tax-Calculator from OG-USA. @jdebacker @MattHJensen

[jdebacker]

I think we want to pass the growth parameters, but not the elasticity parameters.

There will be an inconsistency in the growth assumptions used to extrapolate the data for the Tax-Calc runs because these growth assumptions may not line up with the growth determined by OG-USA. The only way to fix this is through a fixed point algorithm. This will take a lot of time to run and should be put off into the future. I think we should allow the inconsistency that comes with the user specified growth parameters being passed to Tax-Calc.

With behavior parameters, such as user specified elasticities, we should not use these in determining tax rates that are used in OG-USA. The reason is that OG-USA models the behavioral responses that the elasticities are meant to summarize. We don't want to double count the behavioral responses. The exception to this is that OG-USA does not capture certain responses to tax rates such as tax evasion. Thus the ideal thing to do would be to includes elasticities in the Tax-Calc run that only include effects of behaviors that are not explicitly modeled in OG-USA such as tax evasion. Right now we don't have good estimates of these elasticities. Including the full elasticity of taxable income would double count things, thus we should exclude applying behavioral assumptions to the Tax-Calc runs used for OG-USA.

I'm leaving this issue open because we will want to adjust get_micro_data.py to be sure that user defined growth factors will be passed correctly to Tax-Calculator.

[jdebacker]

To fix this:

1. Pass full reform JSON (with policy, growth, and behavior). Suppose this is called reform below.
2. Change line 78 of get_micro_data.py to be something like: policy1.implement_reform(reform['policy'])
3. Update growth parameters for calculator following example here (lines 88-101)
4. Update behavior params as done here (lines 152-154)

[jdebacker]

Closing this issues. get_micro_data.py not has an argument to take growth factors. We determined above that we may not want behavioral parameters from the micro model. And if we do, this will require more changes than laid out here due to the separation between the Behavioral Responses package and Tax-Calculator.