read starfile puts everything in properties

Question

read starfile puts everything in properties

brisvag opened this issue 4 years ago · comments

I don't think we should dump all the columns of a starfile into the properties of a particleblock.
At the very least, we should remove positions, euler angles and other already used columns!

alisterburt · Answer 1 · Fri Dec 18 2020 06:41:00 GMT+0800 (China Standard Time)

I thought about this when doing it and actually disagree. I initially thought the same, but then I thought about the possibility of a GUI which lets you explore the relationships between properties of a set of particle blocks (does CC correlate with defocus, does class assignment correlate to tilt angle) so thought these things could be useful

Lorenzo Gaifas · Answer 2 · Fri Dec 18 2020 17:11:56 GMT+0800 (China Standard Time)

Ok, that's fine, but we should defnitely get rid of duplicate data, no? Is there any reason to keep shifts?

alisterburt · Answer 3 · Fri Dec 18 2020 17:43:43 GMT+0800 (China Standard Time)

yeah definitely, seeing which particles shifted most during a refinement, seeing if that correlates to defocus, that kinda thing :)

…

On Fri, 18 Dec 2020 at 10:12, Lorenzo Gaifas ***@***.***> wrote: Ok, that's fine, but we should defnitely get rid of duplicate data, no? Is there any reason to keep shifts? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXYBYFSNAWDMN5F2CSKI3TSVMMGVANCNFSM4U6TV2GQ> .

Lorenzo Gaifas · Answer 4 · Fri Dec 18 2020 20:23:02 GMT+0800 (China Standard Time)

Ok, then we can keep it all! We should probably add some level of protection, to make sure none of these preexisting columns in the dataframe are overwritten by some arbitrary property by mistake

alisterburt · Answer 5 · Fri Dec 18 2020 20:43:45 GMT+0800 (China Standard Time)

Yeah that sounds like a good idea, not sure if this is possible as a dataframe/how to go about it though - do you have any ideas?

…

On 18 Dec 2020, at 13:23, Lorenzo Gaifas ***@***.***> wrote: Ok, then we can keep it all! We should probably add some level of protection, to make sure none of these preexisting columns in the dataframe are overwritten by some arbitrary property by mistake — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

Lorenzo Gaifas · Answer 6 · Sat Dec 19 2020 00:36:53 GMT+0800 (China Standard Time)

I think we can simply add a check on __setitem__ of the propertyblock that raises an error if you try to set those properties again? And we could hold a list of the properties created at instantiation, so only those ones are protected.