Re: BRAG and gbr2c.f

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Tue Dec 10 2002 - 11:21:48 EST

  • Next message: Bjorn H Samset: "Proposing BRAT/bratmain addition (PLEASE READ!)"
    "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning
      BRAG and gbr2c.f [Mon, 9 Dec 2002 16:32:21 -0500] 
    ----------------------------------------------------------------------
    
    > Coming back to the issue of embedding the gbr2c routine into brag
    > proper, I do agree it is a good suggestions, and it is done., with
    > the following caveat's that arose from discussion with
    > Hiro. Sometimes we also use the comis routine to debug, and or play
    > around with stuff so I decide (executive decision) 
    
    Unilateral executive decision -> flames  in my experience, but this is
    not a flame though - in fact, it's an endorsement :-) 
    
    > to change the names of the rouitnes compiled into brag. 
    > So 
    > a) the names are changed from gbrxx -> gbxxx
    > b) the init_detector is renamed gbinit and is called from gb2c
    >    itself. So a typical sequence will be in your kumac file
    >
    >   >call gb2c
    >   >call gbfile('test.cdat')
    >   >analyze gbana 1000 10
    >   >gbend
    
    I think that's exactly what Djam wanted.   Couldn't we have a KUIP
    interface to? Say 
    
        /GEANT/USER/OPEN_OUTPUT <output file>
        /GEANT/USER/START_RUN  <run number> <max events> <step> <report>
        /GEANT/USER/CLOSE_OUTPUT 
    
    > All exsiting code and macro's that has call gbr2c.f will still work
    > (backward compability), but you can use the newer method's as
    > described. 
    > 
    > This involved adding gbr2c.F in src/user + creating some common
    > blocks (.inc) files. Not too bad less than 1 hour and it seems to
    > work. The setup.kumac files are changed to work with the compiled
    > gbana... 
    > 
    > Brags version is now 1.1.26
    > 
    > Not done at this point :
    > 
    > you cannot set debug flag as before e.g. vector/input debug 1 1 0 0
    > 0 as an example.
    
    Again, a KUIP command would be good 
    
      /GEANT/USER/DEBUG_FLAGS I I I I 
    
    > The makefiles (Makefile.am) should be modified such that a valid
    > gbr2c.f cal be generated from the gbr2c.F file basically by
    > preprocessing the .F file with a preprocessor flag BRCOMIS set and
    > then put it to some nice share/brag .. location. 
    
    Done.  
    
    This means that `run/gbr2c.f' does not exist anymore.  Instead, the
    file `src/user/gbr2c.f'  is generated from `src/user/gbr2c.F'  It is
    installed in `<prefix>/share/brag/' 
    
    Also, as we're all using fairly up-to-date systems with a fairly
    recent Automake, I decided (executive decision?) to take out the
    preprocessing step that was previously needed by the Automake to
    correctly handle the `.F' files.  If this causes you problems, update
    your Autotools. 
    
    Important:  In `include/event.h' had to change lines 
    
       real*4 bimevt 
       real*4 bphi
       real*4  sqrt_s, bmin, bmax, temp, flow_v2, pp
    
    to 
    
       real   bimevt 
       real   bphi
       real   sqrt_s, bmin, bmax, temp, flow_v2, pp
    
    as COMIS complains about a syntax error(?) at the ast `*'. 
    
    Also, I had to change `src/user/gbr2c.F' so that instead of 
    
            SUBROUTINE GB<name> 
    
    it reads 
    
      #ifdef GBRCOMIS 
            SUBROUTINE GBR<name>
      #else 
            SUBROUTINE GB<name>
      #endif
    
    to avoid clashes between interpreted code and compiled code.  My first
    instinct was to do something like 
    
      #ifdef GBRCOMIS 
      # define _GB(NAME) GBR ## NAME 
      #else 
      # define _GB(NAME) GB ## NAME 
      #endif
    
            SUBROUTINE _GB(ANA)
    
    Unfortunately the Fortran77 preprocessor does not recognise the
    concatenation operator `##', so I had to do it the more elaborate
    way.  
    
    I tested the following scripts, and they work:
    
      MACRO foo 
        geodef 
        geofin 
        call gbr2c.f 
        cards ukin 1
        kine 0 10 -180 180 0 180 8 
        call gbrfile('foo.cdat')
        call gbrend 
      RETURN 
    
      MACRO bar
        geodef 
        geofin 
        call gb2c
        cards ukin 1
        kine 0 10 -180 180 0 180 8 
        call gbfile('foo.cdat')
        call gbend 
      RETURN 
    
    
    Due to the current AFS problems at RCF, I have not been able to commit
    the changes.  I'll commit them tomorrow.
    
    The posting on the AFS problem is serious.  Please read it: 
    [Oh, I see Betty just forwarded that as well - well, repetition of
     important stuff is OK and even needed, so here goes] 
    
      # AFS Problems    12/10/2002
      Tue Dec 10 10:54:30 EST 2002
    
      We are currently experiencing problems with one raid box who had a
      failed controller replaced. It's highly possible that restoring from
      backup tapes will be necessary. We'll keep the user community posted
      on further developments. Meanwhile various areas in AFS will not be
      accessible. 
    
    If backup tapes are to be used, we must be very careful to check that
    all our changes are in fact in CVS.  That means, running 
    
      cvs -n update 
    
    and checking the changes it reports, and doing so in minuscule detail,
    before doing any commits or updates.  
    
    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 Dec 10 2002 - 11:22:36 EST