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

Implement new abstract lephare functions #27

Merged
merged 7 commits into from May 13, 2024

Conversation

raphaelshirley
Copy link
Collaborator

@raphaelshirley raphaelshirley commented Apr 30, 2024

we are trying to move most of the lephare code to lephare itself.

Closes #24
Closes #30

This will also involve changes the Params to take lephare configs to overwrite values

Do we want to run get data in the info stages?

What minimal functionality do we want to have in place prior to the in person meetings?

We would like the option to run autoadapt either on the inform training set or on each chunk

Problem & Solution Description (including issue #)

rail_lephare is running but we decided it would be neater to move some of the code to lephare in abstract functions rather than have details exposed to rail_lephare. this involves two new functions prepare and process in lephare which should be the totality of what would be run in rail_lephare.

Code Quality

  • My code follows the code style of this project
  • I have written unit tests or justified all instances of #pragma: no cover; in the case of a bugfix, a new test that breaks as a result of the bug has been added
  • My code contains relevant comments and necessary documentation for future maintainers; the change is reflected in applicable demos/tutorials (with output cleared!) and added/updated docstrings use the NumPy docstring format
  • Any breaking changes, described above, are accompanied by backwards compatibility and deprecation warnings

We would liek the option to run autoadapt either on the inform training set or on each chunk
@raphaelshirley
Copy link
Collaborator Author

We might want to run the get data which would also close #12

Further we should add the autoadapt stage to the inform stage. In general we will not have access to spectroscopic redshifts in the estimate stage.

Raphael Shirley added 3 commits May 7, 2024 20:16
Still to implement autoadapt in inform stage. We need to convert the config key map to a dictionary for it to be pickled. It can easily be converted back
by looping over the keys and replacing the values with lephare.keyword objects
@raphaelshirley
Copy link
Collaborator Author

I left get data out of the inform stage so it must be run outside of rail.

Raphael Shirley added 3 commits May 8, 2024 20:36
This depends on the changes to DataManager in lephare being merged and published. There may be situations where the user wants to default to imed runs but currently they have to do this via the name of the inform stage
@raphaelshirley
Copy link
Collaborator Author

I think the tests are failing because the lephare version doesn't yet have the change to create_new_run which we now use to set the run equal to the informer name.

@drewoldag
Copy link
Collaborator

Yep, that makes sense.

Copy link
Collaborator

@drewoldag drewoldag left a comment

Choose a reason for hiding this comment

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

Overall I think this looks just fine. I'm sure there are corner cases and issues that we haven't uncovered yet, but I would advocate for moving to get it in to main so that we can all experiment with it together.

self._create_filter_library()
self._create_sed_library()
self._create_mag_library()
lp.prepare(self.lephare_config)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
lp.prepare(self.lephare_config)
lp.prepare(self.lephare_config,
star_config=self.config["star_mag_dict"],
gal_config=self.config["gal_mag_dict"],
qso_config=self.config["qso_mag_dict"])

dict(
lib_ascii="YES",
lp.read_config(
"{}/{}".format(os.path.dirname(os.path.abspath(__file__)), "lsst.para")
Copy link
Collaborator

Choose a reason for hiding this comment

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

I suppose this is fine - but I don't think I've seen the default value being defined as a line of code like this. i.e. lp.read_config(...). The way this was originally seemed more intuitive. With self.lephare_config = lp.read_config(self.config["lephare_config_file"]) specified in the __init__ method.

os.environ["LEPHAREDIR"] = lepharedir
if lepharework is not None:
os.environ["LEPHAREWORK"] = lepharework
importlib.reload(lp)
Copy link
Collaborator

Choose a reason for hiding this comment

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

If this is working, then that's fine, I don't think it's worth poking a bear. But I really do wish we had a way around this that didn't require it.

@drewoldag drewoldag merged commit 6de7e74 into main May 13, 2024
4 checks passed
@drewoldag drewoldag deleted the issue/24/implement-new-abstracted-lephare-functions branch May 13, 2024 21:54
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.

Fix hardcode magnitude column names Implement new abstracted lephare functions
2 participants