From: Rachel A. Gibbons (ragibbons@lbl.gov)
Date: Thu Jul 01 2004 - 17:25:25 PDT
Hi,
No decision on the prioritties issue, I see. Thinking a bit more...
Adam says :
> It might make more sense if we make each of our chunks contiguous
> in case we might try to fit in 2 nearby SNe without grabbing someone
> else's priority.
Here would be a reason not to like this. Two good high z candidates
are found close to each other, but in adjacent tiles. It would stink if
one team had priority to follow both of them and the other team were left
with nada.
Now, in the end we have priority on more tiles and will therefore have
more tiles with close neighbors, no matter how we divvy them up.
This again argures for Adam simply having priority on a block of five,
but *not* a set in the center which address the May search coverage issue.
Gotta run to a short meeting, if this doesn't make sense that's fine,
you guys decide.
Rachel
On Thu, 1 Jul 2004, Rachel A. Gibbons wrote:
>
> Hi,
>
> If we're going to group tiles together (I prefer this idea), why not
> have the other team take priority on any grouping which includes 2 of the
> middle tiles, as Adam proposed :
>
> top 5 (tiles 32-36)
> bottom 5 (21,22,24,25,27 - since 23 isn't being observed this time)
> or side options such as (27,28,31,32,35).
>
> Randomizing the positions may look nice, but doesn't mean anything
> statistically.
>
> Also, I think worrying too much about weighting by the search area
> covered in the May search is not necessary. Grouping like I have should
> be close to doing that given the symmetry of the tile positions.
> Remember, the exact HST pointing won't necessarily line up with the map
> (especially tile 30 since it'll be taken at a 6D tilt), so the precision
> to which you measured the tile coverage overanalyses this.
>
> Make sure Adam has included all follow-up orbits that have and will be
> used on current candidates. I see, for example, they will execute another
> orbit over the weekend. Probably Adam included this in his total.
>
> I won't be in to the office until later today, since I have a lot to
> do to get ready for my trip tomorrow. So please don't wait for my further
> opinion on this.
>
> Ciao,
>
> Rachel
>
> On Thu, 1 Jul 2004, Robert A. Knop Jr. wrote:
>
> > Hey guys-- in light of this, please rework the thing you did yesterday
> > using *19* orbits, and send it on to adam asap.
> >
> > -Rob
> >
> > ----- Forwarded message from adam riess <ariess@stsci.edu> -----
> >
> > Date: Thu, 1 Jul 2004 10:37:15 -0400 (EDT)
> > From: adam riess <ariess@stsci.edu>
> > Subject: search priority
> > To: robert.a.knop@vanderbilt.edu, gibbo@panisse.lbl.gov
> > Cc: saul@lbl.gov, ariess@stsci.edu
> >
> > Dear Team,
> >
> > We need to work out priority now before the next search starts
> > in 5 days. The plan Saul and I worked out last year
> > was simple: we use the ratio of orbits remaining
> > for the two teams to decide the fraction of tiles in searches 3 and 4
> > for which each team has priority.
> >
> > So we have 19 orbits left and you guys have 60-(25 or 26 orbits used)~34 or
> > 35.
> >
> > So that gives us priority on 35% of the tiles left or 5 of the 15
> > tiles and you guys get priority on the other 10.
> >
> > The last step was to select (we said by random number generator)
> > which are our 5 and which are your 10.
> >
> > It might make more sense if we make each of our chunks contiguous
> > in case we might try to fit in 2 nearby SNe without grabbing someone
> > else's priority.
> >
> > (For example we could take TILT-TILE 10,14,13,9,16 or some
> > group of 5).
> >
> > I don't care so much but I want to resolve this in the next ~2 days
> > so we don't run into the search and so we can
> > see from the schedule when our priority tiles need to be searched.
> >
> > So Vandy's please respond asap so we can resolve this.
> >
> > -Adam
> >
> >
> >
> >
> >
> > ----- End forwarded message -----
> >
> >
>
>
-- ------------------------------ Dr. R. A. Gibbons Lawrence Berkeley National Lab 1 Cyclotron Rd MS 50R5032 Berkeley, CA 94720-8160 USA Tel 510.486.7416 ------------------------------
This archive was generated by hypermail 2.1.4 : Thu Jul 01 2004 - 17:27:49 PDT