RoyWilliams
commented
5 years ago From Matt Nichol:
Looks great! A few initial thoughts:
— running the example queries is mostly clear and straightforward. I did notice that it breaks if I add LIMIT to the query, presumably because of the hard-coded LIMIT 1000. Maybe this doesn’t matter; I don’t know whether people would have any reason to want to specify manual limits.
— The examples named “classified as SNe” and “recent SNe” are slightly misleading in my view. Not a problem for dev version, but when you’re ready to put this on the main page, I would say that a sherlock ‘classification’ means “likely SNe”. And ‘recent’ sounds like a recent discovery (i.e. all candidates within an object are recent), whereas the query returns recent detections (any candidate that is recent regardless of how long the object has been known). This leads me on to the next point…
— Most SN-enthusiasts will be primarily interested in young SNe, i.e. that exploded recently and have rising light curves. Here’s a simple query that returns likely SNe first detected within the past week (using latest mags and mag ranges to quickly assess whether they are brightening or fading). Most of the objects returned do look like young SNe. I think this or something similar would make a good baseline query for SN folk:
SELECT objectId, jdmin-2400000.5 as first_discovered, jdmax-2400000.5 as last_seen, ncand, latestgmag, maggmax, maggmin, latestrmag, magrmax, magrmin FROM objects WHERE jdmin > (unix_timestamp(now())/86400 + 2440587.5) - 7 AND sherlock_classification = 'SN' ORDER BY jdmax DESC
— For sherlock info, I’m a bit confused about the redshift. The table on each object page gives “photoZ”, but the schema page only lists “z” under the sherlock_crossmatches table. If this z can be either photometric or spectroscopic (depending on the catalog or specific object) it’s important to differentiate (and spec should aways take priority). I remember talking about this at the Lasair meeting, and I think Dave said that sherlock does default to spec if available? If so, the sherlock_crossmatches table needs to keep track of phot or spec (e.g. with another column called something like “z_type”) and this should also be displayed on the object pages
— I also notice on many object pages that the redshift given in the bullet points (to calculate absolute magnitude) often differs a bit from that in the crossmatches table right under it. e.g. https://lasair-dev.roe.ac.uk/object/ZTF18acdzzyf/, https://lasair-dev.roe.ac.uk/object/ZTF18aceyjfx/
— minor point: each non-detection appears to be listed multiple times in the candidates table (i.e. identical times and limiting mags). I don’t know whether this is because of multiple exposures in a row, but it’s suspicious that the times are exactly the same.
smarttgit
tms-epcc
I would really appreciate a close look from you of the new Lasair query page that Ken and I built last week. We now have a truly freeform query mechanism. It is available on the dev system (username: flame, password: !flame). Please look at:
(1) Copy/paste some examples into the query box and click Submit Query. Is it clear what is happening?
(2) The text of query page itself https://lasair-dev.roe.ac.uk/objlist/. Are there other notes or caveats to include?
(3) The Example Queries on the same page. (Some stolen from Joe and Matt Jupyter notebooks.) It would be great to have a fuller explanation of why some of them look the way they do. Or modify them to be more informative.
(4) The schema page https://lasair-dev.roe.ac.uk/schema. I have guessed at which fields to include from sherlock_crossmatches, and guessed at the correct explanation. I have also reduced the ZTF candidate schema.
(5) We would also appreciate your opinion of the new object page, for example https://lasair-dev.roe.ac.uk/object/ZTF18aaxyspx/, which now has non-detections, Sherlock classification/annotation, and JSON output.