You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What does the jdmin column actually store?
Should it be the discovery date or the oldest date in a ZTF alert packet?
I've noticed this when using filters to find short lived transients. Filtering on say, jdmax-jdmin < N days, finds objects with loads of light curve history before jdmin.
We're also trying to search for more long-lived transients by doing jdmax-jdmin > N days in the filter, but noticed that for ZTF20abrbeie the jdmin is only 30 days ago, but the light curve has more than 800 days of history.
Without a true date of discovery or earliest detection it is impossible to do some types of archival searches in Lasair.
The text was updated successfully, but these errors were encountered:
jdmin is the earliest of the candidates that are included with the alert from ZTF. That alert has 30 days of lightcurve, so jdmax - jdmin cannot be more than 30 days. When we built Lasair we assumed it would be about rapid transients, not about archival searches. There has been a lot of discussion about this at Lasair meetings, and we have petitioned Rubin to include the true number -- see here
What does the
jdmin
column actually store?Should it be the discovery date or the oldest date in a ZTF alert packet?
I've noticed this when using filters to find short lived transients. Filtering on say, jdmax-jdmin < N days, finds objects with loads of light curve history before jdmin.
We're also trying to search for more long-lived transients by doing jdmax-jdmin > N days in the filter, but noticed that for ZTF20abrbeie the jdmin is only 30 days ago, but the light curve has more than 800 days of history.
Without a true date of discovery or earliest detection it is impossible to do some types of archival searches in Lasair.
The text was updated successfully, but these errors were encountered: