Message: 6
Date: Fri, 17 Feb 2006 17:25:32 -0700
From: Jeffrey P Kantor <[EMAIL PROTECTED]>
Subject: Re: [LSST-data] Tech Assess concall on Feb 20 is cancelled.
To: LSST Data Management <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="US-ASCII"
Hi Don,
I would like you to consider re-scheduling the telecon rather than
cancelling. There are several groups now interested in getting
cell blades
and it might be a good idea to coordinate efforts. I also have the
Observatory proposals in hand, and could use some extra eyes (but
not Chris
Smith or Ron Lamber, since they are contributors to the AURA
proposal) to
examine the Data Communications sections. Thanks!
Jeff
From: "Don D. Dossa" <[EMAIL PROTECTED]>
Reply-To: LSST Data Management <[email protected]>
Date: Fri, 17 Feb 2006 15:13:52 -0800
To: [email protected]
Subject: [LSST-data] Tech Assess concall on Feb 20 is cancelled.
The tech assess call for 2/20 is cancelled since it turns out to be a
national
holiday. I don't know how many people will be home that day, but it
sure
includes me.
On another note, I have a proposal for the order of readout of the
CCDs on
each raft that minimizes the time required for the crosstalk
calculation.
I have another plan for multiplexing the 25 fibers (and telemetry
line) that
go into the IB switch on the mountain into the 10 nodes that drive
the
data down to the base. The design will automatically and
transparently
recover from the failure of any 1 of the 10 nodes on the mountain. No
one
node is now a single point of failure.
The addition of a second IB switch on the mountain eliminates that as
a single point of failure. This is probably as far upstream we can
do to
add redundancy and insure no data is lost except for a fiber cut
connecting
the mountain to the base.
I will write this up and send it out to the team during the week of
2/20.
Don
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
------------------------------
Message: 7
Date: Mon, 20 Feb 2006 13:22:47 -0600
From: Rob Pennington <[EMAIL PROTECTED]>
Subject: Re: [LSST-data] Tech Assess concall on Feb 20 is cancelled.
To: LSST Data Management <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Resheduling would be helpful to us given the recent discussion on
cell blades. We're putting together plans along with some others at
UIUC around cell efforts and we want to be able to work with several
efforts without over/under committing.
Rob
At 5:25 PM -0700 2/17/06, Jeffrey P Kantor wrote:
Hi Don,
I would like you to consider re-scheduling the telecon rather than
cancelling. There are several groups now interested in getting
cell blades
and it might be a good idea to coordinate efforts. I also have the
Observatory proposals in hand, and could use some extra eyes (but
not Chris
Smith or Ron Lamber, since they are contributors to the AURA
proposal) to
examine the Data Communications sections. Thanks!
Jeff
From: "Don D. Dossa" <[EMAIL PROTECTED]>
Reply-To: LSST Data Management <[email protected]>
Date: Fri, 17 Feb 2006 15:13:52 -0800
To: [email protected]
Subject: [LSST-data] Tech Assess concall on Feb 20 is cancelled.
The tech assess call for 2/20 is cancelled since it turns out to
be a
national
holiday. I don't know how many people will be home that day,
but it
sure
includes me.
On another note, I have a proposal for the order of readout of the
CCDs on
each raft that minimizes the time required for the crosstalk
calculation.
I have another plan for multiplexing the 25 fibers (and telemetry
line) that
go into the IB switch on the mountain into the 10 nodes that
drive the
data down to the base. The design will automatically and
transparently
recover from the failure of any 1 of the 10 nodes on the
mountain. No
one
node is now a single point of failure.
The addition of a second IB switch on the mountain eliminates
that as
a single point of failure. This is probably as far upstream we
can do to
add redundancy and insure no data is lost except for a fiber cut
connecting
the mountain to the base.
I will write this up and send it out to the team during the week of
2/20.
Don
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
------------------------------
Message: 8
Date: Tue, 21 Feb 2006 03:25:33 -0600 (CST)
From: Ray Plante <[EMAIL PROTECTED]>
Subject: [LSST-data] Altering definition of Job [MiddleWG]
To: LSST Data Management <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Keywords: MiddleWG
Hi UMLers,
At our middleware videocon, I took on an action to press on some
use cases
that elucidate how the Data Access Framework works its magic. A main
focus will be on the case of cross-talk correction. I am putting
together
a problem statement will help scope what robust diagrams, for example,
need to be generated to illustrate this. I feel this needs to be
put in
terms of the UML use cases and should perhaps include robustness
diagrams
for related components that help support the context. While
working my
way through this, I found the need to make (what I hope are) small
changes to the UML model. This message describes the first set of
changes
which I just checked in.
This set of changes appear in the Processing Framework Summary
diagram in
the Framework package of the Domain Model. The main change is a
shift in
the definition of a Job. Previously, this was defined to be something
that controls an instance of a Pipeline and scheduled by a Job
Scheduler.
I have shifted the defintion of a Job to be the instantiation of a
*Processing Step*. The latter represents the unit of processing
that is
actually scheduled and executed as a whole. The various processing
steps
could be scheduled on different platforms (say, one step requires a
shared-memory platform). With this shift, I felt we now needed to
show a
class that instantiates and manages a Pipeline as a whole, so I
added a
"Pipeline Manager" class.
To give you a sense of why I felt this necessary, I'll point out
that the
model for parallelism for the cross-talk correction may be
different that
that of the rest of the Calibration Pipeline. I wanted to allow,
if it
turns out to be useful, the option of separating this correction
into its
own processing step apart from the other stages of calibration (which
could require a shifting of data by the DAF). In this case, I feel we
need to show a little more clearly how processing steps are
scheduled and
managed as individual entities.
In summary, my changes were:
o shifted defintion of Job to be a scheduled instance of a
Processing
Step.
o added Pipeline Manager class which contols a Pipeline and
invokes a
Job Scheduler to shedule Jobs that carry out the Pipeline's
work.
o added defintions (in the Notes Section) to key classes in the
diagram
(attn: Jacek--including Provenance objects; please verify).
o rearrange visual layout accordingly.
cheers,
Ray
------------------------------
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
End of LSST-data Digest, Vol 18, Issue 14
*****************************************
