Alloc rule 2 bug

[Ha-Ree]

Fixes the back-allocation half of OasisLMF#2055 — under -a2, per item losses depend on which policy happens to be layer 1, so per location IL depends on the row order of account.csv. Also fixes three segmentation faults in the same function, two of which 3.12.4 already has.

The bug

compute_item_proportions has two ways of working out the item proportions used to back-allocate a level's loss:

• alloc rule 3 computes them at every level and layer as the calculation walks up the hierarchy
• alloc rule 2 computes them lazily, only once it reaches the final level

Under rule 2 nothing ever fills in agg_vecs[level][layer].item_prop for the intermediate levels of layers above 1, so when the final level chains through the level below it finds a null and falls back to layer 1's proportions:

if (prev_agg_vec[i].item_prop == nullptr) {
    prev_agg_vec[i].item_prop = prev_agg_vec_base[i].item_prop;   // layer 1
}

Every layer therefore gets back-allocated using layer 1's distribution of loss over items. Since layer_id follows the row order of account.csv, reordering the file changes which policy is layer 1 and so changes every layer's item split. Rule 3 was unaffected because it never leaves the gap.

The two rules were never intended to differ. Rule 3 was added in 7bbb5a6 as a lazy variant of the existing rule, and 817eee8 ("switch alloc rules 2 and 3") swapped the numbering so the lazy implementation became the default 2. The loop bodies carry identical comments.

Three more bugs in the same function

Chasing the first one surfaced three others, all of which 3.12.4 has:

The layer 1 pass skips aggregations with no loss (allowzeros == false on the sampled path), leaving their item_prop null. If a later layer does have loss at such an aggregation, the fallback above hands it a null pointer and fmcalc dereferences it. 3.12.4 segfaults on 8 of 250 random multi-layer structures under -a2.

A sibling branch borrows layer 1's proportions at the same level. Where the level below does not carry the current layer, compute_item_proportions copies agg_vecs[level_][1]'s proportions rather than computing this layer's. When layer 1 has no loss at that level its proportions there are all zeros, so every other layer copies the zeros and allocates nothing: the layer's loss is not redistributed, it disappears, and back-allocated losses sum to zero against a non-zero layer loss. This one affects -a3 as much as -a2, and it is why rule 3 is no longer untouched by this PR.

An item with no entry at the previous level indexes with -1. The item to previous-level-index lookup leaves -1 wherever the previous level's loss vector does not cover an item, which happens when that level's aggregation ids are not contiguous. The -1 was then used to index that vector, both when totalling the previous level's loss and when reading back item_idx, so fmcalc read out of bounds and faulted on a null item_idx. 3.12.4 hits this under -a3.

The fix

In the per-layer branch of compute_item_proportions:

1. If this layer's proportions for the previous level are missing, compute them (recursing down the levels) instead of falling back to layer 1.
2. At level 1, always populate the ground up share proportions. They are the same for every layer, so this both provides the base case for (1) and removes the null dereference where layer 1 skipped a zero loss aggregation (case2).
3. Restrict the same-level copy shortcut to level 1. A sibling branch had the identical defect: where the level below does not carry the current layer, it copied layer 1's proportions at the same level instead of computing anything. Level 1 is the only level with no level below to compute from; above it the proportions come from agg_vecs[level_ - 1][1], which every layer above shares. This is what fixes the dropped layer losses and the remaining crash of that shape (case3, case4).
4. Skip items that have no entry at the previous level. The item to previous-level-index lookup leaves -1 for any item the previous level's vector does not cover, which happens when its aggregation ids are not contiguous, and the -1 was used unchecked both to total the previous level's loss and to read back item_idx (case5).

Alloc rules 0 and 1 are untouched. Rule 3 is not — items 3 and 4 fix rule 3 as well as rule 2, because both rules reach the same two branches. That is a change from the earlier revision of this PR, which claimed rule 3 was unaffected.

Verification

The test that matters most is conservation: the back-allocated item losses for a layer must sum to
that layer's gross, which -a0 reports directly. It needs no reference implementation to be
believed.

check	result
300 randomly generated multi-layer structures, back-allocated total vs -a0 gross per layer	conserved on all 300 under -a1, -a2 and -a3, no crashes. Before this PR's final two commits, -a2 crashed on 14 and lost loss on 10 of the remainder, and -a3 lost loss on 19
Same 300, -a2 vs -a3	identical on every value
Same 300, -a0 and -a1	byte identical to develop — neither rule is touched
reinsurance_tests/target structures (ri1, ri2, ri2_2layer, ri2_2layer_2level), -a0/1/2/3	byte identical to develop. ri2_2layer_2level is exactly the at-risk shape — one layer at level 1, two at level 2 — and is unchanged because layer 1 has loss at every aggregation there
make check	425 checks pass. develop fails case1 -a2, case2 -a2, case3 -a2, case4 -a2/-a3 and case5 -a3; the previous head of this branch fails case3 -a2, case4 -a2/-a3 and case5 -a2/-a3
OasisLMF#2055 end-to-end reproduction	no longer reproduces on current OasisLMF, on any binary. See below

The #2055 reproduction no longer discriminates

The earlier revision of this description reported 161,418 / 112,220 for the two row orders against
148,786 after the fix. Re-running it today through RunExposure on oasislmf 2.5.6, all three
binaries — 3.12.4, the previous head of this branch, and this one — give L1=148,786.77 and
L2=342,962.73 for both row orders, and report order-independent for both -a2 and -a3. The
generated fm_policytc.bin and fm_profile.bin still differ between the two row orders, so the
reversal still changes the structure; it no longer changes the answer. Upstream input generation
has moved since this branch was opened, so that end-to-end case cannot be used as evidence either
way any more. The 300-structure conservation result and case3/case4/case5 are what stand
behind the fix now.

The saved FM inputs from the original reproduction are still a useful direct test, and they are
where case5 came from: 3.12.4 runs them under -a2 but faults under -a3, the previous head of
this branch faults under both, and this branch runs all four rules and conserves.

Existing runs are only affected where a programme has more than one layer and either layer specific terms below the top level that distribute loss over items differently, or a layer with no loss at a level where a later layer has some, or non-contiguous aggregation ids at a level. Single layer programmes, and layers whose terms are all blanket, are bit for bit unchanged — as are all four reinsurance_tests structures.

Performance

No measurable change on single layer structures. About 15% slower on a 4 level, 4 layer structure, which is the cost of doing the per-layer work that rule 3 always did. Rule 3 now does the same per-layer work at the two branches it previously short-circuited, so it is marginally slower on those shapes too.

Tests

ktest had no back-allocation coverage at all: fmcalc was only ever run with the default -a0. This adds five small cases under examples/fm_alloc, each run through -a1, -a2 and -a3. The arithmetic for each is in the README:

• case1 — 4 items, 3 levels, 2 layers, with layer specific coverage limits that make the two layers distribute their loss over the two locations in opposite proportions. Small enough to check by hand. The regression test for the ordering bug.
• case2 — 5 items, 2 levels, 3 layers, where layer 1 has no loss at an aggregation that a later layer does. The regression test for the first segfault.
• case3 — 2 items, 3 levels, a single layer at level 1 and two above it, layer 1 wiped out at the top level. The recursion terminates in the same-level copy branch with layer 1's proportions absent. Faults under -a2 without fix (3).
• case4 — case3 with a single layer at level 2, so the top level takes the copy branch directly and copies layer 1's zeros. Layer 2's entire 4000 loss was dropped rather than allocated, under -a2 and -a3 alike, which is why this case is the regression test for rule 3.
• case5 — 2 items, 4 levels, 4 layers, reduced from the #2055 client structure by dropping items until the fault stopped reproducing. Level 1's aggregation ids are not contiguous, so an item has no entry at the previous level and the -1 placeholder was used as an index. Faults under -a3 on 3.12.4 and under both -a2 and -a3 on the previous head of this branch.

For case1 to case4 the expected -a2 and -a3 outputs are identical, which is the invariant this PR restores. case5's -a1 output is pinned as a change detector rather than as a correct answer: -a1 allocates 54.41 to a layer whose gross is 92.50 on that structure, which is a separate pre-existing problem in the rule 1 path and is not addressed here.

Docs

One sentence in docs/md/fmprofiles.md recording that rules 2 and 3 are the same calculation with different evaluation strategies, since the table's "(reinsurance)" label reads as though they differ.