Changes between Version 5 and Version 6 of DatabaseBasedAnalysis
- Timestamp:
- 08/03/18 17:15:21 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DatabaseBasedAnalysis
v5 v6 9 9 First, you need a user. For the moment, a user 'fact' is available with the standard password. The user 'fact' is allowed to connect from everywhere if an encrypted connection is used. Usually, all reasonably recent mysql clients are using encrypted connections. So in most cases, a simple should be enough 10 10 11 {{{> mysql -C -h ihp-pc45.ethz.ch -u fact -p }}}11 {{{> mysql -C -h ihp-pc45.ethz.ch -u fact -p factdata}}} 12 12 13 13 To enforce encryption, --ssl (oder clients) or --ssl-mode=REQUIRED can be used. If you have problems with the connection, you can also try --protocol=TCP. … … 29 29 The mysql call would now look like 30 30 31 {{{> mysql -h 127.0.0.1 -P 10000 -u fact -p }}}31 {{{> mysql -h 127.0.0.1 -P 10000 -u fact -p factdata}}} 32 32 33 33 Note that you need to use the IP address instead of localhost, otherwise the mysql client tries to use a socket connection (which will fail). You could also use --protocol=TCP. … … 47 47 You can now do 48 48 49 {{{ISDC> mysql -h localhost -P 10000 -u fact -p }}}49 {{{ISDC> mysql -h localhost -P 10000 -u fact -p factdata}}} 50 50 51 51 Note that you need to use the IP address instead of localhost, otherwise the mysql client tries to use a socket connection (which will fail). You could also use --protocol=TCP. … … 56 56 57 57 A convenient way to retrieve data is the ''rootifysql'' tool which is part of the FACT++ package. More details can be found either calling it with the --help option or at https://www.fact-project.org/logbook/showthread.php?tid=4192. The same access rules as if the native mysql client is used apply. 58 59 To simplify the usage, it is wise to write a rootifysql.rc file with the following contents: 60 61 {{{uri=fact:password@iph-pc45.ethz.ch/factdata}}} 62 63 The following tutorial assumes that such a file exists. 58 64 59 65 == Other alternatives == … … 71 77 For data selection only run-wise information should be relevant which are stored in the table '''RunInfo'''. The reason is that if you select data on a more fine grained level (e.g. event-wise zenith angle), right now there is no easy method to determine the corresponding observation time. So whenever data is selected event-wise make sure that you do not cut the data in a variable which cuts out events systematically and not randomly. For example, an event-wise cut in zenith angel usually keeps or discards two consecutive events because their zenith angle is correlated. For a cut in any image parameter (Width, Length, Size, ...), the result on two consecutive events is random because their image parameters are not correlated. 72 78 79 As an example we analyse the Crab data from our public sample (01/11/2013 - 06/11/2013). 80 81 Let's first have a look at the total observation time of all Crab data in this period: 82 83 {{{ 84 SELECT 85 COUNT(*), 86 SUM(TIME_TO_SEC(TIMEDIFF(fRunStop,fRunStart))*fEffectiveOn/3600) AS EffOnTime, 87 MIN(fZenithDistanceMin) AS ZdMin, 88 MAX(fZenithDistanceMax) AS ZdMax 89 FROM 90 RunInfo 91 WHERE 92 fSourceKey=5 93 AND 94 fRunTypeKey=1 95 AND 96 FileId BETWEEN 131101000 AND 131107000 97 }}} 98 99 The result (in mysql) is 100 {{{ 101 +----------+-------------+-------+-------+ 102 | COUNT(*) | EffOnTime | ZdMin | ZdMax | 103 +----------+-------------+-------+-------+ 104 | 435 | 32.53992354 | 6.36 | 67.89 | 105 +----------+-------------+-------+-------+ 106 1 row in set (0.01 sec) 107 }}} 108 109 So we have 435 data runs from Crab with a total effective observation time of 32.5 hrs in a zenith angle range between 6° and 68°. 110 111 73 112 == Data retrieval == 74 113
