Include possibility for meta-calls in API

[hmgaudecker]

This has come up during the discussions on #778 and related.

The graph relies on a 1:1 mapping of function arguments and data. But we need a (n unknown) number candidate contents of bg_id and wthh_id in order to determine the correct setting in households where we have more than one fg and/or more than one bg.

#778 solves this via a complex workaround, which involves manually using fg_id as a candidate bg_id. It only works for a small number of candidates and which requires fg_id == hh_id.

Instead, we should provide for an option to

1. Call a part of the DAG / another function which returns all possible candidate bg_id-wthh_id constellations, which pass some "absolute" checks (e.g., we won't need to worry about households failing the wealth checks).
2. Create a sub-DAG, which will output the required targets (here, probably something like whether a particular candidate allocation of bg_ids and wthh_ids is valid in the first place along with eligibility for and payments from arbeitsl_geld_2, kinderzuschl, wohngeld).
3. Make checks like vorrang or günstiger based on the results from 2.

This will be complex, also for users. We may want to provide a shortcut that allows for the same setup as we used to have: bg_id == fg_id == wthh_id == hh_id, then the checks are trivial.

[hmgaudecker]

The use case is so tiny that it won't be worth it to implement this.

Rather, we should provide a recipe in a separate repo that

1. generates all $$k$$ possible and feasible permutations of bg_id and wthh_id
2. runs GETTSIM $$k$$ times
3. Picks the correct configuration of bg_id and wthh_id

[MImmesberger]

Not sure about this.

The issue is less about being unsure about which individuals belong to one BG (this is indeed not too relevant for most people / datasets and is super complicated) but about households with more than 1 generation (single adult + parents). Currently, we treat them correctly as individual BGs and assign them to an wthh_id based on this. Due to nonlinearities in the formula, this can be quite wrong.

Basically, any plot of disposable income vs earnings of a household with more than 1 BG is wrong near the SGB XII Bedarf.

If anything, we should get rid of endogenous bg_ids and wthh_ids and enforce the usage of such a configuration repo. If possible, doing it endogenously would be nicer IMO.

[hmgaudecker]

we should get rid of endogenous bg_ids and wthh_ids

Yes, this is what I meant!

Sure the other thing would be nicer, but it would make the whole architecture much more complicated. Almost certainly not worth it.

So to be clear, bg_id and wthh_id would become policy_inputs. In both docstrings and elswhere in the docs, we will point to the recipe. Running that won't be hard -- fairly easy to implement that logic 1-3 above outside of GETTSIM, but difficult to do within.

[MImmesberger]

Okay, I agree. But fairly easy to implement gave me some serious Vietnam flashbacks from last spring. 😄

[hmgaudecker]

That was a purely relative statement, ofc!