Skip to content

Fix reindexing of fixed tones#1625

Open
tpsatt wants to merge 4 commits into
masterfrom
fixed-tone-mapmaking
Open

Fix reindexing of fixed tones#1625
tpsatt wants to merge 4 commits into
masterfrom
fixed-tone-mapmaking

Conversation

@tpsatt

@tpsatt tpsatt commented Apr 29, 2026

Copy link
Copy Markdown
Contributor

Loading an observation with fixed tones (special_channels) and reindexing was broken because multiple UFMs (stream_ids) could share the same band/channel numbers. This fixes that, and fixes a bug where NaNs were not propagated in the reindexing.

@mhasself

Copy link
Copy Markdown
Member

@tpsatt Thanks for working this out. Since unit tests on this kind of thing are pretty tricky, can you mention in the PR comments here what obs_id(s) you used for testing?

@tpsatt

tpsatt commented Apr 29, 2026

Copy link
Copy Markdown
Contributor Author

@mhasself Good point. For testing, I was using obs_id obs_1750380829_lati6_111 which had fixed tones enabled. Before the patch, the data beyond just signal got scrambled after reindexing since the channel matching returned multiple results due to not using stream_id. Now, everything lines up, and all of those fields go to empty strings, NaNs, or anomalously large/small ints for fixed tones (which lack that info).

@ykyohei ykyohei left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me, and I tested to run update_det_cal site-pipeline with this branch and confirmed that there is no problem, just in case.

This reindexing was used for update_det_cal with hwpss_subtraction for SATs. update_det_cal should not have had issues because it analyzes oper books that is saved per wafer.

Comment thread sotodlib/core/axisman.py Outdated
@@ -877,7 +877,7 @@ def reindex_axis(self, axis, indexes, in_place=True):
shape.append(s)

new_v = np.empty(shape, dtype=v.dtype)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use zeros, or zeros() - 1, instead of empty here?

The idea that "empty" will always produce garbagey results that are easy to distinguish from "good numbers" is not accurate. Sometimes "empty" will give you 0, or -1, or other normal numbers.

So I'd rather we have the predictability of a simple result here, such as zero or -1 for integers, than to rely on whatever garbage is given by empty.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I've just pushed a change which sets floats to NaN and ints to -1. I think this is minimally invasive since many bad float values in "real" data (e.g. R_ns) are already NaNs, and bad ints (e.g. bias lines) are -1s. This also preserves strings being ''.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Given that new_v is now simply replaced in the int and float specializations, you can skip the .empty creation here and instead do a .zeros in an "else" clause for the type checks.

I really don't like leaving .empty arrays lying around! Non-determinism.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes we have strings in the data, so I like that empty becomes an empty string. When I tried to put a case in for this, it broke (I think because of how numpy encodes strings, I'm not an expert here)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.zeros has always worked on strings for me ... also returns an array of ''s ... What's the dtype that fails?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point now. I've updated this and committed. Thanks!

@tpsatt

tpsatt commented May 1, 2026

Copy link
Copy Markdown
Contributor Author

@ykyohei should probably review again since I've tweaked the reindexing function

@tpsatt tpsatt requested a review from ykyohei May 1, 2026 04:14
@tskisner

tskisner commented May 5, 2026

Copy link
Copy Markdown
Member

The unit test failures here are due to an interplay between the latest toast wheels and the so3g wheels. I'm debugging in a separate PR.

@ykyohei

ykyohei commented May 7, 2026

Copy link
Copy Markdown
Contributor

I tested update_det_cal again and I didn't find problem.

@tpsatt

tpsatt commented Jun 19, 2026

Copy link
Copy Markdown
Contributor Author

Is this ready to merge now that #1629 has converged? (@tskisner)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants