Test #1, detailed history

This test is built in a directory /d0sgic/data1/para/adamo_tests/test1. The input data file is test1.dat.

• Build the infrastructure
  • define the table Object1.
    
  • Need to define EvKey table to differentiate events.
    
  • Define a DataFlow to consist of the Object1 object only and construct the DDL file test1.ddl.
  • run MAD, using test1.kumac to produce auxiliary files INITAP.f, CREOBJ.f, all include files and produce the report file, test1.rep.

  Problems encountered:

  • cannot define members to be of double precision type. Use REAL for now.
  • it would be real nice to define an aggregate (REAL,INTE,DOUB) as a new data type and define the table in terms of such a derived data type.

• convert the input file to a GAF. There are following files:
  • test1_main.ftest1_main.f, the main program. It opens the input file test1.dat and creates the GAF, test1.gaf.
  • txt_toadamo.ftxt_toadamo.f, routine to read the data and create entries in the table Object1
  • link_test1link_test1, a script to compile and link. It requires CERNLIB (setup cern) to be set up. It produces an executable test1.x.

  After this step we have a GAF data file, which can be browsed, for example using ti.

• create a new DDL file:
  • add new table Object2 for pairs of Object1
  • define new event type (== DataFlow) containing Object1 and Object2

  Run MAD using test1_1.kumac to produce the auxiliary files and to produce new report.

  NOTE:He have now new versions of CREOBJ.f and INITAP.f. "Old" program, test1, can be linked against the new version as well.

• create a program test1_1_main.f to read the GAF file, perform 'analysis', create new table Object2 and store new events in a new GAF file. The new GAF file is a random acces, RZ file.
  This program is linked using link_test1_1. This program produces a GAF file test1_1.rz. Its output file shows a three events entered into this file.
  The new GAF file can be browsed using ti, as before.

  Problems:

  • any operations involving multiple rows of the same table (or multiple objets of the sane type) is a bit awkward due to the common block interface: one has to make local copy (copies) of entries needed for further operations.
    This problem is intrinsic in the standard Fortran environment.
    Possible solution (?): notice that most of the modern Fortran compilers do support structures and pointers. For machines having such a capabilities one can define a structure of a requested type. User program can instantiate as many local copies of the structure, as needed for the problem. A new calling sequence, supplementing FETTAB/GETTAB passing a pointer would enable ADAMO to fill the structure in the user address space.

  • a potential problem, related to the above one: within a loop over the rows of a table one may invoke routine(s) which will themselves invoke FETTAB/GETTAB and hence overwrite the values in the common block.
    Solution mentioned above takes care of this problem too.

• create a program test1_2_main.f to read the latest GAF. This program loops over all Object2 objects, finds links to Object1 and prints out the values of Object1_aa members of the pair involved.
  The program is linked using link_test1_2.
  It's output is shown.