From: Pawel Staszel (ufstasze@if.uj.edu.pl)
Date: Tue Aug 26 2003 - 11:26:59 EDT
Hi, Flemming Videbaek wrote: >Hi > >There are some good thoughts in this e-mail. I and others are certainly aware of non-unifomity in naming, >scripts, locatation of files etc. There has been recent work done by Claus, Bjoern, and Hiro to come with >consistent naming of the files generated and used by the analysis. >I have myself had toughts on this, and I believe this is converging (has converged even), and at the same time official >repository should be made that keeps the scripts, (different for each run period and species) > that has been and are being used for production generation of files. > I do like this idea to distinct between scripts used for different running periods and to keep them in different cvs modules or in a single module but in different sub-directories. The sub-directiories should be organized in a nice tree, reflecting the subsequent stages of analysis, containing README, appropriate job scripts, submitting tools like masterReduction.sh, links to detector efficiency files, acceptance maps, etc. I like to think about BRAT as a general tool box which serves with tools needed for the specific jobs defined out of BRAT. It is mainly because the specific jobs require a specific setup which depends e.g. on the running period (as pointed by Flemming), and putting them in to BRAT will spoil it's "generality". Cheers Pawel. > >There is always going to be difference in the 'tast' one has, but the underlying rationale that production stuff should be >maintained in official repositorys be it inside or parallel to brat , cannot be questioned. > >Flemming > > > >------------------------------------------------------ >Flemming Videbaek >Physics Department >Brookhaven National Laboratory > >tlf: 631-344-4106 >fax 631-344-1334 >e-mail: videbaek@bnl.gov > >----- Original Message ----- >From: "Christian Holm Christensen" <cholm@hehi03.nbi.dk> >To: <brahms-dev-l@bnl.gov>; <hagel@comp.tamu.edu> >Sent: Monday, August 25, 2003 12:56 PM >Subject: Re: BRAT does not compile anymore. > > >| Hi all, >| >| Kris Hagel <hagel@comp.tamu.edu> wrote concerning >| Re: BRAT does not compile anymore. [Mon, 25 Aug 2003 10:18:04 -0500] >| ---------------------------------------------------------------------- >| > A short comment about BrRecoPackage. I started on that very >| > enthusiastically to try to take some of the "mystery" (at least for >| > me) out of reduction. >| >| You're not alone! >| >| > The intent was to have it consistent with ProductionReduction.C and >| > thereby simplifying ProductionReduction.C and making the results of >| > a reduction less dependent on which ProductionReduction.C one is >| > using. (ie the one in djam_app or the one in kh_app or any other >| > place where one might find one (I am fairly sure there are more to >| > be found; perhaps they are not even called >| > ProductionReduction.C!!!) >| >| >| I'm surprised that none of these scripts have made it into BRAT yet. >| Or something like your `BrRecoPackage'. >| >| >| > I also must say that I did not know about the ProductionReduction.C >| > in ~bramreco/reduce, but now that I look at it I see that it is a >| > link to djam_app. Will it remain the "official" script after Djamel >| > finishes? >| >| If it's official, shouldn't it be in BRAT (hint hint). >| >| > And for my part, as long as we continue to have "official" passes >| > coming out of macros in peoples private directories where the >| > collaboration as a whole does not have control over what the >| > individual person is doing, I will remain confused. >| >| > On the other hand, if it would be felt that something like >| > BrRecoPackage would be an appropriate approach, perhaps I could >| > notch that up on my priority list if there would broad consensus >| > that it would be used once completed and accepted. >| >| Why not? I think it's a good idea, as long as it's not doing too >| complicated stuff. Heck, then you could run your jobs via the >| interactive prompt (on a PROOF server?), like: >| >| > bratroot >| brat[0] BrMainModule* main = BrMainModule::Instance(); >| brat[1] main->Add(new BrRecoPackage); >| brat[2] main->Main(); >| starting job on node `rcas0000.rcf.bnl.gov' ... >| starting job on node `rcas0001.rcf.bnl.gov' ... >| starting job on node `rcas0002.rcf.bnl.gov' ... >| ... >| >| Be warned: This is not complete, just a hint at what _might_ be >| possible, should Kris' idea be implemented. >| >| > In the short term, I will check it out and make sure it compiles. >| >| Well, I think it's safe to say, that when you do changes in one >| directory, to one set of modules, then you should may damn sure that >| _all_ of the directories build nicely. Meaning, if I do a change in >| class `BrFooModule', and `BrBarPackage' uses that module, then I >| should make sure that `BrBarPackage' compiles _before_ submitting to >| CVS - otherwise people will slam me on the head, saying `BRAT does not >| compile anymore!' >| >| A suggestion for Kris: Why not leave the various `Set'ters out of the >| `BrRecoPackage', and just have `Get'ters to get a reference (or >| pointer) to the various contained modules - much like in the >| BrMultPackage for example. In that way, BrRecoPackage is thin, but >| still allows for user customisation. >| >| > > I made a look into BrRecoPackage and, at least concerning the DC >| > > setup, is it absolutely not up-to date. >| > > I don't know whether any one uses it, if not, it should be removed, if >| > > yes, it should be modified >| > > according to ~/bramreco/reduce/ProductionReduction.C - but in my >| > > opinion keeping the same >| > > software in two different places is a potential source of confusion. >| >| It definitely is - however, having `official' scripts outside BRAT is >| even more confusing. In that respect, Kris' approach is sound - it >| keeps the `official' stuff were it's supposed to be - in BRAT. >| >| 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 : Tue Aug 26 2003 - 05:21:06 EDT