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

Issue/572/dataops redshift #596

Merged
merged 38 commits into from
Oct 16, 2023
Merged

Issue/572/dataops redshift #596

merged 38 commits into from
Oct 16, 2023

Conversation

m-aguena
Copy link
Collaborator

Closes Issue #572 .
In the end, most functions could just change their input to sigma_c instead of implementing z_src, z_src_info.

@coveralls
Copy link

coveralls commented May 25, 2023

Coverage Status

coverage: 100.0%. remained the same when pulling 783efe9 on issue/572/dataops_redshift into 8e97b4a on main.

@m-aguena m-aguena marked this pull request as ready for review May 26, 2023 12:07
@m-aguena m-aguena requested a review from hsinfan1996 May 26, 2023 12:07
Copy link
Collaborator

@hsinfan1996 hsinfan1996 left a comment

Choose a reason for hiding this comment

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

https://github.com/LSSTDESC/CLMM/pull/596/files#diff-b0d44342af6305abba113e4054806c63583e6cd75effe601d322c6e56709e6afR227
This line of the docstrings is not correct. Now is_deltasigma flag is removed from clmm.dataops.compute_tangential_and_cross_components

@m-aguena
Copy link
Collaborator Author

@combet @marina-ricci can one of you take a final look before I merge this? I would like a second pair of eyes on it since there are some API changes. The main changes here are on dataops/__init__.py and on galaxycluster.py (and their tests), most changes in the code are just replacing z_source->z_src. Thanks!

clmm/dataops/__init__.py Outdated Show resolved Hide resolved
clmm/dataops/__init__.py Outdated Show resolved Hide resolved
@combet
Copy link
Collaborator

combet commented Jul 13, 2023

@m-aguena - thank you for pinging me again on this PR. I took a look this morning and left a couple of comments above. Let me know what you think. Also I have a follow up question below (that could be addressed in a subsequent issue/PR).

You implemented this new approach for the functional interface only. The methods compute_galaxy_weights and compute_tangential_and_cross_components of the GalaxyCluster class still require the use_pdf and is_deltasigma flags. Should they be homogenized as well, i.e the user should have added a sigma_crit column beforehand and these methods would just check whether it exists or not (probably still keep a is_deltasigma flag) ?

@m-aguena
Copy link
Collaborator Author

@m-aguena - thank you for pinging me again on this PR. I took a look this morning and left a couple of comments above. Let me know what you think. Also I have a follow up question below (that could be addressed in a subsequent issue/PR).

You implemented this new approach for the functional interface only. The methods compute_galaxy_weights and compute_tangential_and_cross_components of the GalaxyCluster class still require the use_pdf and is_deltasigma flags. Should they be homogenized as well, i.e the user should have added a sigma_crit column beforehand and these methods would just check whether it exists or not (probably still keep a is_deltasigma flag) ?

@combet, thanks for the comments.

With regards to is_deltasigma, I agree it can be more friendly to have them on the functional interface too. The galaxycluster object currently computes and adds the sigma_c (or sigma_c_eff) column automatically if it is not there already when is_deltasigma=True. Is your suggestion to return an error when sigma_c (or sigma_c_eff) is missing and force the user to add it by hand?

The argument use_pdf does not make sense in the functional form as that information is already completely contained in the input sigma_c. I agree that it makes the API to be different from the galaxycluster object, but I do not see a clear solution. Maybe we could change the argument in galaxycluster to something like sigma_c_colname, and the options would be 'sigma_c' or 'sigma_c_eff'. What do you think?

@combet
Copy link
Collaborator

combet commented Jul 13, 2023

With regards to is_deltasigma, I agree it can be more friendly to have them on the functional interface too. The galaxycluster object currently computes and adds the sigma_c (or sigma_c_eff) column automatically if it is not there already when is_deltasigma=True. Is your suggestion to return an error when sigma_c (or sigma_c_eff) is missing and force the user to add it by hand?

Yes, I thought it would be more consistent with what we now have in the functional interface. i.e., the user need to make sure they have pre-computed sigma_c. For the OO interface, that would mean they have to explicitly use the add_critical_surface_density method, to ensure galcat has a sigma_c column. But there might be some side effects to do that, I haven't thought about it very long :) .

This could/should be kept for another issue/PR until we carefully think about it. But I think it would be nice to try to keep a good symmetry between the functional and OO interface.

@m-aguena
Copy link
Collaborator Author

m-aguena commented Jul 13, 2023

With regards to is_deltasigma, I agree it can be more friendly to have them on the functional interface too. The galaxycluster object currently computes and adds the sigma_c (or sigma_c_eff) column automatically if it is not there already when is_deltasigma=True. Is your suggestion to return an error when sigma_c (or sigma_c_eff) is missing and force the user to add it by hand?

Yes, I thought it would be more consistent with what we now have in the functional interface. i.e., the user need to make sure they have pre-computed sigma_c. For the OO interface, that would mean they have to explicitly use the add_critical_surface_density method, to ensure galcat has a sigma_c column. But there might be some side effects to do that, I haven't thought about it very long :) .

This could/should be kept for another issue/PR until we carefully think about it. But I think it would be nice to try to keep a good symmetry between the functional and OO interface.

@combet , I agree that this is a good idea, and also to put it in another issue so we can think more carefully about it and also to move on with this one. I just created issue #599 for it.

BTW, I just implemented the changes for the is_deltasigma argument in the functional interface.

@combet combet self-requested a review August 28, 2023 13:22
Copy link
Collaborator

@combet combet left a comment

Choose a reason for hiding this comment

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

Thanks @m-aguena. Playing the demo_compute_weights notebook gave errors in cell 9 and 13 because of the new _validate_is_deltasigma_sigma_c check. I think the calls in these cells now need to explicitly have a is_deltasigma=True.

@m-aguena
Copy link
Collaborator Author

is_deltasigma=True

Thanks @combet , good catch!
I updated the notebook now.

@combet combet self-requested a review August 29, 2023 12:19
Copy link
Collaborator

@combet combet left a comment

Choose a reason for hiding this comment

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

Thanks @m-aguena. All looks good to me now!

if is_deltasigma and sigma_c is None:
raise TypeError("sigma_c (=None) must be provided when is_deltasigma=True")
if not is_deltasigma and sigma_c is not None:
raise TypeError(f"sigma_c (={sigma_c}) be provided when is_deltasigma=False")
Copy link
Collaborator

Choose a reason for hiding this comment

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

raise TypeError(f"sigma_c (={sigma_c}) **should not** be provided when is_deltasigma=False")

@m-aguena m-aguena mentioned this pull request Sep 15, 2023
@m-aguena m-aguena merged commit bf1b9e3 into main Oct 16, 2023
1 check passed
@m-aguena m-aguena linked an issue Jul 5, 2024 that may be closed by this pull request
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.

Standardize redshift use in dataops
4 participants