Hello,
I have been working to implement DB access for our detector geometry
parameters. In the current analysis, we have ASCII files (ie
5and40.geo, 5and40.mag) and we have cumbersome statements in perl
scripts that have many if statements which decide what file to use for a
given reconstruction job. In addition, I could imagine that I (no one
else I am sure) would use the "wrong" version of a file as there are
many of these running around in different directories.
.
Having talked about having this for some time, but not yet having the
time as well as not having decided yet the exact philosophy to use,
after a short discussion with Flemming I implemented classes that are
described in the following. I kind of picked a philosophy and
implemented it to start a discussion. The basic philosophy is that the
detector tables specify the position of the detector on the platform and
then there is a platform table that specifies the spectrometer angle.
In short, the classes allow us to read the detector geometry definitions
from our MySQL DB ala Christians DB framework. The BrGeometryDbManager
was also modified to have a MySQL mode which when selected uses the new
classes to construct the traditional BrDetectorVolume and
BrMagneteVolume objects for use in the analysis codes as before. I
should note that the default mode is still ASCII read that we have had
for a long time, so if the MySQL mode is not selected, things still work
as before.
Here is what I have implemented and files that are changed:
1. Made a Platform position table (BrDbPlatformPosition) which specifies
angle of platform (as well as position which is defaulting to (0,0,0),
the nominal vertex right now). This has a name (ie FFS, BFS (not used
now), or MRS) and a run #. There is expected to be an entry for each
run. One could perhaps specify a start time instead of a run # and this
is something that might be iterated. In any event, there would be an
entry in the DB at least every time the platform is moved.
2. Made a Detector volume table (BrDbDetectorVolume) which specifies
position and angle relative to the platform. This has a starttime
(specified by unix time; perhaps it could also be run #) and there is
expected to be approximately one copy per year or even less if we don't
move detectors on the platform.
3. Made a Magnet volume table (BrDbMagnetVolume) similar to
BrDbDetectorVolume but has some extra features of magnets. I at first
thought to inherit it from BrDbDetectorVolume, but putting that in the
DB is then problematic, so I just made it standalone. I will revisit
having it inherit from BrDbDetectorVolume.
4. Modified BrGeometryDbManager:
a) Put a flag so mysql mode could be specified.
gGeoDb-?SetDbModeMySQL(). If this is not set, it acts just like it did
before. The default mode is not mysql. We can change that once we
decide to migrate.
b) Put extra methods which build our current BrDetectorVolume and
BrMagnetVolume from BrPlatformPosition, BrDbDetectorVolume and
BrRunInfo. That way, you get the platform position (and current and
polarity in the case of magnets) out of the run DB which I assume has
been verified to be correct. These extra methods are triggered only if
MySQL
mode is selected.
5. Added constructors to BrDetectorVolume and BrMagnetVolume to specify
only the size, origin and rotation angle. This eases the construction
of these classes in the BrGeometryDbManager.
To use this once the data is in the DB, one simply uses the following
BrMainDb *mainDb = new BrMainDb(...); //same as
everything
BrRunsDb *runDb = mainDb-?ConnectToRun(...); //same as everything
BrGeometriesDb *geoDb = mainDb-?ConnectToGeometry("brahmlib"); //new
BrRunInfoManager *runInfoManager = BrRunInfoManager::Instance();
runInfoManager-?Init();
runInfoManager-?Update(2482); //select run 2482 for test
//start up our geometry DB manager
BrGeometryDbManager *gGeomDb = BrGeometryDbManager::Instance(); //as
before
gGeomDb-?SetDbModeMySQL(); //new to select MySQL mode
BrMagnetVolume *mag =
(BrMagnetVolume*)gGeomDb-?GetDetectorVolume("BrMagnetVolume","D1");
This will make a BrMagnetVolume for the position, current and polarity
of run 2482.
All of this is mostly placeholder for now as I put it in to start
discussion. It is compiled and linked along with the other classes,
however. As mentioned before, if MySQL mode is not selected in
BrGeometryDbManager, it will behave as before. I have tested to make
sure that I didn't break anything. Hopefully my test is correct.
Regards
Kris
This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 16:25:12 EST