Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use single date for agasc1p8 promotion #333

Merged
merged 2 commits into from
Aug 22, 2024
Merged

Conversation

javierggt
Copy link
Contributor

@javierggt javierggt commented Jul 15, 2024

Description

This uses a single date for the AGASC 1p7-1p8 promotion. Note that this is based on the branch of #332. It leaves the logic to be able to change the AGASC catalog file when getting star catalogs.

The main reason for this is that, even though the promotion dates are configurable parameters, the result also depends on whether the 1p8 file is present in $SKA/data/agasc or not, which means the parameters are not enough to guarantee reproducible results. With that out the window, a single date is as good, with simpler code.

This PR has the lint errors that are fixed in PR #336.

Interface impacts

Testing

Unit tests

  • No unit tests
  • Mac
  • Linux
  • Windows

Independent check of unit tests by [REVIEWER NAME]

  • [PLATFORM]:

Functional tests

No functional testing.

@taldcroft
Copy link
Member

taldcroft commented Jul 15, 2024

@javierggt - see #332 (comment).

We can make a new PR like this after the promotion and when we have a definitive transition date. I do not agree that a single guess (and it really just a guess) at the transition date can be merged and promoted to flight now.

Base automatically changed from agasc-cone-fast-for-1p8 to master July 16, 2024 13:57
@javierggt javierggt force-pushed the single-agasc1p8-date branch 2 times, most recently from aaf9eb0 to 4196c4a Compare August 20, 2024 13:57
@javierggt javierggt force-pushed the single-agasc1p8-date branch from 4196c4a to 9d952e6 Compare August 20, 2024 14:04
@javierggt javierggt requested a review from taldcroft August 20, 2024 14:06
@taldcroft
Copy link
Member

@javierggt - please document your unit testing in the usual way.

@taldcroft
Copy link
Member

And go ahead and add PLR1730 to the ruff ignore list or # noqa them.

identification.
"""
with (
conf.set_temp("cache_starcats", False),
conf.set_temp("date_start_agasc1p8_earliest", "1994:001"),
conf.set_temp("date_start_agasc1p8", "2003:001"),
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see the utility in moving the date start for agasc1p8 for this test anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test just verifies that the change took place. In other words: by setting an early date, the test will use 1p8, when in reality it used 1p7, and the test will fail.

We can rewrite the test and make it better, but somewhere we still need to check that the switch works.

Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding "This test just verifies that the change took place." I don't see how the config set_temp to date_start_agasc1p8 for this test does that. I think, functionally, that is happening in
the other test, test_get_starcat_only_agasc1p8 .

Copy link
Member

Choose a reason for hiding this comment

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

@jeanconn - since the requested time frame in the line below is just before 2003:001, that means this is explicitly using AGASC 1.7 (as the test name implies).

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, but since the requested time frame is also before the standard config time for 1.8, the explicit set_temp doesn't show us anything.

Copy link
Member

Choose a reason for hiding this comment

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

It shows us that the code is not doing something silly like adding one day before comparing to the transition time. This is similar to other testing we've done of using a value that is purposely close to a limit.

Yes, not the strongest test in the world but the code is correctly testing both cases (before and after the limit). I think it is all good!

@jeanconn
Copy link
Contributor

"And go ahead and add PLR1730 to the ruff ignore list or # noqa them." or somebody approve and merge #336 first.

@javierggt
Copy link
Contributor Author

And go ahead and add PLR1730 to the ruff ignore list or # noqa them.

I left that unchanged, because Jean added the corresponding changes in the other PR. I saw no point in cherry-picking four commits, or making one commit that will cause conflicts.

@taldcroft
Copy link
Member

And go ahead and add PLR1730 to the ruff ignore list or # noqa them.

I left that unchanged, because Jean added the corresponding changes in the other PR. I saw no point in cherry-picking four commits, or making one commit that will cause conflicts.

Oops. OK understood.

Copy link
Member

@taldcroft taldcroft left a comment

Choose a reason for hiding this comment

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

This looks good to me. I explicitly checked that the transition date is good and that this will select obsid 43254 from AUG0524B as the first one with AGASC 1.8.

identification.
"""
with (
conf.set_temp("cache_starcats", False),
conf.set_temp("date_start_agasc1p8_earliest", "1994:001"),
conf.set_temp("date_start_agasc1p8", "2003:001"),
Copy link
Member

Choose a reason for hiding this comment

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

@jeanconn - since the requested time frame in the line below is just before 2003:001, that means this is explicitly using AGASC 1.7 (as the test name implies).

):
# Force AGASC 1.7 and show that star identification fails
# Force AGASC 1.8 and show that star identification fails
Copy link
Contributor Author

Choose a reason for hiding this comment

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

since we are going back and forth with this test, @taldcroft, did you see this change in the comment?

Just making sure I did not change it wrongly.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I saw this and agreed.

@javierggt javierggt merged commit 72bba92 into master Aug 22, 2024
2 of 4 checks passed
@javierggt javierggt deleted the single-agasc1p8-date branch August 22, 2024 14:36
@javierggt javierggt mentioned this pull request Nov 7, 2024
@javierggt javierggt mentioned this pull request Nov 19, 2024
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