Luminosity DB Report - E's Test Links

Test links for luminosity test data:

1. 3829969,3756333,4467840-4467850
2. 1139440-1139450 - (early A) - Run 151817 (April02)
3. 3536160-3536170 - (late A) - Run 196584 (just before Fall 04 shutdown)
4. 3737320-3737330 - (early B) - 12/7/2004
5. 3756470-3756480 - (late B) - 12/19/2004
6. 3759350-3759360 - early C - 12/19/2004
7. 3921400-3921410 - late C - 3/17/2005
8. 3921400-3921410 - early D - 3/17/2005
9. 4317920-4317930 - late D - 10/20/2005
10. 4317945-4317955 - early E - 10/20/2005
11. 4536190-4536200 - late E - Spring 2006 shutdown (2/22/2006)
12. 4536190-4536198 - EXPOSED_LUMS where EXP_LUM_VME < 0
13. 3829969 - LBN_TRIGGERS.L1_LUM_VME is null (and DL.del_lum_vme, EL.exp_lum_vme)

14. all these above lbns
    
    
15. 5002000-5002054 - some Run 2B (E')
16. 5002057-5002100 - some Run 2B (F)
    
    
17. all these above lbns plus some Run 2B (E' and F)

Operations Reports with problems:

• Run ?runs=196584 -- this run report takes a LONG time, then CRASHES with no error.
• Run ?runs=211213 -- This report CRASHES -- it is the first run officially using VME electronics.
• Store 4666 ?stores=4666 -- this should be a STORE report, not a RUN report (there happens to be only one Run in this Store) The Run report takes too long. I hope the Store report is faster.
  SELECT STORE,COUNT(*) FROM RUNS.RUNS WHERE STORE >10 GROUP BY STORE ORDER BY COUNT(*);
• Date 09Feb2004
  needs speed up -- reorder to start printing some results faster so the user is not sitting staring at a blank screen for over 2 minutes (like the Store report).
  why is this day 28 hours long ? (need to just define what this time is)
  why does this report require 3555 queries to complete ? (see suggestions below on making reports faster/better)
• Date 15Oct2005 -- this Daily report is painfully slow requiring 6.2 minutes! to complete with 1442 queries). This day is only 12.1 hours long (same comments as above and below).
• MultiRun report first table too wide. I suggest to make it narrower and more readable:
  • Put Start and End Date/time in same column so they align (print them separated by a carriage return <br>) and can be more easily compared.
  • Do the same with the Start and End LBN.
• Suggestions for making reports faster/better:
  • Do not wait until everything is calculated before starting to print (daily report for example).
  • Print faster parts of the report first (if it makes sense). I know the order was determined by the online report examples, but we can reorder and still compare.
  • Always use a where clause: using '=', '<', '>' conditionals before 'LIKE' or 'IN' conditionals (there is a speed difference).
  • Goal: all reports should try to use < 100 SQL queries.
  • To see the queries,
    • set DEBUG=1 (to see them in the html source).
    • Set DEBUG=2 to have them printed unhidden on the report html.
  • Avoid queries by individual LBN or LBN_TRIGGER (use the WHERE clause to get all the LBNs needed for all triggers and then sort).
  • To reduce the number of queries, form more general queries with a reasonalble WHERE clause and sort results in python. Make sure your sorting in python is efficient or the same performance problem will result.
  • Use oracle functions like SUM and COUNT with the GROUP BY clause if you are querying for a result you can directly use. We are already using some of those functions.
• Trigger List ?triggerlist=JETTEST-4.00
  -- Good red message on the bottom of the report, but would be better to have it in the table.
  why is there no information in the delivered_lums table during store 3681 (for runs 195708, 195709, 195711, 195714, 195718, 195719, 195723)? Is there data missing from the database ?

DATA to be fixed or understood:

• For LBN 4536190,
  1. why is EL.EXP_LUM_NIM > 0. for tick_num and eg_num, but DL.DEL_LUM_NIM = 0.
  2. why is DL.DEL_LUM_VME = 0 for TICK_NUM=0, but it is > 0. for some individual ticks.

Run 180849 (lbn 2639206-2639221) is in the lbn_triggers table,
  a official/zero_bias_3L1L2L3_1out-1.00  (NOTphysics) run.
Run 180850 (lbn 2639211 - 2639223) is not,
  a calibration/cft/calib-0x53-1.1  (NOTphysics) run.

There are no lbn_streams for either Run.
This LBN report for this LBN Range covers both Runs.

Have we excluded certain types of Runs from the database?