From: Bjorn H Samset (bjornhs@rcf2.rhic.bnl.gov)
Date: Wed Aug 20 2003 - 04:41:57 EDT
n Tue, 19 Aug 2003, Christian Holm Christensen wrote:
> > 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.
Then we agree ;-)
> 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?
Unfortunately, I don't think it has. We have the code that's in pc_app
which is the basis for most of it, but all the acc files that I know of
have been made with slight modifications. This is (amongst other things)
necesseary because Peters stuff is for AuAu only - we need more trigger
slats etc. for pp and dAu. Also, we've often discussed other ways of doing
the acc. that e.g. JH, Claus and Kris are working on, so I don't think we
can gather around a common fileset just yet. I share your vision for the
future, though...
> > accpt
>
> Erh, why not call it `acceptance'
Sure. I just went by the current CVS norm where the most recent dir is
called 'fldmap' ;-)
> > in CVS, with subdirs
> > accpt/bhs_acc
> > accpt/jij_acc
> > accpt/ds_acc
> > etc.
>
> Erh, the `_acc' is redundant, isn't it?
Partially. It's redundant if you check out and keep the entire
'acceptance', but not if you have e.g. your brahms_app/ch_app and then
want to keep just ch_acc close by. Both _app and _acc are actually
redundant, but I think they're handy additions. (It's not that much more
typing ;-)
> 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 :-)
All dir's that other people could want to access should contain a README
in any case, but a summary object would be nice too. Let's think about
that for the next code update.
> 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.
The only Bad Thing I see about CVS is that once you overwrite an acc file
(say you found a code bug or made an improvement) you really don't want
the prevoius one anymore, so 'concurrent versions' aren't really needed.
(Except when you find that your bugfix was also wrong ;-)
> 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).
I agree a database would be nice and probably better than CVS, but
currently we're not at the point where we can make one (see above). The
acc. code and standards are still in flux, so I'd rather work on
stabilizing that than making a db.
In the meantime, I still think CVS is a good option. Our data disks are
rather messy (a disc. on this is also going on, by the way) and
unfortunaltely prone to crashes (e.g. data07), but I really think we
should still have a common place for acc files. What do other people
think?
a) Keep acc files in brahms_app and/or home dirs?
b) Make a CVS dir?
c) Make a common dir on a data disk, with backup on two other data disks?
b and c are fine with me, but I'd like to avoid a (that was the whole
point...) I think a db is premature, but should be a goal.
Ping :-)
--
Bjorn H. Samset Phone: 22856465/92051998
PhD student, heavy ion physics Adr: Schouterrassen 6
Inst. of Physics, University of Oslo 0573 Oslo
\|/
----------------------------> -*- <-----------------------------
/|\
This archive was generated by hypermail 2.1.5 : Wed Aug 20 2003 - 04:42:52 EDT