From: Flemming Videbaek (videbaek@sgs1.hirg.bnl.gov)
Date: Mon Dec 09 2002 - 08:49:18 EST
Hi Djamel, Now I get your point. It is certainly true one could make a 'default version' of gbr2c.f that is included in the code. I believe that all the vector stuff i.e. setting debugging flags has to go , unless one add a bit more coding) - but one could keep a parallel version in (with different subroutine entry names) for that purpose(and it could be erated from the same basic code). I will look into this - Flemming ------------------------------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax 631-344-1334 e-mail: videbaek@bnl.gov ----- Original Message ----- From: "Hironori Ito" <hito@rcf.rhic.bnl.gov> To: <brahms-dev-l@bnl.gov> Sent: Sunday, December 08, 2002 7:45 PM Subject: Re: OSCAR reading (was Re: rotating event with brag) > gbr2c.f is already brag/run directory. And, not only they should always > sync with a version of brag, it "must" sync with a version of brag (and > also brat). This is certainly true when I change the format of > breg/brag ( and BrGeantInput or something) while back to incorpolate the > event plane and other info. > > > Djamel Ouerdane wrote: > > >I have another question about brag. > > > >Why the gbrc2.f routines are not incorporated to the brag source directly ? > >The way it is now introduces possible source of errors especially for > >newbies (gbr2c.f should always be in sync with brag but a user can > >sometimes forget that the latest version should be picked up from > ><install-dir>/share/brag and use an oudated version in his(her) working > >dir). Christian agrees about importing these routines, maybe somewhere in > >gxuser.F ? > > > >Djam > > > > > > > > >
This archive was generated by hypermail 2.1.5 : Mon Dec 09 2002 - 08:47:31 EST