NA62 Software Framework: Oracle DB Integration The User’s Point of View Bob Velghe Université catholique de Louvain May 22, 2012 Background (I) "The DB system used to store data in NA62 will use relational technologies and will be able to contain all information needed to properly support data-taking and analysis."1 First implementation for GTK in the MC simulation. We store & retrieve all geometrical parameters from the DB. 1 NA62 DataBase requirements specification Background (II) C++ objects NA62 FW Coral library “SQL queries” DB server “SQL queries” MANY INSTANCES SQLite DB ONE INSTANCE Figure: General infrastructure, see "Summary of DB requirements and prototype status" by Sergey Podolsky (Software working group, December 14, 2011) for more details. Software Environment (I) Everything is built over CORAL 2.3.22 I GLIBC 2.5 I GMP 4.1.4 I Boost 1.48.0 I SQLite 3.6.10 I Xerces-C++ 3.1.1 I Oracle SQL Developer 3.1 I CMake 2.8.8 I PCRE 6.6 I and much more . . . Not exactly user-friendly ! Software Environement (II) The implementation in build on top of Sergey Podolsky work. There are two logical parts, I One is used to create the DB layout and load the attributes values. I The other is linked with the Monte-Carlo simulation and reconstruction code. It connect to the DB, setup the local cache and retrive the attributes values. How to proceed ? I Setup the software environement, I Define the database layout, I Practical Implementation Data types We use five datatypes for the GTK implementation Logical Type Type Unit Length VecLength FStrength Count String float std::vector<double> float long long std::string Meter Meter Tesla Attributes We divided GigaTracker in 10 subsystems: I I ... Magnet I I I I Station I I I fFieldStrength - FStrength (tesla) fDimensions - VecLength (m) fPosition - VecLength (m) fDimensions - VecLength (m) fPosition - VecLength (m) ... Only geometrical attributes at the moment ! % ! )% % $ ! % # ! ! $ ! % ! % & & & ! ' ' )! % * ( ! % % ! ! ! ! % & " & " ! ! ( &+ % ,) ,) - % - & " - & " - ! - ! % " " % * Dependencies Between the Attributes Figure: Dependencies between attributes. For instance fStationPosition depends on fDetectorPosition and fStationDimensions Practical Implementation (I) int GetAttributeValue(std::string ss_name, std::string attr_name, float & value, int id); float fMagnetFieldStrength[NMagnets]; for(int j=0; j < NMagnets; j++) { ret = mDS->GetAttributeValue("Magnet","fFieldStrength", fMagnetFieldStrength[j],j); ret = mDS->GetAttributeValue("Magnet","fDimensions", fMagnetDimensions[j],j); ret = mDS->GetAttributeValue("Magnet","fPosition", fMagnetPosition[j],j); } Practical Implementation (II) AddNewDataType("UID","long long","","Unique Identifier"); AddNewDataType("VecLength","multitype","m","std::vector"); AddNewDataType("FStrength","float","tesla","std::vector"); AddSubSystemType_stored("Magnet"); BaseSubSystemTypeManager * stm; // Magnet stm = GetBaseSubSystemTypeManager("Magnet"); stm->AddAttribute("DBID","UID",true); stm->AddAttribute("fFieldStrength","FStrength",true); stm->AddAttribute("fDimensions","VecLength",true); stm->AddAttribute("fPosition","VecLength",true); delete stm; Practical Implementation (III) ///////////// // Magnets // ///////////// float fMagnetFieldStrength; std::vector<double> fMagnetDimensions; std::vector<double> fMagnetPosition; // Magnet 1 RegisterNewSubSystem("Magnet"); fMagnetFieldStrength = -1.6678; // tesla SetAttributeValue("Magnet","fFieldStrength", fMagnetFieldStrength,0); fMagnetDimensions.push_back(fDetectorDimensions[0]); // m fMagnetDimensions.push_back(fDetectorDimensions[1]); // m fMagnetDimensions.push_back(2.5); // m SetAttributeValue("Magnet","fDimensions", fMagnetDimensions,0); fMagnetDimensions.clear(); Documentation I We prepared a short note with technical details useful for other teams, I There is a doxygen documentation associated with our implementation, I For interested people, I have a ready to use virtual machine (VirtualBox). Discussion What are the attributes we want to store in the database ? I Pixel thresholds I ...