Map product for Imap-Lo - #3354
Conversation
|
|
||
| # Empirical offset [degrees] added to the measured pivot angle when | ||
| # projecting a look direction onto the RAM direction. | ||
| PIVOT_RAM_OFFSET: float = 4.0 |
There was a problem hiding this comment.
This is a magic value that Nathan is using. If this looks like a dangerous hack, I can open up an issue on this so I can fix it in an upcoming iteration.
| 0.787, | ||
| 1.821, | ||
| ] | ||
| GEO_FACTOR: ClassVar[list[float]] = [ |
There was a problem hiding this comment.
These used to be in ancillary files, but only the removed code was using them. I'll open an issue so that these values are obtained from (existing) ancillary files.
| # Default background-rate thresholds [counts/s] when the pivot angle matches no | ||
| # spec in PIVOT_ANGLES, or the matching spec has no pivot-specific value. | ||
| # Currently set to nominal values for the 90-deg pivot angle. | ||
| THRESHOLD_BG_RATE_RAM_DEFAULT: float = 0.028 |
There was a problem hiding this comment.
Default background rate thresholds have changed to match those used at 90 deg pivot, as per the dropbox code.
| sky_map.max_epoch = max(sky_map.max_epoch, int(met_to_ttj2000ns(gt_end.max()))) | ||
|
|
||
|
|
||
| def _dps_spin_angles() -> np.ndarray: |
There was a problem hiding this comment.
I couldn't find an existing function I could use for this directly. Perhaps I can add one to the library and call it here.
|
The plan is still to create the l1c, correct? Just not needed for the map production? |
2 participants
Closes #3349
The Imap-Lo L2 maps now no longer derive from the
l1cpsets (the Lo team and Nathan are fully aware of this and have endorsed this path forward), but froml1bproducts likehistrates,goodtimes, andbgrates.The approach in
lo_l2now is a direct counterpart of the offline processing that the team has been doing, and has been approved by the team as being broadly correct. A more systematic validation will come soon when this code is available upstream and everyone can access/generate these products. Hopefully these tweaks will be minor.Since the original
lo_l2code was written a while ago and never exercised or validated, I found little need to keep it in here - I can always go back to the old code and re-introduce parts of it (sputter correction, bootstrap correction etc). as I incorporate those corrections incrementally. For now, perhaps this PR is best reviewed as a new implementation instead of an incremental update (i.e. looking at the whole file instead of a diff against the old one). I think seen in this light, the whole approach this code is taking is quite straightforward.Unlike the previous attempt, I'm now using
compute_pointing_directionsfrom the library as well asRectangularSkyMap. Any remaining code redundancies you see are a result of my own ignorance of what else is out there inimap_processing, rather than an attempt to rush things!