Re: lullaby

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Fri Nov 22 2002 - 10:26:48 EST

  • Next message: Andrey Makeev: "ZDC cal-s for 130 GeV runs"
    Hi Flemming et al, 
    
    "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> [Fri, 22 Nov 2002 09:26:03 -0500] wrote concerning
      lullaby 
    ----------------------------------------------------------------------
    > Hi Christian
    > 
    > The machine is on my desk, and actually in the pii cluster,
    > But don't dare to use it !!
    
    I wasn't considering that, I was merely wondering what this new
    machine was :-) 
    
    > On the detector params
    >  - yes I think SOME of the data should go into a DB; but many of
    > them will never change and then it may not be so bad to keep them in
    > ascii files - afterall we have many tasks on the plate , and it may
    > not be the highest priority to design the ideal system. I will take
    > a look at this. 
    
    Whether a given parameter changes or not is not really the conditional
    for whether it should be stored in a database or not. 
    
    I'd say that the decision criteria is: 
    
      If a parameter is used by multiple jobs, people, steps, ladida, over
      and over again independent of simple `job-parameters', it _must_ be
      stored in a database.   
    
    It is clear that the parameters that do not change (or change rarely)
    should not be written to the databases often - in fact, they should
    only be written when they change.  Fortunately the design of the DB's
    facilitates just that. 
    
    Also, I'd argue that such things as ADC-channel-number to
    row/ring-number (like in the SMA/TMA/BB(?)), ADC-channel-number to
    pad-row/column, active channel, and similar maps, all belong in the
    geometry database, as it's conditional on the physical (as in some
    thing palpable) setup, not the `cyperspace' of the DAQ. 
    
    Whether we should `... design the ideal system' is a non-issue.  The
    point is we should have a system that is fault tolerant and insures
    data integrity.  A database is just that - ASCII files are not,
    period.  And, we don't really need to design anything new - we can
    exploit the already existing system.   I know the design calibration
    database is flexible and stable enough to handle what is in the 
    `DetectorParameters.txt', and that may also be the case for the other
    database desgins in BRAHMS - I don't know - I haven't looked at them
    in that detail. 
    
    Yours, 
    
     ___  |  Christian Holm Christensen 
      |_| |	 -------------------------------------------------------------
        | |	 Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
         _|	          DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
        _|	          Denmark                    Office: (+45) 353  25 305
     ____|	 Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
     | |
    


    This archive was generated by hypermail 2.1.5 : Fri Nov 22 2002 - 10:27:32 EST