Ian, I am working even as I write to populate afs on rh7.2 stuff. The hall probe stuff is for the very near future, but all is not decided quite yet as I think one would not use it for last years data given the reasons you indicated. So there are a few decisions to be made as to how to handle that seamlessly. As to who will do it, I anticipate Ramiro will supply me with a recipe for calculating fields given the hall probe reading and I will implement it within a short period of time. I hear it will be a week or two before they can get the measurements for D2 and D5 because of something going on in the IR or something like that. Regards Kris Ian Bearden wrote: >Hi Kris, >Can you also update BRAT on AFS? I'd like to test your changes:-) > > I have a question about using the Hall probe data for the magnetic field. >Is this something that is for the future, or is there a plan to use this for >last year's data? If so, I think we have to be really careful, since the >Hall probe gave spurious readings for D3 and D4 (at least for the few runs >that I checked back in October...). I also guess that at some point we have >to have a better description of magnetic field than the present one. If >this is true, are there any ideas about how to do this and who might do it? >Cheers, >Ian > >>-----Original Message----- >>From: owner-brahms-dev-l@bnl.gov [mailto:owner-brahms-dev-l@bnl.gov]On >>Behalf Of Kris Hagel >>Sent: 16. april 2002 17:34 >>To: brahms-dev-l@bnl.gov >>Subject: Changes to BRAT >> >> >>Hello, >>I have committed some changes to the BRAT repository. They are >>semi-major (internally; you should notice no functional change), so the >>revsion number was bumped to 2.3.8 >> >>Changes committed. >>brat/db/run >>1. Add and implement BrDbConditionsKeithley. This is a general class >>for those tables in the RunDB. To get data for specific measurements >>(ie Hall probe values), it is necessary to know which channel of which >>unit has the measurement you are interested in and select on that. >>2. Modify BrRunsDb and BrRdbmRunsDb to implement access to >>BrDbConditionsKeithley >> >>brat/db/geometry >>1. Major surgery on MySQL mode of BrGeometryDbManager to reflect more >>the style of other db managers. In particular it is now possible in >>MySQL mode to do geoDb->Update() and the detector volumes will be >>updated according to which run has been selected. Much of the code for >>building detector and magnet volumes in MySQL mode has been moved from >>here to the detector and magnet volume code. No change in functionality >>and it should be COMPLETELY backward compatible with no changes >>necessary to existing code. >>2. Major surgery on BrDetectorVolume. Change to reflect changes to >>BrGeometryDbManager in MySQL mode. In particular, the access of the Db >>is now done from here. Also, add Update() method which gets used from >>BrGeometryDbManager. >>3. Major surgery on BrMagnetVolume. Change to reflect changes to >>BrGeometryDbManager in MySQL mode. In particular, the access of the Db >>is now done from here. Add Update() method which gets used from >>BrGeometryDbManager. >>4. Imlement a list of hall probe readings in BrMagnetVolume. This is a >>TObjArray of BrDbConditionsKeithley objects which were selected based on >>the start and end time of the selected run. The field will be set to >>the field corresponding to the first hall probe reading. The routine >>that does this is currently empty. The field is still set according to >>the current as before. Once I have the calibration from Ramiro and we >>decide exactly how this is to be done as well as how to handle analysis >>of runs before the hall probe reading was implemented, this routine will >>be filled and will actually set the field to the field that corresponds >>to the hall probe reading at the given time. REMEMBER, for the time >>being, the field is still being set according to the current reading. >> >>brat/util >>1. Beautify the ostream output of BrVector3D and BrRotMatrix. >> >>Enjoy these new changes. Enjoyment is defined for the moment as not >>noticing them. If you notice something behaving different, let me know >>ASAP. I have tested extensively, but you never know. >> >>Regards >> >>Kris >> >> >
This archive was generated by hypermail 2b30 : Tue Apr 16 2002 - 15:47:26 EDT