Closed taylorbell57 closed 1 year ago
@erinmmay may have some thoughts on this.
I thought some more on this today and realized multi-dimensional arrays won't work well as there's no guarantee that the time axis for different observations will be the same length, and it may get pretty messy or inefficient to pad arrays with NaNs or whatever. I think either keeping the flattened arrays or using lists of lists may be better option.
I have this implemented already! Different time arrays was certainly the most annoying part 😅 It's on my to-do list to open a PR (hopefully) next week, but happy to send my code to you sooner if you're curious how I made it work @taylorbell57. I did maintain the flattened arrays bit, but agree that a modification may be useful. The one thing I didn't implement is the ability to have multiple versions of a shared parameter (like if you have two G395H visits and want each detector to have it's own limb darkening that is the same across visits), so right now a fit parameter is either the same for all light curves or different for all light curves.
@erinmmay amazing, I'm really glad to hear that! I'm really time constrained this week, so getting this implemented from scratch quickly was going to be tough for me. If you're able to point me to a branch somewhere where I can quickly try hacking it into my local working branch so that I can use it before we get it properly merged, that'd be amazing
I've pushed my changes to my fork: https://github.com/erinmmay/Eureka
(FYI, there is no documentation, things aren't done optimally, and I'm sure there are bugs. It's also based off an old version of S5 and to get this to you quickly I just put it in my fork as is instead of merging it with the current version, so ignore any anything it says I removed, I'll fix that when I go do the PR.)
Thanks so much!
FYI, @erinmmay I've copy-pasted your code into the jointfits branch for my temporary, hacky fits for a meeting tomorrow morning. I don't mean to submit this branch as a PR because GitHub has lost track of what edits you'd made since I copy-pasted your code, and I don't want to claim I did all that work. But if you compare my branch to yours (there's some nice, automated ways of doing this like meld
), you can get some good ideas as to what changes will need to be made in order to get things merged properly.
Instrument
Light curve fitting (Stages 4-6)
What is your suggestion?
As of right now, we can in theory do joint fits with shared parameters across different wavelengths from a single visit from one instrument. In practice this is not really feasible with lsq/emcee/dynesty, but I believe it should be possible with the new exoplanet/nuts methods implemented in PR #492. Beyond that, it'll be really great to be able to do joint fits of data from different visits with the same instrument (aka repeated observations) or from different instruments/detectors (e.g. NIRCam SW+LW or WFC3+NIRSpec or maybe even Spitzer+NIRCam someday).
We can likely do something similar to what is currently done for "shared" fits, but we'll need ways of ingesting multiple S4 save files; after that, we can likely just treat them exactly like different wavelengths (although we might want to do something a bit fancier to have helpful plot titles and filenames rather than ch13 being the last channel from MIRI/LRS visit 1 and ch14 being a different instrument or visit altogether). I think we can likely also keep things neater than the currently implemented "shared" code by using multi-dimensional numpy arrays rather than their flattened equivalents, and this might be a good time to pursue that. Perhaps we can have one axis for time, one axis for wavelength, and one axis for different visits and/or instruments.
I'm working on a set of repeated photometric observations of TRAPPIST-1b for which I want to perform a shared fit, so I'll likely being working on this over the next week or two on the branch jointfits. Any thoughts or contributions are certainly welcome
Code of Conduct