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

Add datasets for the brighter-fatter task #102

Merged
merged 2 commits into from Oct 11, 2018
Merged

Conversation

mfisherlevine
Copy link
Contributor

No description provided.

Copy link
Contributor

@r-owen r-owen left a 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.

Copy link
Contributor

@r-owen r-owen left a 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.

python: lsst.daf.base.PropertySet
tables: raw
template: brighterFatter_metadata/brighterFatter_metadata.boost
brighterFatterKernelNew:
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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 :)

description: "The per-amplifier gains, as calculated and used by the brighter-fatter task."
persistable: ignored
storage: PickleStorage
python: numpy.array
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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"?

Copy link
Contributor Author

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.)

Copy link
Contributor Author

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.

Copy link
Contributor

@r-owen r-owen Sep 19, 2018

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.

@mfisherlevine mfisherlevine force-pushed the tickets/DM-13293 branch 3 times, most recently from 76f1810 to 0bf4265 Compare September 6, 2018 15:36
Copy link
Contributor

@r-owen r-owen left a 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.

description: "The per-amplifier gains, as calculated and used by the brighter-fatter task."
persistable: ignored
storage: PickleStorage
python: numpy.array
Copy link
Contributor

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?

plotBrighterFatterPtc:
description: "Plots of the photon transfer curve, as made by the brighter-fatter task."
persistable: None
python: builtins.str
Copy link
Contributor

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?

Copy link
Member

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).

Copy link
Contributor Author

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.

@TallJimbo
Copy link
Member

Just saw this fly through my email: numpy.array is not a type, it's a factory function. numpy.ndarray is the type.

@mfisherlevine
Copy link
Contributor Author

Thanks Jim! I think all instances of those are gone now anyway though :)

Rename all classes, methods, instances and datasets to use full name
Update some python types in the dataset definitions
@mfisherlevine mfisherlevine merged commit 4fe4452 into master Oct 11, 2018
@timj timj deleted the tickets/DM-13293 branch August 17, 2020 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants