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