Skip to content

Conversation

@nicHoch
Copy link
Collaborator

@nicHoch nicHoch commented Dec 5, 2025

No description provided.

@nicHoch nicHoch requested a review from samaloney December 5, 2025 12:34
@nicHoch nicHoch self-assigned this Dec 5, 2025
@nicHoch nicHoch added this to the v1.7.0 milestone Dec 5, 2025
@codecov-commenter
Copy link

codecov-commenter commented Dec 5, 2025

Codecov Report

❌ Patch coverage is 81.48148% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.04%. Comparing base (3ae9671) to head (9b9c9dc).
⚠️ Report is 11 commits behind head on master.

Files with missing lines Patch % Lines
stixcore/products/product.py 86.95% 6 Missing ⚠️
stixcore/products/level1/quicklookL1.py 20.00% 4 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (3ae9671) and HEAD (9b9c9dc). Click for more details.

HEAD has 1 upload less than BASE
Flag BASE (3ae9671) HEAD (9b9c9dc)
2 1
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #447      +/-   ##
==========================================
- Coverage   72.23%   67.04%   -5.19%     
==========================================
  Files          78       76       -2     
  Lines        8085     8136      +51     
==========================================
- Hits         5840     5455     -385     
- Misses       2245     2681     +436     

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@samaloney samaloney left a comment

Choose a reason for hiding this comment

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

I'm not sure allowing operations in different time systems is a good idea. A product should either have time in OBT or UTC and the conversion should only be done once in the from_level0 or similar methods?

All products (>L0) will always have obt_timerange from products will have an utc_timerange but only if the time sys in header is UTC and not sure supporting on the fly conversion is a good idea because the spice kernel dependence.

This aren't blocker just thoughts

Comment on lines 195 to 199
assert p.exposure == p.data["timedel"].as_float().min().to_value("s")
assert p.max_exposure == p.data["timedel"].as_float().max().to_value("s")
else:
assert p.exposure == p.data["timedel"].min().to_value("s")
assert p.max_exposure == p.data["timedel"].max().to_value("s")
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd avoid asserts like this for use if and raise a specific exception

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we test if the xxx_exposure property is working for L1 and L0 files in the same test.
both have different internal timing systems: so i need the if case or we split it up into 2 separate tests.

if "TIMESYS" in pri_header and pri_header["TIMESYS"] == "UTC":
try:
offset = Time(pri_header["DATE-OBS"])
except Exception:
Copy link
Collaborator

Choose a reason for hiding this comment

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

very broad exception

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

narrowed down

if "timedel" in l1.data.colnames and isinstance(l1.data["timedel"], SCETimeDelta):
l1.data.replace_column(
"timedel",
l1.data["timedel"].as_float(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this an int to start with?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no here it is a SCETimeDelta and the as_float() does the conversion to seconds

@@ -524,10 +537,22 @@ def __init__(

@property
def scet_timerange(self):
Copy link
Collaborator

Choose a reason for hiding this comment

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

For this specific case we always have OBT-BEG and OBT-END so maybe this should use those?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

.obt_beg and end are only existing properties for LB products

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes but we always have the headers all L0+ fits files have OBT_BEG and OBT_END

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes but only if it comes from FITS read or after it was just writen out to fits. Some intermediate states of products will not have valid header data. Frech created with init or splited into days voa to_days ....

Comment on lines 954 to 955
(self.data["time"][0] - self.data["timedel"][0] / 2).datetime,
(self.data["time"][-1] + self.data["timedel"][-1] / 2).datetime,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the .datetime really needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no: removed

@nicHoch
Copy link
Collaborator Author

nicHoch commented Jan 29, 2026

i agree that it is not ideal to provide some of the on the fly conversions. The auto converting most of the time (and if proper used never) will not happen as our process steps will do this explicit.

In general this L1 product could have state depended time systems and i think it would be bad experience if the properties will raise an exception if used

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.

3 participants