Closed ih64 closed 4 years ago
Simon recommends we use the most recent weekly for the confirmed release.
Hi @kadrlica , thank you for the comments and suggestions! I'm going to change to the newest weekly, and add in your suggestions. I think you raised a good point, that the notebook is a bit long, probably too long. I'm wondering what your thoughts on how to proceed. Do you think there are pieces that can be removed or moved to an appendix? Or maybe cutting the slides a bit short, and doing something to what Meredith suggested and using it as a guide to lead participants through live coding? Thanks!
Assuming that the LSP is functioning well, I think that cutting the slides short and giving the participants a chance to go through the notebook together (with you as a guide, would be great)! @mrawls what do you think?
This is a very thorough notebook! But yes, too long for a 2-hour session :) Great work including so much explanatory text. I haven't looked at your slides, but I would propose the following as a skeleton schedule:
(1) Slides + everyone gets their stuff spawned, 15 min (2) Participatory live coding (starting with an empty notebook) through the first section ("Measuring the PSF"), 25 min (3) First exercise ("Make a plot showing the difference between the model PSF evaluatad at two different arbitrary points"), let participants work on their own and ask for help as needed, 10 min (4) Regroup where you demonstrate one way to solve the exercise, 10 min (5) 10-min break, theoretically at the 1-hour mark (6) Continue the participatory live coding, assuming it went well. If necessary, switch to just demoing running the full notebook while you talk through what is happening. Maybe leave 20 min at the end for another exercise + regroup (presumably this would be the "Make a plot showing how well aperture magnitudes agree with kron magnitudes" exercise, but if you do this, you'll need to explain what a kron magnitude is since the Lupton notebook doesn't explain it either.)
I suggest skipping "Altering the PSF for Detection" as well as "Erosion and Dilation on Footprints" altogether so you have a chance to get to Source Measurement at all. You might consider moving those sections to the end as bonus/appendix type optional sections.
Timing-wise, I don't think it's realistic you'll get to doing stuff with coadds, or forced photometry. (I also disagree with your statement "most of your science will come from detection, deblending, and measurement on coadds," that's certainly not true for everyone!) But that's why having a full notebook like you've made is an excellent resource, so folks who care about doing those things can pick up where you left off and continue on themselves.
Regarding the giant import block at the top. While I usually do something similar in notebooks for my own work, and it's fine to leave it as-is for reference, I suggest only importing what you need when you need it as you work through the lesson live.
One point of the technique I am proposing, participatory live coding, is to not go any faster than the folks who are seeing this for the first time can process new information. So you need to type everything yourself as you go, and explain what you are doing as if they are watching you do real work over your shoulder. The notebook you have made is a reference for you to have open in another window/screen (and it's available for learners if they want more context or fall behind). You should avoid copy-pasting since it is easy to grab text that you skip over explaining and it also makes you go much faster than the learners.
Hope that helps!
hi @mrawls, thanks for your comments and suggestions! I will make sure to incorporate them before I merge into master. I really like the schedule you have in mind, along with the idea of live coding. It reminds me of an instructor who goes through examples with a class at the blackboard, vs an instructor who distributes then reads aloud lecture notes.
pull request for session 5, detection deblending and source measurement