Skip to content

Use enabled_ifo_id for write_ifo_mapping

Timothy Davies requested to merge tdavies__fix_ifo_is_gap_index into spiir-O4-EW-development

In the last MR !122 (merged) I misunderstood how write_ifo_mapping works.

In #89 I note that write_ifo_mapping converts enabled_ifo_id to available_ifo_id, and input_ifo_mapping converts from pad_id to enabled_ifo_id.

But I had the following:

for (int i = 0; i < state->nifo; i++) {
    int cur_ifo = state->input_ifo_mapping[i];
    int ifo_id = state->write_ifo_mapping[i];
    ...
}

In my defence, there's a lot of loops that do the following:

for (int i = 0; i < state->nifo; i++) {
    int ifo_id = state->write_ifo_mapping[i];
    ...
}

Whether it's right or wrong really depends on whether that loop is going over pad_id or enabled_ifo_id

i.e. what you get when you have
for (pad_id = 0, collectlist = pads->data; collectlist; g_slist_next(collectlist), pad_id++)
vs
for(int enabled_ifo_id = 0; enabled_ifo_id < nifo; enabled_ifo_id++).

But my change in the last MR is a clear contradiction. If the pads are connected in a different order to the standard HLVK, then cur_ifo and ifo_id wouldn't match. So it's now:

for (int i = 0; i < state->nifo; i++) {
    int cur_ifo = state->input_ifo_mapping[i];
    int ifo_id = state->write_ifo_mapping[cur_ifo];
    ...
}

I've also gone and fully renamed input_ifo_mapping to enabled_ifo_id so it's at least a Little less confusing. (enabled_ifo_id is HLVK order, but skipping disabled IFOs. So in an HLK run H is 0, L is 1, K is 2.)

Edited by Timothy Davies

Merge request reports