From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Wed Dec 11 2002 - 21:23:31 EST
Hi Flemming et al, "Flemming Videbaek" <videbaek@rcf.rhic.bnl.gov> wrote concerning Re: Proposing BRAT/bratmain addition (PLEASE READ!) [Wed, 11 Dec 2002 19:54:50 -0500 (EST)] ---------------------------------------------------------------------- > Hi Just a few comments > > and to be frank I have NOT read the complete reply. The mail I sent does outline a lot, so I can understand why you haven't read all of it - but, please do read it, and in particular the last part where I ask some questions - and then try to answer them! I think you'll come to the same conclusion as I did. Another point of my mail, and a very general one, is that one should really sit down and figure out the usage patterns before doing any kind of coding or implementation design. And one should spell out those patterns in a document - if one can not do that, one is looking at it the wrong way. In this context, I'd like to mention the book `Design Patterns' [1] by `Gang of Four' - it's an old book using SmallTalk (an old OO language), but the concept still holds. Again, a book that should stand right next to your copy of the ISO/IEC C++ standard (I hope I get mine for Christmas). For more on the (formalised) concept of `Patterns' see also the `Patterns' home page [2]. > Some commetnts worth mentionining are > > a) I have yet to see a single person in the coll. who as part of an > analysis saves the script used with an appropriate name as well as the > BRAT version for each single run analyzed. . Ideally if one kept track of > this there would be no need for any other mechanism. We're talking `production mode' here right? In that context it's entirely safe to assume that the scripts have a meaning full name, is stored in the CVS repository of BRAT, and so on. If not, then the configuration script should not be used for `production' - it's really that simple. <rant> I think that there's a general misconception on what the personal CVS areas are for, at least in terms of production software. It's really sandboxes for development of software, but as soon as that software reaches some sort for usable state, it should immediately go into BRAT, BRAG, ..., or even it's own package (like BDST and BRED did). Of course, there are some pieces of code in the personal areas that are only used for personal things - that's OK, as long as it's not being used by more than that one person, and always explicitly marked as such. The point is, that one shouldn't need to go through another persons `private parts' to find the magic script or module that does the grand analysis of BRAHMS data to produce dN/deta, spectra, ratios, or similar - those things should be consolidated in a more open forum, and they should integrate nicely with the rest of the environment. The hope is, that at some point, you'd be able to do some thing like cvs -d /afs/rhic/brahms/BRAHMS_CVS co grand-analysis cd grand-analysis ./autogen --prefix=${HOME} make make install cd ~/ bin/grand-analysis and, vola, you get all the papers and results ever produced by BRAHMS - all you need to do next is to book your flight to Stockholm :-) </rant> Also, anyone running jobs on CRS automatically create an ASCII human readable text file that contains all the relevant information: the log files. If the verbosity is 3 or larger, you automatically get a list of all the modules, and each module _must_ list it's parameters in the output, as well as it's CVS revision number (if they don't they should be fixed). The I/O modules automatically list all the input/output files, BrMainModule shows the configuration number and author, bratmain shows the BRAT and ROOT version, as well as a time stamp - the run host, and so on. In short, if you want a human readable summary of the job setup, pipe the output of your `bratmain' job to a file, and you got it all. In short, the log files are all you need if you're running your `personal' jobs. Use what ever filing system you like for ASCII files: in a personal MySQL database, in a directory structure, ladida. But I think we want something stronger than that. I think what we want is a way to look up various stuff in an consistent way. That is, questions like: * What passes has been performed on run number ladida? * What script created this file? * When was this file created? * What calibrations went into the creation of this file? * Who's this idiot that didn't turn on feature XYZ? * ... For that, you need a database. > b) thus as a secondary mechnism that invokes some kind of storage of what > was done is a USEFUL concept. Bjoern and I did in fact also discuss > instead of a structure storing the 'script' as I belive you mention - and > if this things are labelled/named this would be a better documentation > than what we have i.e. none at this point together with any analysis. The > implementation may be different by is essentially the same namely that > EVERY settable parameter is stored in a human readeable file. Well, if a module does not output that in it's Print member function when invoked with the `D' (`D' for `Details') then it should be fixed, and the responsible person hit in the head with a large newspaper (hi David :-), preferably `Søndagsberlingeren' (a _very_ thick sunday edition of a daily paper in DK - I doubt it could fit through any mail-slit or in any mail-box you may have unless you live in Buckingham Palace :-) And why bother to write a program that parses the `human readable ASCII log' to make a script - it;'s so much easier to do emacs Script.C M-x brat-config-skel <type in the modules needed> After all, all the information is there in the log file and it's not that hard to write the module names, and ladida. But if you insist, use Perl - you can probably turn it into a 1-liner :-) Also, if the `setter' member functions names does not give enough information to decipher the meaning of that parameter, then someone should be hit hard one the head with a rolled-up newspaper! > I think this should be kept in mind and we should do what is needed with > minimal impact, resources -, My point exactly - why design something new if what we got may be modified slightly to do the job - and especially as it does it The Right Way(tm). > but let us continue the discussion and lets us hear from more > people. > Ok, I really only wanted to write a few lines - in my wildest :-) 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 | | [1] http://www.aw.com/catalog/academic/product/1,4096,0201633612,00.html [2] http://www.hillside.net/patterns/
This archive was generated by hypermail 2.1.5 : Wed Dec 11 2002 - 21:41:12 EST