From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Tue Aug 19 2003 - 05:05:34 EDT
Hi Bjorn, Bjorn H Samset <bjornhs@rcf2.rhic.bnl.gov> wrote concerning Proposal: accpt in CVS [Tue, 19 Aug 2003 03:59:10 -0400 (EDT)] ---------------------------------------------------------------------- > > Hi dev'ils. I have a proposal that I'd like some feedback on: > > Currently, a fresh brahms_app takes up 114Mb, and over 50% of that > is acceptance files. Yikes. That's an awful lot of space to take up. Hmm ... Perhaps we need some better solution to this. > Still, this is only a fraction of the acc. files that I know are > lying around and that could be useful to other people than the > author. Hasn't the acceptance code sort of converged on something yet? If it has, why do we then have several, what seems like, several redundant sets? > We're at a point where more and more people are doing analysis, and > there's no sense in every one of us (esp. master students with too > little time) reinventing the acceptance wheel. I should think we had something standard by now. Is it in BRAT? Or Bdst, or whatever? > Therefore, for clarity and to clean up the very useful brahms_app a > bit, I suggest that we make a dir. > > accpt Erh, why not call it `acceptance' - after all, there's little reason for short cryptic names - we're mostly working on UNIX machines with more or less unlimited lengths of filenames, and practically no one is using Fortran4 with it's 6 character identifier limit. For the sake of clarity, why not spell it out (and remember to use <TAB> :-), which should also help the poor fresh master students. > in CVS, with subdirs > accpt/bhs_acc > accpt/jij_acc > accpt/ds_acc > etc. Erh, the `_acc' is redundant, isn't it? > containing the acc files and a README with a few lines on how they > were made and for what. Perhaps you should make some sort of summary object, in the files themselves, so that the data is never lost (unless you loose the files themselves :-) > (No, the examples are not random ;-) This way a new (or old) > analyzer can quickly find avaliable acc files and see who to email > to learn more about them. > > Thoughts on this? If you like the idea then I can make the dir. and > place my own stuff there, and then start nagging others to do the > same. (While following up on a few older promises I've made about > CVS...) Yes, I do have some thoughts on this (surprise!). I think leaving the acceptance files in a CVS directory is a Bad Thing(tm). We should think of sort other way of storing these, especially as a lot of people will use them same files over and over again. However, as I understand it, it's largely a read-once/job operation, with very few writes. To me, that sounds a bit like a database. It needn't be a MySQL calibration like database, but it's an option (after all, a histogram is just an array, or if you like, an image). Another possibility is to have a ROOTD server (with kerberos5 enabled) running on brahms-db0, and `acceptance calibrator shift leaders' can upload files to specific directories on that host, to make acceptance maps available to the whole collaboration. These files can be accessed like TFile* file = TFile::Open("rootd://brahms-db0.rcf.bnl.gov/acceptance/run005620.root"); for example. In fact, we could probably use the ROOT backend to BrDB (or what ever it's called) to do this. Of course, RCF has to OK opening the ROOTD port through the multiple firewalls. 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 19 2003 - 05:06:27 EDT