1. What is different between Run 1 vs. Run 2? 1. More FPGAs than ASICs 2. CPU farms more optimally 3. L1: 1. L1Topo is new. 2. CTP: How many objects I found above a threshold were sent from MUCTPI and CMX to CTP. But now we need topological information like eta, phi to be sent to L1Topo. 3. It makes sense to trigger on relationships between objects and not just object. Is L1Topo to decrease L1 accept rate? That is not a problem. We have a maximum L1 accept rate coming from read out maximum which is 100KHz (In run1, it was 75KHz). 100KHz is the speed at which you can take data out of the detector i.e. FE -> Read-Out System. FE buffer has a certain depth which gives us 2.5microsecs. How many events can you read out and put in the pipeline? That is 100KHz. So how much should L1accept rate should be? It should be below 100KHz. 4. From Run1 to Run2, energy went up to twice implying rate for many interesting events went up by factor of 2. L1topo really matters for low energy B-physics for example where the rate increases by a lot. 5. Another change is we added isolation for electrons so to decrease the L1 accept rate 6. With L1topo, you can use Kalman Filter to get better MET at L1. 7. Calorimeter pulse: With MCM you can apply requirements bunch by bunch so you can correct the fact that the calo response is different for each bunch. 8. At the beginning of the fill, you have max inst. Lumi and you need to fit everything to the peak, so you need to reject more 9. Plots where some of them are linear and some are exponential. With more luminosity, then you have more to process in trigger and more to read outrigger 1. Between Run1 and Run2, the bunch spacing also changed!! Making matters worse. 2. New Small Wheel was added so that you remove beam remnants and other backgrounds. 3. Trigger menu changes: 1. Raising thresholds, why? Bandwidth is fixed but rate is higher so in order to make sure we did not increase thresholds much (by 2 GeV) you nede pedestal subtraction. 2. Why not dijet? Requiring second jet doesn’t buy you anything as if we had one jet, then it mostly will recoil against this. You have >75GeV cut on one jet events to reduce QCD background 1. GPUs? 1. Use multithreading in future but not for this as replacing our current farm will be extremely expensive. 2. High luminosity L1 will be 100KHz so we might need to look into alternatives 3. Sequential algorithms are needed for trigger where we need to do one step after the other. So even if we multithread, we will need to wait for all information to reach us to apply the sequential algorithm 4. There was problem with LHC and they had to run with unusual bunch spacing in 2017. At that point, we had to do many processes on same CPU which made it slower. 5. Will explore GPUs and multithreading for HL-LHC era 1. L1 trigger flow: 1. Figure 2 in 2015 trigger paper 2. TileCalo -> we did not talk about this? The HLT Calo includes TileCalo 1. TDAQ components -> overview. Went through the flowchart again. 2. CDF: 1. If you have trigger rate on fixed frequency, then you have current in magnetic field then it starts resonating and breaks wire bonds!! 2. Position of your trigger should be random in the bunches. Taking data during ramp up is difficult because of this 3. 2,8,12,24,50,100,500,etc bunches are filled during ramp up after each technical stop 4. Ask Maurice about this 1. Fast track finder in inner detector 1. We want to look at larger area and more stuff which implies we 1. Topological clusters are used everywhere in L1 and HLT. 2. Figure 17 b, shift/bias is because of some miscalibration