Wohngeld on individual / BG level

[MImmesberger]

Closes #752

Also, this PR fixes a bug through which Kindergeldübertrag was too high (because Kindergeld was already counted as income when calculating the difference between Regelbedarf and income).

[codecov]

Codecov Report

Attention: Patch coverage is 98.52941% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.57%. Comparing base (84246be) to head (6f8e2c9).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
src/_gettsim/groupings.py	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #753      +/-   ##
==========================================
+ Coverage   89.53%   89.57%   +0.03%     
==========================================
  Files          52       52              
  Lines        3688     3711      +23     
==========================================
+ Hits         3302     3324      +22     
- Misses        386      387       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hmgaudecker]

I adjusted the title because the individual-level calculation of things is the core from my perspective, even though the main outputs may be at the bg level then.

[MImmesberger]

Not to argue against the renaming but to make sure we're on the same page: I'd say that at the core, it's a BG-level calculation because the Vorrangprüfung happens at the BG level (to do it on the individual level, we would have to split up Regelbedarf or ALG2 on individual level).

[hmgaudecker]

All good — nur to my mind that's just one of many calculations, other important ones happen at the level of the individual!

[MImmesberger]

The Kinderwohngeld implementation now relies on the eigenbedarf_gedeckt bool (it basically turns on and off the consideration of Kinderwohngeld for the calculation of the Kindergeldübertrag).

If we ever make eigenbedarf_gedeckt endogenous, we need to calculate Wohngeld/ALG2 in two steps:

1. Calculate Wohngeld and ALG2 for the child, make Vorrangprüfung and calculate, based on this Kindergeldübertrag (based on the result for Wohngeld) and bg_ id.
2. Calculate ALG2 and Wohngeld for the parents given Wohngeld/Kindergeldübertrag of the child, and given bg_id.

[ChristianZimpelmann]

Thanks! Two quick comments.

[ChristianZimpelmann]

Should again probably contain vor_vorrang_check

[MImmesberger]

If anything, it's nach_vorrang_check

[ChristianZimpelmann]

Why? it uses the input wohngeld_vor_vorrang_check_m? And it represents potential Kinderwohngeld not the Kindergeld that is indeed paid out, right?

[MImmesberger]

Because of eigenbedarf_gedeckt the outcome of the Vorrangprüfung is already specified. But given your comment above, we might get rid of this function anyway.

[hmgaudecker]

The Kinderwohngeld implementation now relies on the eigenbedarf_gedeckt bool (it basically turns on and off the consideration of Kinderwohngeld for the calculation of the Kindergeldübertrag).

If we ever make eigenbedarf_gedeckt endogenous, we need to calculate Wohngeld/ALG2 in two steps:

1. Calculate Wohngeld and ALG2 for the child, make Vorrangprüfung and calculate, based on this Kindergeldübertrag (based on the result for Wohngeld) and bg_ id.

2. Calculate ALG2 and Wohngeld for the parents given Wohngeld/Kindergeldübertrag of the child, and given bg_id.

Sure, I am sorry that this did not become clear all along. Do you see any issue with it?

[MImmesberger]

Sure, I am sorry that this did not become clear all along.

You probably made it clear, but I didn't thought about it deep enough :)

Do you see any issue with it?

I think this goes along the lines of the discussion we had yesterday on Zoom (trying out different constellations of BGs to arrive at the actual BG/wohngeldrechtl. Teilhaushalt combination). We have to call the current version of GETTSIM several times to achieve correct results.

[hmgaudecker]

We have to call the current version of GETTSIM several times to achieve correct results.

That is true.

I think this goes along the lines of the discussion we had yesterday on Zoom (trying out different constellations of BGs to arrive at the actual BG/wohngeldrechtl. Teilhaushalt combination).

To the extent that Wohngeld is linear in the number of people in the entire household (by Wohngeld def), we do not need to try out too many different combinations, right?

1. Set bg_id = fg_id for all households without children or where children have no income.
2. For the remaining households,
   1. Calculate maximum WoG (always individual level, since linear) and BüG while ignoring childrens' income, setting bg_id = fg_id. (This will give the set of potential BüG beneficiaries, we can ignore everyone else)
   2. Set bg_id = fg_id if no eligibility for BüG even when children's income is ignored.
   3. For everyone else, create eigenbedarf_gedeckt when each child forms his/her individual bg (requires maximum WoG from step 2.1 and BüG at the individual level). Create bg_id for the remaining households.
3. Stack the data from 1, 2.i, 2.i and run GETTSIM for all households, using endogenous bg.

Probably not complete yet and my model of how this could work was definitely not complete! I think the upshot is there really is no way of representing it in one DAG when the functions have the same names.

If that makes sense, then to achieve the above 6 steps, we can either create a little helper script somewhere or document this. The planned interface change should make this sort of thing very natural.

[MImmesberger]

To the extent that Wohngeld is linear in the number of people in the entire household (by Wohngeld def), we do not need to try out too many different combinations, right?

Yes that's true, I'm just very pessimistic regarding that actually being true.

[hmgaudecker]

We'll know soonish, I hope.

But in any case, I am not super-worried anymore, in the above thing it would mean doing lots of permutations on children in step 2.iii, which presumably will be a small set of people in most applications (colleagues at IAB might form an exception).

And you won't have to run steps 1 and 2 many times in any given application. Will be very natural with a revamped interface.

[hmgaudecker]

Just needed for the rain to stop -- looks great! Mostly stylistic comments.

[MImmesberger]

FYI: I'm still writing some tests that cover Mischhaushalte. Currently facing some bugs where GETTSIM and the calculator by BMWSB disagree but will fix that asap.

[MImmesberger]

Currently facing some bugs where GETTSIM and the calculator by BMWSB disagree but will fix that asap.

I noticed that the calculation of Mietkosten was wrong. This should be done on hh level and then disaggregated "pro-Kopf". (See for example page 30 here)

I added Mischhaushalte to test the module, we get the same results as the BMWSB with its Wohngeld calculator.

I didn't implement #713 but I think we can do this in a different PR because this isn't central to what you're trying to do with the Wohngeld module, correct @ChristianZimpelmann ?

(Will add a test for the two remaining uncovered lines tomorrow)

[ChristianZimpelmann]

Looks great! I will try it out today.

I didn't implement #713 but I think we can do this in a different PR because this isn't central to what you're trying to do with the Wohngeld module, correct @ChristianZimpelmann ?

Yes, this shouldn't be relevant for now.

[MImmesberger]

As discussed I added Wohngeld to the relevant income of the child to calculate Kindergeldübertrag. (We don't have official data or calculators for Kindergeldübertrag, that's why didn't catch this one before.)

[hmgaudecker]

Looks great to me -- will be away from the machine for a bit, so this is to signal I am very happy with this. Great work!

[hmgaudecker]

^ Or did I miss anything in #710 that you don't tackle here?

[MImmesberger]

No, we can close that one. But I'd suggest to leave #752 open (because we are not 100% sure that our implementation is correct)

[hmgaudecker]

I'd suggest to leave #752 open (because we are not 100% sure that our implementation is correct)

No. If new things come up, it is important to go through the process of explaining what is wrong. Better open a new issue for that then. There isn't a whole lot of information in that issue, either.