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
Add datasets for the brighter-fatter task #102
Conversation
8fbaafa
to
25fb522
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per my comment on Jira: I suggest expanding bf -to brighterFatter in these names. It makes the names clearer. It also fixes the collision with the old kernel without the need for "New" as a temporary suffix.
0b74bf9
to
9453ebc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions. I suspect I looked at this before you had time to updated it to match changes in cp_pipe.
policy/datasets.yaml
Outdated
python: lsst.daf.base.PropertySet | ||
tables: raw | ||
template: brighterFatter_metadata/brighterFatter_metadata.boost | ||
brighterFatterKernelNew: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need the "New" here? I thought the old name that HSC used was "bfKernel" and that "brighterFatterKernel" had not been used before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack. I agree that it has not been used, and could be used in that way in principle. However, I think that while two things coexist, it is nice to have the added disambiguation of the "new" on the end, as things are confusing enough already, plus this saves having to change it. I think that once the old one is deliberately removed that we then update the name so that the One True Kernel be {{brighterFatterKernel}} as you suggest. Does that sound OK for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I worry that it is disruptive to have to change the name of a dataset. However, as long as the dataset name is purely internal (does not affect the name or path of persisted data) then it's probably not too bad. Go ahead.
If the dataset name affects the path or file name of the persisted data then I would be very uncomfortable changing the name later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, our OOB discussion persuaded me to just change it. Doing so now :)
policy/datasets.yaml
Outdated
description: "The per-amplifier gains, as calculated and used by the brighter-fatter task." | ||
persistable: ignored | ||
storage: PickleStorage | ||
python: numpy.array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this a dict of amp-or-detector-name (as a str): gain (as a float)? Though as I mentioned in cp_pipe review, if you made it a simple struct-like class then you could store the level as an attribute. Since you are using pickle storage anyway, that does not seem to be much of a hardship.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely the python:
entry should be changed to the type of the new custom class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm confused, but it's also all sorted. I thought that this was for the kernels, not the gains. I made a class for that, and did change the python type. This is just a dict, and I have also changed it to not be a lie here. So, unless you dislike that and think this should also be a thin class (which I don't agree with, as the gains are, by definition, at the amp level, so a dict is fine), then this is all nicely done, with the nice idea expressed here applied to the kernels, not the gains.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I amended the commit to save squashing later, so if you look, look here, or beware the force-push, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The python type says "numpy.array" but apparently it's a dict, so surely it should be "builtins.dict"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, that's outdated, it does now say dict
. However, I just did a plain dict
rather than buitlins.dict
. Does that matter? (Obviously I don't mind changing it, this is more for my education.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You were, of course, right, I've changed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect "builtins" is not necessary (as you say) -- if it works, leaving out "builtins" is best. That said, if omitting the entry or setting it None works then I'd go with that.
76f1810
to
0bf4265
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two questions. Once you have updated, if necessary, feel free to merge.
policy/datasets.yaml
Outdated
description: "The per-amplifier gains, as calculated and used by the brighter-fatter task." | ||
persistable: ignored | ||
storage: PickleStorage | ||
python: numpy.array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely the python:
entry should be changed to the type of the new custom class?
policy/datasets.yaml
Outdated
plotBrighterFatterPtc: | ||
description: "Plots of the photon transfer curve, as made by the brighter-fatter task." | ||
persistable: None | ||
python: builtins.str |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is str
the right type for MatplotlibStorage? That seems a bit strange. If you are saying "arbitrary binary data" then wouldn't builtins.bytes
be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you can set it to None
or just leave the key out, that would be best (but I don't know if it will work).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just confirming that None
does indeed work fine (@TallJimbo) , and have changed here.
20ca5d7
to
a7e5382
Compare
a7e5382
to
0fa7f4c
Compare
Just saw this fly through my email: |
0fa7f4c
to
86ec3a9
Compare
Thanks Jim! I think all instances of those are gone now anyway though :) |
86ec3a9
to
3435ac2
Compare
3435ac2
to
06032ae
Compare
Rename all classes, methods, instances and datasets to use full name Update some python types in the dataset definitions
06032ae
to
4fe4452
Compare
No description provided.