Home » Groups » STAR Protected

ageParser.py version 0.0.1

Updated on Mon, 2010-05-24 18:58. Originally created by jwebb on 2010-05-20 10:00.
We have developed a parser which can read in the agstar geometry files, recognize almost all of the syntatical elements, hold the data and algorithmic elements in python data structures, and output the code in a new format.  In this alpha version, we are able to:
 
(1) successfully parse the ecalgeo6.g geometry file,
(2) export the file back to its native agstar format,
(3) compile the exported file and generate a TGeo geometry using g2root,
(4) parse and export the exported file 5 times,
(6) find that there are no differences (up to whitespace) between the 1st and 5th iterations
 
The figures below show the original AgSTAR geometry (iter 1) and the exported geometry (iter 5),  I do not label which is which, but one can infer which was generated by the original geometry and which from the parsed geometry by the filename.
 
 
Conclusion:  The ageParser is at a beta level where it can recognize most, but not all of, the agstar language expressed in our geometry files.  The QA loop is closed after the first iteration.  Meaning that the exported geometry is identical to the input geometry after the first iteration.  Due to different formatting choices made by users it is difficult to compare to the original file.  One should perform a geometry differential regression test in order to compare the original to the export. 
 
We can, however, compare the original to the export in the TGeo files.  Here we find multiple issues, illustrated below:
$ diff --width=207 --ignore-case --ignore-all-space ecalgeo.C ecalgeo-export.C | less
258c258
< TGeoVolume *ELED = gGeoManager->MakeTubs("ELED",med11,74.62763,206.5812,0.2285,-15,15);
---
> TGeoVolume *ELED = gGeoManager->MakeTubs("ELED",med11,74.62763,206.5812,0.2785,-15,15);

The common thread is that they are all TUBS.  Quickly found and elminated this bug (the dictionary which describes TUBS parameters for the backend was lacking the 'dz' arguement.) 

The loop is closed in terms of purely geometric construction (i.e. everything which TGeo understands).

List of Geometries which Compile / Run / Render in TGeo using ageParser 0.0.1

1. EEMC -- ecalgeo6.g
2. BBC  -- bbcmgeo.g
3. PIPE -- pipegeo.g
4. MUTD -- mutdgeo3.g
5. PIXL -- pixlgeo3.g
6. BEMC -- calbgeo2.g
7. TPCE -- tpcegeo2.g (old, but still,  woot!)
 

List of Geometries which Compile but have Run Time Errors

1. SCON -- scongeo.g
   + can be overcome by setting svtg conever = 3, autoconfiguration from geometry.g
2. MAGP -- magpgeo.g (something lost in translation...)
 

List of Geometries which can be converted to AgML, back to AgSTAR, and Compile / Run / Render

1. EEMC -- ecalgeo6.g --> ecalgeo6.agml --> ecalgeo6.g
2. BBC  -- bbcmgeo.g  --> bbcmgeo.agml  --> bbcmgeo.g
3. PIPE -- pipegeo.g  --> pipegeo.agml  --> pipegeo.g
4. MUTD -- mutdgeo3.g --> mutdgeo3.agml --> mutdgeo3.g
5. PIXL -- pixlgeo3.g --> pixlgeo3.agml --> pixlgeo3.g
6. BEMC -- calbgeo2.g --> calbgeo2.agml --> calbgeo2.g
 
TPCE will not compile at the moment, as Mortan data statements are not quite rendering into AgML...
      DATA Mntcylht/30./
      DATA Mntcylid/16./
      DATA Mntcylod/20./

      translates to

      <Data variables="['Mntcylht']" values="['30.']"  />
      <Data variables="['Mntcylid']" values="['16.']"  />
      <Data variables="['Mntcylod']" values="['20.']"  />
... The Mortran backend is a bit more sophisticated than the AgML backend for data statements, so we need to massage the input to AgML to remove list syntax.

After a bit more tweaking...

TPCE compiles (almost) and renders in full gstar --> agml --> gstar loop.  The exception is that the list of hits is not processed correctly (likely because the TPC uses a user-defined function for hits, and I have not setup code to recognize / handler this case).

05/24/2010

Most geometries can be parsed now.  Exceptions for geometries which include subroutines, and mortran IF ( logic ) { ... statements ... }

Notes:

1. btofgeo6.g -- POSITION commands end up being too long for Mortran to handle.  Need to improve the PrettyPrinter such that long statements are detected and split in a sensible (perhaps context sensitive) fashion.  The btof_config variable is declared as a real, but is expected (by a format statement) to be integer, causing a runtime error.  Otherwise, btofgeo6.g compiles and produces a geometry.  Although visualization is... odd.
 
2. fhcmgeo.g -- compiles fine
 
3. ftpcgeo1.g -- Nearly compiles.  In the POSITION FROM blah=blah ... statement, the trailing _ needs to have a space between it and the last token... or replace it with a ','...
 
4. gembgeo.g -- Looks like it compiles.
 
5. fgtdgeo2.g -- several issues with fortran 77 vs mortran continuation syntax, but will compile when corrected
 
6. phmdgeo.g -- compiles and runs.
 
7. supogeo.g -- well... whatever it is it seems to work... not sure what exactly it does, as it looks liek its just some brackets...
 
8. vpddgeo2.g -- there is an issue with attribute lists in SHAPE statements.  The behaviour of continuation characters at end of line is different if the cc is a '+-' versus a '_'... Need to sort this out.
Groups: