Should the Supernova statistic have an associated tracer type in SACC?

[marcpaterno]

Currently, the Supernova statistic uses a tracer of type sacc.tracers.MiscTracer (see https://sacc.readthedocs.io/en/latest/tracers.html).

Should it instead have a dedicated tracer type? It would seem that this would at the very least help prevent misconfigurations of programs, helping to avoid the reading of wrong tracers from the SACC data.

What would the features of this type be?

Would someone working with the Supernova statistic in analysis volunteer to take on implementing such a thing?

[marcpaterno]

There is already an issue in SACC (LSSTDESC/sacc#42) discussing this. That issue is still open.

[am610]

just putting my two cents here : the SN tracer currently is miscellaneous type. Is it worth the effort to move it into a dedicated tracer type, given the fact I am not aware of which other probe is going to use the 'misc' type tracer, making it almost proprietary to SN.
However, If we do want, and if no one else is volunteering, I can try implementing this.

[joezuntz]

I don't think we should reserve the misc tracer for supernovae, that just seems confusing for future usage. I would suggest having a new tracer, even if it's very simple, so that it signposts the meaning.

[am610]

Yes ok, I give into this logic. I can start working on this. probably in a week's time.

[vitenti]

@am610 Hi Ayan, we have started using this discussion feature on github. It seems to be very handy in discussing the design prior to the implementation. So, we would like to suggest that you could put your first design ideas here so everyone can discuss them and contribute. Once we have a consensus plan we turn this into an issue (using github's feature: Create issue from discussion) and implement it.

[am610]

Hi everyone, while this might need for brainstorming, I am suggesting below an initial outline, of what I think could be a good start. I am of the opinion to start with a simple design, where we create a new tracer type, very much replicating the (current) existing design.

So the following modifications in tracers.py :
Add a new class SupernovaTracer to represent supernova data. This class will have attributes for redshift (zcmb and zhel), distance modulus (mu), and its error (muerr).
The SupernovaTracer class will have a method get_redshift to retrieve the redshift data for the tracer.

Again, this is an overview and we can start discussing more.

[marcpaterno]

When written to a table with SupernovaTracer.to_tables(instance_list), would the result produce:

1. a single table contributed to by each SupernovaTracer in instance_list, or
2. multiple tables, one for each SupernovaTracer in instance_list?

The MiscTracer does 1, but other tracers (e.g. NZTracer) does 2.

[joezuntz]

I'd recommend a single table. The MiscTracer is a bit of an outlier, being miscellaneous. A single table would reduce the overheads.

[am610]

I am attempting to display a raw code block to show how it is implemented. Please check the code below and comment if you agree.

The following is an example snippet for a single table in the SupernovaTracer instance.

@classmethod
def to_tables_consolidated(cls, instance_list):
    """Convert a list of SupernovaTracer instances to a single consolidated table."""
    table_data = []
    for instance in instance_list:
        for redshift, mu, mu_err in zip(instance.z, instance.mu, instance.mu_err):
            table_data.append((redshift, mu, mu_err))
    table = Table(names=('z', 'mu', 'mu_err'), data=table_data)
    return table

and below for multiple tables, one for each tracer instance,

@classmethod
def to_tables_individual(cls, instance_list):
    """Convert a list of SupernovaTracer instances to individual tables."""
    tables = []
    for instance in instance_list:
        table_data = list(zip(instance.z, instance.mu, instance.mu_err))
        table = Table(names=('z', 'mu', 'mu_err'), data=table_data)
        tables.append(table)
    return tables

or something similar.

[marcpaterno]

@joezuntz please correct me if I’m wrong, but my understanding is that the Tracer protocol specifies just the method to_tables, and that Joe’s suggestion was for to_tables to yield a single table. So I think we want something like your implementation of to_tables_consolidated, but the method name should be to_tables.

[joezuntz]

Yes, exactly, except that it would have to return a length-1 list return [table] not just return table

(I think the name Ayan used was just for illustration.)

[marcpaterno]

@am610 if you agree I think we can convert this discussion to an issue. Do you agree?

[am610]

Hi @marcpaterno , yes I think we should make it an issue. However I would like to put a disclaimer : I will take a few days time before I start working on this, I have few stuffs going on at the moment, thanks.

[marcpaterno]

This is now being handled as issue #317