From chenyc@fnal.gov Mon Mar  8 18:25:20 1999
Date: Tue, 1 Dec 1998 10:37:43 -0600 (CST)
From: Yenchu Chen <chenyc@fnal.gov>
To: Ping Yeh / Academia Sinica <pyeh@mail.cern.ch>
Cc: Jaroslav Antos <antos@mail.saske.sk>, G.P. Yeh <gpyeh@fnald>,
     Paoti Chang <paoti@fnald.fnal.gov>, Pavel Strizene <strizene@ns.saske.sk>,
     Antonio Wong Chan <tony@lixpro1.phys.sinica.edu.tw>,
     Stephen Wolbers <wolbers@fnal.gov>
Subject: Re: some terms

Hi Ping,

   I agree with you that we should use same terminologies to avoid
confusions and I think what you are proposing is fine with me.

   One thing I double checked with Steve is that the executable will
do the spilitting, means that at the end of reconstruction it will 
put events into different streams files. Event can be duplicated and
exist in multiple streams.

   Best regards,    Yen-Chu Chen
                    chenyc@fnal.gov
                    (630) 840-8871 (experiment)
                    (886)-(2) 2789-9681 (Inst. of Phys., Academia Sinica)

On Tue, 1 Dec 1998, Ping Yeh / Academia Sinica wrote:

> 
> Hi Yen-Chu,
> 
>     I read the FBS user's guide.  I think we should start to use
> the same terminologies for the same thing to avoid confusions.
> 
>     I list my opinions below.  Please comment.
> 
> 						cheers,
> 						Ping
> 
> ================================================================
> 
> input:  No problem with this, right?  8)
> 	Okay, this should be the process that copies data from tape to disk.
> 
> split/distribute/dispatch:
> 	In FBS guide "dispatch" is used for activating worker nodes.
> 	GP liked "distribute".  You were using "split".  I prefer to
> 	use "dispatch" because it properly describes the action of
> 	asking worker nodes to start jobs.
> 
> analysis/processing/reconstruction:
> 	In Steve Wolber's note "analysis" means physics analysis,
> 	not event reconstruction.  But in FBS guide analysis is used
> 	for data processing.  I prefer to use "event reconstruction"
> 	(or "reconstruction" for short) because it is less confusing
> 	in the context of data production.
> 
> splitting:
> 	In Run 1 "splitting" means copying events to various physics
> 	streams.  An inclusive DST file is "splitted" into several
> 	smaller DST files.  Each small DST file contains events that
> 	satisfy the same set of triggers.  If an event satisfies more
> 	than one trigger, it is duplicated.
> 
> 	PAD (Physics Analysis Data) files are also splitted in similar way.
> 
> 	In Run 2 the definition of DST and PAD may change, but I propose
> 	we still use "splitting" for similar actions.
> 
> merging/concatenation:
> 	In Run 1 "concatenation" means merging those small files of the
> 	same stream to larger files, one file per run.  I prefer to use
> 	"merging" because it is a shorter word.
> 
> output/spooling:
> 	Copy data from disk to tape.  This was called "spooling" in Run 1
> 	because data have to be queued on disk until a tape-worth of
> 	them are accumulated.  I think this name is fine.
> 
>