Closed jfcrenshaw closed 1 year ago
Please help:
numpy
.enum
already when you check the available instrument. Try to use the existed enum
if possible: https://github.com/lsst-ts/ts_wep/blob/develop/python/lsst/ts/wep/Utility.py#L42-L47Thank you!
@teweitsai I believe I have satisfied all of the points above, with one exception:
- Put the parameters into the policy directory if possible.
I looked in the policy directory, but I'm not really sure what to do here. Are these all yaml files specifying defaults? Could you give me a little advice on what to do here?
Thanks for your review!
You can create a new yaml
file or put the parameters into existed yaml
file (if there is one that you think it is a good place). You can add comments to explain the new parameters. Thanks!
Is this what you were thinking? There is only one parameter that can be defaulted.
Or were you saying I should put the conversion factors in the yaml? https://github.com/jfcrenshaw/ts_phosim/blob/73f4f066e353cbc70dea2625636ae3b76a071dda/python/lsst/ts/phosim/utils/ConvertZernikesToPsfWidth.py#L93-L170
I will put all the conversion factors in the yaml
instead of hard-coding them. The camType
is not the parameter but the argument of function (or the optional
argument if you like). In addition, for the enum
value, it is better to use the name
instead of value
in the yaml
file. Otherwise, it is hard to understand what it is and what might be the available options.
Okay the policy file now contains the conversion factors.
Assuming the CI passes again, is this ready to merge?
No. You need to put the "Reviewers" to ask for the review of pull request. Then, after the approve, you can merge the pull request. What I did is called the "comment" instead of "review".
In addition, it is better to rewrite the git history (to organize the comments) before asking the review or pull request.
I cannot request reviews in the "Reviewers" field above because I do not have write access to this repo. But I have sent a slack message to @jbkalmbach asking him to review.
One more comment now that I think about it some more. Do we want to change the file name to a more general name for Zernike analysis in case we want to add some more code in there to calculate metrics like we talked about at the last AOS meeting?
One more comment now that I think about it some more. Do we want to change the file name to a more general name for Zernike analysis in case we want to add some more code in there to calculate metrics like we talked about at the last AOS meeting?
OpdMetrology.py
, e.g. calcPSSN
, calcFWHMeff
, calcDm5
. Maybe instead, this conversion should be moved there too? I'm just not sure how the OpdMetrology
class gets used, since the docstring is pretty bare.Yeah, it does look like if we make some sort of metrics utility we'll want those there too. So maybe let's just leave things the way you have them now and think about this some more after we start to converge on what the most useful metrics are as we go forward.
@jbkalmbach sounds good. I will squash the history again, and then merge this addition.
I mentioned unifying the metrics as a future goal to Andy. He said he expects ts_phosim
will be retired as we move away from phosim
, and that the important pieces will need to be moved over to other packages. So maybe that is the stage where we should unify the metrics into some common framework.
Superseded by PR #72
Added function to convert Zernike amplitudes (in microns) to their quadrature contributions to the PSF FWHM (in arcseconds). This is to address ticket DM-33115.
I wasn't exactly sure where to put this, so I put it in its own module/function in
utils
. I figured it would be good to open a pull request with the implementation in place, and someone more familiar withts_phosim
could tell me if and where to move it.