Default Photometry File Requirements

[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.

[jdeast]

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 <#5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQT2B6WWILCKEJ6HGDJ5OTY2AVBHAVCNFSM6AAAAABFHCFNEKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDKOBUGAZTMOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rpoleski]

I'm for stating that BJD_TDB should be provided by the user and if they don't, then they introduce small level errors. These errors are important for 1 out of 10,000 ground-based events. For Roman data, I agree we will get BJD_TDB for free.

I've checked mm.MulensData.__init__(). Scientifically important keywords are:

• photometry format flux vs. mag,
• ephemeris,
• bandpass.

Above plus an additional detrending info, plotting info etc., for me suggests we should use some metadata rather than encode information in time stamps etc.

The disadvantage of providing fluxes instead of magnitudes are the limits on lens brightness and the properties of the source. Currently we use such constraints from a single dataset (the first one actually), but we could have it as a flag - use it for lens/source properties constraints or not. Such a flag once more suggests metadata.

The metadata could be passed at the top of the file, in a separate file (one per photometry file), or in the settings file (e.g., see these 2 lines).

We generally have not done de-trending so far.

[jenniferyee]

Ha! Here's an idea: We could write some tests!

[jenniferyee]

@jdeast
I propose you write a file of dates with columns for the different time systems: BJD_TDB, HJD, JD, etc. Span of 2 years.

Then, we can generate some trajectories using the different time systems and compare.

[jdeast]

Action item for @jdeast

Create file with 1 minute cadence for 2 years with 6 columns:
BJD_TDB, BJD_UTC, HJD_TDB, HJD_UTC, JD_TDB, JD_UTC,