TNS spectral types not being returned on Lasair page

[smarttgit]

We should report the SN types that are in the TNS on the Lasair page. Users should not have to click through.

e.g https://lasair.roe.ac.uk/object/ZTF19abgpgyp/

Is correctly reported as being SN2019lkw , but the SN type (which is registered on the TNS) is not being reported on Lasair. This is easy to pull out - Ken and Dave have code.

[RoyWilliams]

Is it one of these attributes? mysql> describe crossmatch_tns ; +--------------------+---------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------+---------------------+------+-----+---------+----------------+ | id | int(10) unsigned | NO | PRI | NULL | auto_increment | | ra | double | NO | | NULL | | | decl | double | NO | | NULL | | | tns_name | varchar(10) | YES | UNI | NULL | | | tns_prefix | varchar(10) | YES | | NULL | | | disc_mag | float | YES | | NULL | | | disc_mag_filter | varchar(50) | YES | | NULL | | | type | varchar(20) | YES | MUL | NULL | | | z | float | YES | | NULL | | | hostz | float | YES | | NULL | | | host_name | varchar(512) | YES | | NULL | | | disc_instruments | varchar(512) | YES | | NULL | | | public | tinyint(4) | YES | | NULL | | | sender | varchar(50) | YES | | NULL | | | associated_groups | varchar(512) | YES | | NULL | | | classifying_groups | varchar(512) | YES | | NULL | | | discovering_groups | varchar(512) | YES | | NULL | | | class_instrument | varchar(512) | YES | | NULL | | | tnsid | int(10) unsigned | YES | | NULL | | | disc_int_name | varchar(512) | YES | | NULL | | | ext_catalogs | varchar(512) | YES | | NULL | | | disc_date | datetime | YES | | NULL | | | tns_at | tinyint(4) | YES | | NULL | | | htm16 | bigint(20) unsigned | NO | MUL | NULL | | +--------------------+---------------------+------+-----+---------+----------------+

[smarttgit]

It is probably :

| type | varchar(20) | YES | MUL | NULL | |

[genghisken]

Yes - it's "type". The code running at ROE is almost identical to that which is running on ATLAS/Pan-STARRS. We also show "z" and "hostz" if they are populated, as well as "disc_int_name", "disc_date" and "sender" (Simple "if" statement in the Django template). The "sender" field is usually a "bot" so I remove any _bot1/_BOT/Bot* characters before displaying.

[RoyWilliams]

https://lasair.roe.ac.uk/object/ZTF19acxxwrs/

In TNS as SN2019wep at 0.7 arcsec, discovered 2019-12-07 23:16:30 (MJD 58824.00) by XOSS type SN II-pec

[smarttgit]

Great, while we're here, can we tidy up the text and information

"at 0.7 arcsec" - I guess means the separation between the Lasair coords and the TNS coords ? If yes, change to:

"In TNS as SN2019ewp (0.7 arcsec separation from ZTF coordinates), discovered (MJD 58824.00) by XOSS. Classified as a type SN II-pec at a redshift z = 0.025

Where the redshift is reported from the value : | z | float | YES | | NULL | |

This will allow users to compare the host z (which we report from Sherlock) and the z inferred from the transient. Sometimes these can be different which can mean interesting object.

i.e. the redshift in that sentence should NOT be that from Sherlock, it should be the one reported in the TNS

[chrisfrohmaier]

This update has removed the useful hyperlink to the TNS object page. I like that we can now see the classification, but would also like to click the object name to go to TNS. Thanks!

[RoyWilliams]

Hope this is OK now. Text below. The TNS name is hyperlinked.

In TNS as SN2019vtx (2.3 arcsec separation from ZTF coordinates), discovered (MJD 58816.00): by ATLAS. Classified as a SN Ia. At a redshift z = 0.0369.

[genghisken]

Good job! Just one minor issue - the date & time conversion to MJD isn't quite being done correctly. The code you're using is only treating the date part, hence all the MJDs end with .00. (In ATLAS and Pan-STARRS we report to TNS with 3 decimal places - though we will switch to 5 in future.)