Present: Fuquian Wang, Li Qun, Eric Hjort, Peter Jacobs, Hans Georg Ritter, Raimond Snellings Peter Jacobs, Iwona Sakrejda, Roy Bossingham, Doug Olson On the phone: Dave Hardtke, Howard Wieman 1. Analysis of the December Data Iwona with help from many people (Bill, Eric, Tonko, Blaire to mention just few) pulled together a list of available data files and conditions under which they were taken. The list can be see from: http://www.rhic.bnl.gov/~sakrejda/tpcsoft/crdec99/data.html Bill Love based on anlysis of laser data prepared a list of calibration constants (offsets, drift velocity etc). These constants were put into parameter files with appropriate timestamps. Yuri Fisyak put together a mechanism that based on time of the daq file allows to pick up a params file with coresponding calibration constants. Currently Fuqiang is testing the solution (first results are positive - looks like the timestamp solution works). Eric and Fuqiang will do more testing and then release the chain for production and prepare a set of template QA histograms. Nu will then look at the resolution as a function of the ASIC parameters (we can modify them off-line). Dave will look at the dE/dx resolution Grazyna would like to repeat Ian study of momentum resolution. 2. Calibrations. Masashi will take over pulser Calibrations as Fabrice is heading towards graduation. 3. Reconstruction initialisation from the Data Base. Parameters that never change will be available on Init(). Parameters with time stamps will be available in InitRun(). InitRun() will only be called in the event loop, just before Make(), if DB parameters change. Thus Makers can have InitRun() function where they do re-initialisation if necessary (calculate derived quantities). For FORTRAN modules the situation is more difficult as there is no way for the time being to pass the information about InitRun() into them. Currently there is no time consuming processing done on init in these modules (a handful of arithmetic operations that will not contribute noticeably to the processing time), so they will be change to do this simple calculations, always and not only the first time they are called (compared to C++ there is still a large time advantage in FORTRAN). Roy pointed out that in the future more complex operations might be required so it would be good to have an option to check in a module whether a table changed or not. Doug Olson reminded that there used to be a possibility to do that. We could either have a function callable from FORTRAN or a word in the Table Header that carries that information. 4. DB parameters for simulations. There is a proposal to use a timestamp to pick up parameters for simulations. I append Jeff's e-mail that outlines it: We discussed the issue of access to time-stamped Db data in simulations. The issue is that some Db-data for simulations should be accessible via timestamps. One reason being that simulated data can be matched with real experimental conditions. But also, purely generic simulator running should procede with 'preset' timestamps so that the production operation run transparently. the proposal that came out of the discussion is as follows, Timestamped data is obtained during Make() where, in general, the real-data's timestamp is available. Then, to have the flexibility of timestamps for simulated data, the chain can make use of the St_db_Maker's overloaded setDateTime() method to "artificially" input timestamps for use by an St_db_Maker. This can be done by an intermediary "StClockMaker" inserted into the chain before the St_db_Maker. This StClockMaker sets the timestamp used by the St_db_Maker based on some yet unspecified criteria. The technical part of "StClockMaker" is pretty trivial; the "yet unspecified criteria" of determining the input timestamps is where the work comes in. Comments please. Thanks, Jeff That prompted a discussion on advantages of timestamps and tags driven by Peter. Essentially everybody agreed that both are useful and that tagging would allow for an unambigious selection of calibration constants and that on many ocasions we need to have several versions of a constant for a given time period, so the timestamp idea is ok, but the tagging is needed as well. Also Nu brougth up an issue of possible separation of data processed with different parameters. But then others argued (Dave, Howard) that there are parameters that change during the run and separating outputs from processing with fixed calibration constants might be unrealistic. Everybody will provide their comments, Iwona will gather them and forward to the infrastructure group. Next week we will have 30 min devoted to efficiency. A discussion will be led by Peter. We also hope to have some results from the cosmics. Also please send suggestions forother agenda items.