From: Alexander Conley (AJConley@lbl.gov)
Date: Thu Sep 16 2004 - 17:23:34 PDT
Hello all,
In some discussions with Don I discovered what I think is a mistake
in the way that the V band magnitudes were determined in P99.
While attempting to determine if this actually affected P99, Greg and I
discovered another bug that definitely occured in P99. This bug
masks our ability to determine if the first problem is real. I will
describe both, starting with the second problem because we have
verified that it exists. They two problems are conceptually identical,
they just manifest differently.
The good news is that both problems would only affect the Vmax
values of P99, and so have no bearing on fit C. However, fit D
is affected, and the comparison of low and high redshift color
distributions is incorrect. This did not affect K03.
This is a long email, so be warned.
This bug has to do with the program that converts the Hamuy lightcurves
into the format that snminuit understands (read_hamuy), and therefore
only affects the low redshift sample. More specifically, the V band
fits
to 8 of the 18 Hamuy SNe are incorrect : 92P, 92ae, 92ag, 92bc, 92bh,
92bo, 92bp, 93ag.
The problem is that read_hamuy (at least the version used in P99)
subtracted off the date of the brightest point from all of the dates
when writing out the file. The problem is that the B and V files were
handled independently, and so if the brightest B point did not occur
at the same date as the brightest V point the resulting B and V
lightcurves
were placed on different time axes.
Example: 92ae. The brightest B point occured on date 8807.82, and
the brightest V point on 8805.83. These were both considered to occur
at date 0 when the joint fit was done, and so the V maximum was
computed incorrectly.
Here is the error in days for each of the problem SNe, where the
error is defined as the date of the brightest B point minus the date
of the brightest V point: 92P (1.03), 92ae (1.99), 92ag(1), 92bc(2.93),
92bh(2.98), 92bo (0.95), 92bp(0.92), 93ag (-1). These are all observer
frame days, although at these redshifts that doesn't matter much.
Fortunately, as I stated above, this doesn't affect the Bmax magnitudes.
The reason for this is the fashion that the lightcurve fits were
performed
in P99. First, the B band was fit. Then the date of maximum, stretch,
and
B flux multiplier were fixed and a joint fit was performed. The only
thing
allowed to vary from the B only fit was the R-I parameter. So the Bmax
value used in most of the fits was calculated from the B only fits, and
the problem described above can only occur in multiple-color fits.
But it will definitely affect the calculated V maximum for all of the
listed SNe.
Unfortunately, estimating the size of the effect that this had is not
trivial because the fitter will interact nonlinearly with the incorrect
dates. The only way to really tell how much this mattered would be
to redo the fits with the old code, but without the bug in read_hamuy.
The other problem, which isn't really a bug, is a bit more complicated.
It again has to do with an assumption about the brightest point in the
two bands occuring on the same date, but only occurs when the brightest
V band point is brighter than the brightest B point. It will only be a
problem
when the P99 fit prescription (B fit followed by joint B and V fit with
everything
except R-I fixed) is followed. The problem is that the method of fixing
the date of maximum for the joint fit looks simple, but actually isn't.
When you do a snminuit fit, the output contains the best fit
parameter t of B max. A typical value is around 0. This value
can be fixed by editing the control file to the value you want and
then adding a 'fix 1' line.
The subtlety arises when you realize that this number is in a system
that is relative only to the lightcurve being fit -- that is, fixing
t of B max to -11 will mean different things to a B only and V only
fit to the same supernova because the B and V lightcurves are not
identical. To first order this date system is relative to the brightest
point in the lightcurve in question. When you do a joint fit it will
be the brightest point in either lightcurve.
A simple example may help clarify what I mean. Imagine a
SN with B observations on day 1,2,3,4,5,6,7 and V band observations
on days 5,6 and 7. The brightest B point is on day 2, and the brightest
V on day 5 -- and is brighter than the maximum B point. Say that the
snmin fit returns t = +0.2, which would mean that in real days the date
of maximum is 2+0.2 = 2.2. Next imagine that
you want to do the V band fit, and you edit the control file to fix the
first
parameter at 0.2, which is what you got from the B fit. The problem is
that in the V frame t=0.2 actually means 5+0.2 = 5.2, which is not
at all the same.
So, you might wonder, if this is the case, shouldn't it have been
obvious
from the fits? Not necessarily, because most of the time if there is
color information is is taken around peak, so the brightest point will
probably have both B and V. It isn't quite this simple because of
random fluctuations and what not, but for most lightcurves the B and
V band frame that snminuit works in will be pretty close -- but not
always.
In addition, I suspect that this piece of code doesn't understand the
difference between the B and V peak dates, so you can expect to be
systematically off by 1-2 days, depending on whose SN template you
are using.
Things are actually a bit more complicated because the current version
of snminuit doesn't simply take the brightest point, but instead
computes
some weighted mean of the brightest points, but the scale may still
come out differently for B only, V only, and B+V joint fits.
I have verified this problem using sn1998as, a supernova for which the
V band coverage starts considerably later than the B band coverage.
For a B only fit, the zeropoint of the time axis is at 50908.6 and the
tbmax
fit value is -12.572. This translates into an actual date of B max of
50896.03. For a V only fit the zeropoint of the axis is 50952.2.
If I perform a joint B and V fit the time axis zero is at 50916.5.
This means that if I try to perform a fit in the fashion that they are
performed
in P99 by doing a B only fit and then doing a joint fit where tbmax is
forced
to be -12.572, then in the joint fit snminuit will interpret the date
of B max
as being 50916.5-12.572 = 50914, which is different than the B only fit
value of 50896, and the fit won't turn out as you intended.
It is still an open question as to whether people were aware of this
problem
in P99 and if they took account of it. The first problem completely
masks
this one. It is possible that these two problems cancel out, although I
would have to think about the signs carefully to be sure. However,
since
the second problem only occurs in a subset of the cases in which the
first problem occurs (because in addition to the brightest B and V
points
occurring on different days, the V point must be brighter than the V
point)
this won't really save us.
This problem also did not affect K03 because Rob always perfomed joint
fits.
Alex
This archive was generated by hypermail 2.1.4 : Thu Sep 16 2004 - 17:25:37 PDT