โจ I'm pretty good with Python and LaTeX, with a vague grasp of C, C++, Javascript, and a few other languages.
๐ฑ Iโm currently learning about GPU-accelerated computing.
๐๏ธ Iโm open to collaborate on pretty much anything.
Fun facts about me
I'm a huge fan of both classic and modern fantasy/sci-fi. From Stoker to Sanderson, Wells to Weir, I love it.
I'm embarrasingly afraid of bees, wasps, and hornets (even though I've never been stung).
I've never broken a bone, but I have knocked out a few teeth.
I made an RC car from scratch for my 2-year old. It took me the better part of a summer to design and build it. It took him the better part of 15 minutes to break it. I'd do it again in a heartbeat.
I released an EDM album once. I'm proud enough of it to mention it here, but not proud enough to give you the information to go find it.
Right now most of the function calls take just the config dictionary as a parameter. That abstraction is nice for concision, but prevents the functions from being useful outside of the rigid framework of my main working routine. It would be more useful to have the functions take actual parameters (which can be read in by the config dict). Then they could be cherry picked by anyone else wanting to use parts and pieces of this software.
Many of the parameters are highly unintuitive, so the user would benefit from rapid feedback. Probably a good idea to include more plots and printed output so the user doesn't need to just guess blindly.
It would be easier to run the spec macros if they were all in the experiment directory. However, they will have to be renamed so that they don't overwrite each other (something like scan0023grain001.mac or something)
Finding all the peaks in every frame makes it harder to differentiate which peaks belong together. A single peak which appears in N frames is flagged N times, regardless of whether it's actually "peaking" at that position. This makes it hard to determine the boundaries of a single grain, and causes fading peaks to spill into the spaces of other grains.
It would be better to mark each peak based on where it is brightest. This would require a 4D peak-finding optimization, and would probably need a slightly different image pre-processing routine.
When we do a Laue scan using the px/py motors, everything gets stretched out on the map because it's trying to compensate for an angle that isn't actually needed.
When the distance is calculated between the observed peaks and the forward simulation, the result is about an order of magnitude larger than expected. As far as I can tell, the actual indexations are correct; they match up with those found in the old version of the code.
It would be great if there were a way to check whether a certain command would produce valid results. In other words, it would disable a button if any of the following are true:
An upstream config parameter has been changed.
A command is run at least two levels upstream.
I can't think of any other reasons right now. This is a low-priority task, but a good one to keep in the back of my mind.