Total no. of type 1a supernovae in DP0.2

hi, when trying to seperate SN1a, from truth summary table i got 445209 results(redshifts), and from diaobject i got 70976 results(fluxes), so how do i allocate redshift and flux/magnitude corresponding to each SN1a, as i want magnitude vs redshift of all the SN1a (not evolution of one SN1a), on a single plot.

and no SN1a id from truth summary table or matches truth table is present in any of the DiaObject, DiaSource, and ForcedSourceOnDiaObject tables , am i doing something wrong?

Hi, Akshita! I am the Community Engagement Team forum watcher for this week. I am just replying to let you know I am looking into your question. I note that the MatchesTruth table has a match_objectID column, which is the objectId of the object within the Object table, but I have found no equivalent column in the DiaObject , DiaSource , or ForcedSourceOnDiaObject tables that matches the DiaObject/DiaSource id back to either the Object table or the MatchesTruth table. Let me look further into this and consult others.

More info soon (I hope)!

OK, I have some additional info now.

It appears that, although the DP0.2 MatchesTruth table has a match_objectId column, which is the objectId of the object within the Object table, there is nothing corresponding for the DiaObject , DiaSource , or ForcedSourceOnDiaObject tables. For that matter, there is no spatial match between, say, the Objects table and the DiaObjects table – at least not for DP0.2 (but there should be in the future). Thus, to do what I think you want, one must do one’s own matching between the entries in the TruthSummary table and (say) the DiaObjects table. Unfortunately, speedy spatial matching can be a big pain. If you don’t mind an imperfect – but not unreasonable – quick-and-dirty method, I recommend using healpixels with a sufficiently high NSIDES value that you do no risk either too much contamination or too many missing matches. Along these lines, I wrote a simple Jupyter notebook, which you can find attached to this message. (For the time being, you can also find a copy in my scratch area of – in /scratch/douglasleetucker/notebooks/TrueSNeIa.ipynb.

I hope this helps!

Sorry for the delay!

TrueSNeIa.ipynb (166.4 KB)


thank you for the detailed solution.

i tried the healpy code to get match both the tables , so for around 6000 SNe in diaobject , only 1000 out of those 6000 matched with the truth table Sne, i didn’t understand that?

i had used the diaobject tutorial code to get Sne between redshift range 0.1 to 0.3, but the matched 1000 Sne have redshifts way beyond the expected range?

i have attached the jupyter notebook containing the code and plots.

Untitled5.ipynb (86.1 KB)

Good questions! I have run your notebook (many thanks for supplying it!), but I don’t have an immediate answer. Of course, not all the transients found by the diaobject notebook will be SNe: some will be variable stars. According to Sectoin 5.3 of the DC2 Release Paper, about 10% of the simulated stars were made variable. But it still seems surprising that only 1000 of the diaObjects had matches with the SNe in the Truth Summary table. Maybe you can try some spot checks of the light curves of some of the matched and unmatched diaObjects, something like what was done for the first 20 matches in Section 3.4 of tutorial notebook 07a_DiaObject_Samples.ipynb ?

I am also not sure why the 07a_DiaObject_Samples.ipynb notebook seems to be netting so many z>0.3 SNe Ia. Could they just be mismatches (i.e., the healpix matching method is yielding too many mismatched objects)? Could there be an issue with the SN-finding algorithm in 07a_DiaObject_Samples.ipynb? Are other types of SNe (besides SNe Ia) also being represented in the simulated data? But I don’t think the DC2 Release Paper mentioned other SN types?

Might need to think about this more…

Re. “Could there be an issue with the SN-finding algorithm in 07a_DiaObject_Samples.ipynb?”

That is not an SN-finding algorithm, not by any means. The notebook 07a contains a very rough, back-of-the-envelope way to identify a bunch of DiaObjects with parameters that suggest they are SNIa-like. The resulting sample is not scientifically useful (not pure, not complete) – it is just a few simple cuts that will get you a bunch of DiaObjects for which we can demonstrate how to plot light curves using the DiaSource table. Real SN-finding algorithms are photometric classifiers that fit the light curves with templates, rigorously, and provide probabilistic classifications. The text in Section 1 of the notebook describes this.

Re. “Are other types of SNe (besides SNe Ia) also being represented in the simulated data?”

The DC2 simulation only included Type Ia supernovae. But there are also variable stars, and the simple cuts being made on the DiaObject light curve summary parameters in notebook 07a could permit DiaObjects that are variable stars into the sample.