Slides 10-December-2003

• I am keeping a list of which sets have been processed by GVerify.
• In order to keep track of what the 4-character GEANT volume name corresponds to, I made up this table of GEANT/CDF names. The Muon names are from development as of 26-November, the rest are from 4.11.2. Any additions since then are not reflected in the table.
• I had difficulties making the shim overlap go away, but I think I found all the references now.
• The overlap between snout iron pieces has curious aspects. This shows what GVerify thinks about the overlap between SSOJ and SSOA near the top of the snout. Somebody doesn't know where the iron is. Is it GVerify or evd?
  • GVerify doesn't seem to know how many parameters a TRAP has (it thinks 35!) Maybe the algorithm is buggy. On the other hand, when I write out by hand where I expect the thing to be (as coded!), it agrees with GEANT. Long ago I fiddled with the code to get rid of overlaps the display 'revealed.' (The snout code is complicated.)
  • Do we have a guarantee that the evd display is identical with the GEANT sees? We know that the silicon simulation is missing a lot of material, which is consistent with some kinds of overlapping of GEANT volumes.
  I don't know which is wrong here. I tried the exercise of cutting down on the number of detectors systems in CDF, to try to simplify the system, but of course evd expects that their pointers will be non-NULL and coredumps accordingly. I can fairly easily link up a GEANT program to paste two TRAPs next to each other and see if GVerify handles the system correctly. A messier job is to rebuild TYPES using the correct byte-order for a Linux system--but I need to do that sooner or later anyway.

  I'd like to try displaying GEANT directly from cdfSim by hacking in some calls to the graphics package. That may or may not work...

• I tried linking up a simple GEANT program that locates 2 TRAPs next to each other, and duplicated the GVerify error. On closer inspection, I'm not sure that I'm using the sign of the angle in TRAP correctly in my drawing.
• 11-Dec-2003:9:45 It looks like GEANT accurately reflects the code in ImuContainer.cc, and evd does not. One issue may well be the interpretation of the sign of the angle joining the lower and upper centers in a trapezoid. And where you find one bug, look for others. In any event, I may have to put this aside for a while given the complaint about the position of BMU stubs in validation. (??Not sure what is going on!??)

  16:12 BMU_DtoE was giving the local coordinates instead of global.

Modified 11-December-2003 at 10:00

http://hep.physics.wisc.edu/~jnb/imu/26Nov2003

Previous meeting notes

Next meeting notes

Main slide directory

Please contact jnbt@hep.physics.wisc.edu if you have trouble accessing the information on this page.