Hi Kris, Flemming, et al, On Wed, 12 Dec 2001 11:19:45 -0500 "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning "Re: Upcoming BRAT changes": > Hej Christian, > > This looks like a nice set of changes to implement, and makes the > meaning of run/job/lecl much clearer. Just one comment - do you > have to do changes in the geantinput module too ? I can certainly > see have to read multiple files of those to get enough statistics ? The changes are mostly in BrIOModule, since that's the module that deals with multiple files. Subclasses only (fortunately) deal with single files. In fact, BrEventIO should really be spit into two sub-classes: one reading, and one writting! But that's outside the current scope. The BRAG output input (read it again - it does make sense in some odd way :-) is the only thing I need to test. Otherwise it looks good. It has to do with what kind of status the module sets. I'd like to point out, again, that output modules does not gain _anything_ from this - it simply doesn't make sense. If that's a problem, well too bad, I'm not going to implement that - takes to bloody long, and the pay off is to low - maximising the efficientcy function, to speak in (unpopular?) tradidional economics tounges. The changes should of course propegate to BrDbUpdateModule - I'll work with Djam on that. On Wed, 12 Dec 2001 12:01:23 -0600 Kris Hagel <hagel@comp.tamu.edu> wrote concerning "Re: Upcoming BRAT changes": > Christian, > The changes you propose sound good. I especially like the BrAppXXXOption > being able to have multiple values. I had been frustrated with that > limitation and at one time had thought to launch into making it happen > before finding another bandaid. This will allow some cleanup elsewhere. That change was kind of fun, since you hav to deal with deault values being overwritten. It worked out in the end, at the expense of some clarity, but at this simple level - who gives a s**t. What do you think of the BrModule::Debug and BrModule::Info idea? Ayway, I'll probably submit the changes Friday, baring no complains from fellow collaborators. It's amassing how much time you have when you're waiting for data from the quasi-stable CRS, especially when jobs get killed in the middle of absolutly nothing. Mind you, processing one 100K run with only the TMA, SMA, and BB in takes about 10 min. Seriously, the CRS is not at all optimal, and I think implementing a schedular on top is a bloody waste of time - RCF should provide that - and they should provide a search engine for our mailing-list archives too! Now, please! Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Wed Dec 12 2001 - 14:01:11 EST