Meta-issue gathering info on parameters/functions that vary by year

[hmgaudecker]

Current and desired situation

Currently, we have one humongous set of functions for all years, varying essentially only parameters. Ad-hoc functions like wohngeld_miete_m_hh_ab_2009_bis_2020 notwithstanding.

We will need to improve our handling of how to set up the policy environment. This issue is to gather all cases to keep in mind.

1. Obvious: Functions that change interface over the years. Just search for _ab_ and _bis_ in the (functions) codebase
2. Functions that stay the same up to parameter changes, but change name (example: Many components of Arbeitslosengeld II -> Bürgergeld)
3. Cases where we want to set up derived parameters to use in functions for clarity / consistency / speed instead of the parameters specified in the law (e.g., calculate the threshold for soli_st where the lower rate applies and not the maximum rate, see #444).

I distantly remember similar issues to 3. in the pensions discussion, @ChristianZimpelmann @TeBackh if your memory works better, please add specific examples.

Everybody, if anything comes to your mind, please extend this list!

[ChristianZimpelmann]

I would add:

• Functions that stop existing at some point (I think this cannot be handled properly by our current setup as the function is still loaded and can be selected as target).
• Parameters that only exist for a limited amount of time (similar to 1.) (Set to null in some cases (e.g. maximum in kinderzuschl.yaml) and to 0 in some others (e.g. vermögensfreibetrag in grunds_im_alter.yaml))
• Parameters that change names (similar to 2.)
• The parameters for which something like 3. is implemented are in policy_environment.py: kinderzuschl_max, einführungsfaktor_vorsorgeaufw_alter_ab_2005. I also don't remember whether we had more cases during the pension discussions.

[mjbloemer]

One additional point that comes to my mind:

• _ab_ and _bis_ might also not be the best solution if we want to avoid duplicate functions: There are some policies that are active in multiple periods with gaps in between. For instance, Wohngeld Heizkosten-Komponente (I think active in 2009 and 2010, abandoned 2011--2020 and then again active using the same structure 2021--2022), maybe Soli, or Kinderzuschlag Höchstbetrag (defined by law vs. calculated from other parameters).

[hmgaudecker]

The Kinderzuschlag Höchstbetrag was actually the example I tried to think of above, was looking in the wrong spot. Thanks!

[ChristianZimpelmann]

• input variables that are only necessary for certain time periods. E.g., currently bürgerg_bezug_vorj is a required input even for years before 2023. I actually realized that this is handled already fine. But I leave it here for completeness.

[hmgaudecker]

• input variables that are only necessary for certain time periods. ~E.g., currently bürgerg_bezug_vorj is a required input even for years before 2023.~ I actually realized that this is handled already fine. But I leave it here for completeness.

I initially thought you were worried about the edge case of 2022-23, where I guess the state variable should "officially" be arbeitsl_geld_2_bezug_vorj... But that will be for the documentation of required inputs, I guess.

[hmgaudecker]

Broadening the scope of "meta" just slightly:

• Hardcoded numbers in test_docs.py: for year in range(1990, 2024):

• Make it easy to dynamically generate tables in the docs with all required input variables, which vary by year (e.g., in #448 the type change of wohnfläche_hh did not make it into docs/gettsim_objects/input_variables.rst)

  Get rid of _gettsim/functions.py in the process of implementation.

[ChristianZimpelmann]

Another goal when working on this should be to have DEFAULT_TARGETS date-specific. Some targets do not exist for the whole period we will be supporting (e.g. Kinderzuschlag)