jdeast
commented
7 months ago For MMEXOFAST, we need to choose a standard for photometry files, e.g. flux vs. magnitude. My opinion is that we should require:
Date (HJD), Flux, Flux Error
Date in HJD because most groups already report their dates that way.
Ugh. What timing precision do we need over what timescale? Even definitively answering that question seems harder than switching to BJD_TDB.
Common algorithms to compute HJD are inaccurate at the 1s level, and the HJD is fundamentally internally inconsistent at the 50 millisec / month level. I'm guessing that doesn't matter, even at the precision of WFIRST, but if people use a mix of reference frames, that's probably important (8 seconds). Note the light travel time from earth to WFIRST is 5 seconds, so if people compute their own HJD from the raw spacecraft timestamps, there's a good chance they'll introduce an additional 5 second error.
Do we know what WFIRST is going to report? I'd be surprised (disappointed) if it weren't BJD_TDB. Also, if we want to broaden the tent for new mircolensers, using the standard the rest of the exoplanet community uses is a good start. I don't think we'll ever have a better opportunity to lead the ulensing community into 1991 (when HJD was deprecated by the IAU).
At a minimum, we should be explicit about the time standard (TDB vs UTC), not just the reference frame (HJD vs BJD). Again, the internal inconsistencies probably don't matter, but a mix (1 minute) probably does.
Fluxes because we usually use difference imaging for the photometry, which means that the measured values can sometimes be negative. If we use magnitudes, this means that there needs to be a zeropoint and either some fraction of the negative fluxes will get eliminated (because you can't take the log of a negative number) or the magnitudes will be stupid (because your zeropoint is so large to accommodate the negative values that the dynamic range of the real flux changes is too small).
I support flux instead of mag for the reasons you state, and for consistency with transit files. Are these absolute fluxes? Normalized? We'll fit the baseline flux, so we need a way to get a good default guess for that baseline -- either force the user to supply it close to some value (1?), or compute it. I don't have a strong opinion on which, but maybe you have a good idea of whether it's easier to make a reasonable global baseline flux value (minimum reported flux?) or make the user supply normalized LCs.
Do you ever do detrending? For transit LCs, I allow an arbitrary number of additional columns of things to detrend against.
We could also consider including an ephemeris as additional (optional?) columns, though that would get messy if we also did optional detrending.
Jason
@rpoleski https://github.com/rpoleski @jdeast https://github.com/jdeast
I await your counter-arguments.
— Reply to this email directly, view it on GitHub https://github.com/jdeast/EXOZIPPy/issues/5, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQT2B6WWILCKEJ6HGDJ5OTY2AVBHAVCNFSM6AAAAABFHCFNEKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDKOBUGAZTMOA . You are receiving this because you were mentioned.Message ID: @.***>
rpoleski
jenniferyee
For MMEXOFAST, we need to choose a standard for photometry files, e.g. flux vs. magnitude. My opinion is that we should require:
Date (HJD), Flux, Flux Error
Date in HJD because most groups already report their dates that way.
Fluxes because we usually use difference imaging for the photometry, which means that the measured values can sometimes be negative. If we use magnitudes, this means that there needs to be a zeropoint and either some fraction of the negative fluxes will get eliminated (because you can't take the log of a negative number) or the magnitudes will be stupid (because your zeropoint is so large to accommodate the negative values that the dynamic range of the real flux changes is too small).
@rpoleski @jdeast I await your counter-arguments.