Minutes and Summary

Main purpose of the meeting: 2025 schedule, pO, OO, NeNe

LPC minutes 13th January

Present: Chiara, Chris, Catrin, Robert, Silvia, Paula, Federico, Silvia, Roderik, Brian Cole, Filip, Flavio Pisani, Gabriella Pasztor, Gerardo Vasquez, Giovanni Cavallero, Hiroaki Menjo, John Jowett, Jorg Wenninger, Lorenzo Bonechi, Maciej Trzebinski, Peter Steinber, Qipeng Hu, Riccardo Longo, Rosen Matev, Witold Kozanecki, Michi

LPC talk - schedule 2025, pO, OO, NeNe (Chris Young)

S4:

Witold: Not convinced that vertical downward crossing means positive x-angle. The sign of the angle should be given by the sign of the boost. 

Jorg: Downward boost means positive: B1 needs to go down, and B2 also.

Witold: I remember the opposite, we can take it offline.

Roderik: Downward at the IP would be a negative angle.

Jorg: Negative x-angle means that B1 is moving downwards, same for the other beam, so the beam is moving downward towards the IP, so the derivative is negative.

Roderik: If both beams are going downwards towards the IP, then it means that the angle is negative, you have a negative derivative of dy/ds.

Catrin: ATLAS for ZDC always asked for positive x-angle.

Brian: The way the ZDC is positioned assumes an upwards crossing, and we’d have terrible acceptance if it was not like this.

Chris: Let’s follow up offline. It sounds like we have different requests from LHCf and ZDC-ATLAS.

Filip: PPS can take data only when it is vertical in CMS, because of the switch that we have in 2025. But maybe the question is not what CMS-PPS wants (which would be vertical) but how important it is that PPS is in this run, since there is a conflict with the requirement of LHCf. We’re still waiting for a comment from their side about this.

Chris: Yes, I knew they wanted vertical if they wanted to take data, the question is whether they want to take data, and if we can have them both in vertical in PbPb, for example, and if the beam compensation is not such that we have to have them switched in these one. 

Roderik: To do vertical-vertical we need to have flat beams, because with the present beams and aperture, we cannot have vertical crossing in CMS with the present round beta*, you need a totally new optics in this case, which is not impossible, but it’d be quite different to the machine configuration. You’d need to step back in beta* which I think we don’t want, because then we lose in performance. 

Chris: Does that apply also if we want to get vertical in ATLAS?

Roderik: No, in ATLAS the beams are oriented in vertical, in CMS it is in horizontal. So the larger aperture is the horizontal plane in CMS and the vertical in ATLAS. These are the default crossing angles since the LHC design. If you want to go to the other side, you have to go flat.

For LHCb we are considering smaller b*, so they will not be identical to 2024. But x-planes and angles will be the same. With one exception: for OO and pO, we’re thinking of zeroing out the x-angle, in LHCb and ALICE, to gain luminosity. Since there are few bunches, very much spaced, there are no long range beam beam effects, and there is no reason to keep the x-angle. 

Chris: But for IP1, for ZDC, and LHCf it is important that there is a x-angle. 

Roderik: it is important to understand what x-angle you require for IP1: what is the minimum that you require. 

Chris: 145 urad. Last year we did 150 um, which is very close to what we want. 

Roderik: The same should hold true for CMS: we can zero out the angle to have a bit more luminosity. The plane then is irrelevant because it is zero. I even think that the last performance figures that were given assumed zero x-angle at all experiments. So it will be slightly worse if we put an angle. 

Chris: But then the ZDCs of ALICE, ATLAS and CMS would have a problem. 

Roderik: This we have to check: what is the x-angle they actually need.

Witold: I understand you can do zero x-angle in OO and pO for CMS, but the second bullet says that CMS wants the same plane for PbPb and OO/pO. Doesn’t this constrain what you do in pO and OO?

Silvia: Yes, this is what ZDC requested. From PPS, we still need a reply.

Chris: If ZDC is at zero, there isn’t a plane: the plane is undefined. 

Michi: how close is zero to zero if you put 10 urad?

Chris: I suspect they’d have lost quite some acceptance by the time you get to the 10 urad. But let’s see what they say. 

Roderik: Can one adjust the ZDC around the x-angle that we say, so that we can fix it within a range and you can adjust the ZDC?

Chris: For pO, LHCf dominates the settings. 

Catrin: Yes, but we install the ZDC on the other side.

Chris: Yes, then we need to have a x-angle because LHCf has no acceptance without a x-angle.

Lorenzo: To confirm: LHCf has a very very small acceptance, and only a small calo can catch the center of the beam. This detector can move vertically, and the small calo is at the bottom of the detector. So to extend the phase space is to move the calo as close to the bottom as possible, in such a way that we can catch the beam center at the bottom. This can be obtained only in the vertical plane, with downward going beams. We need downward going in such a way that we can lower as much as possible downward the detector to catch the beam center and measure with the other calo, moving the detector upward, the highest extension in transverse momentum, in forward rapidity. This is the way to maximize our acceptance. And the lowest position in which we can put the calo corresponds more or less to 145 urad for the half crossing angle.

Roderik: Is 145 the optimal, or is there a range around this where we can play?

Lorenzo: I think this is the optimal.  

Hiroaki Menjo: that x-angle that we used in 2022, that is the optimal for us to have a comparison to pp. I think it cannot be moved too much (compared to that).

Chris: 145 urad +/- something should be ok, but not huge amounts.

Roderik: We can assume 145, for this we have the freedom. 

Brian: If we keep it like this in OO, it’d be very bad. 

Chris: We will get to OO details a bit later. 

Robert: Running at an effective zero x-angle needs to be checked with ALICE ZDC, to verify the acceptance. I think it is only good between 50 and 100 urad. To be checked. 

Roderik: Yes, please, check, so that we put the smallest angle that the ZDCs can tolerate. 

Chris: But with the x-angle we cannot get a factor 2 (in lumi), so there’s no improvement in going to a lower x-angle.

Roderik: For ATLAS ZDC, with -145, you’ll get a very bad acceptance. 

Brian: Yes, we can move our RPD detectors, but the ZDC cannot move. Anything less than zero is a problem. Even zero is not optimal. Anything negative is an issue. With -145 we’ve lost most of the acceptance of the showers. It almost does not make sense to install the ZDC on the LHCf side, since it’d be so bad.

Roderik: But LHCf will take data only in pO. So if we’d change the angle between pO and OO for the ZDC, then it’d be ok since LHCf is not there in OO. This could be the best thing to do even if it’d take a few hours to do. 

Chris: We might need to keep the angles switched between the two runs. 

 

S5:

Catrin: What do you mean by “better performance”?

Chris: Generally, when things are wrong, when we go between fills, having longer fingers make things look better. The performance was checked also for a Chamonix presentation by Sofia where she included more sophisticated effects to derive the lumi estimate for different filling schemes, and she also found that they behave quite similarly, as from the LPC tool. So all in all, it seems that availability is what matters the most. From LHC side, they want to have some room to go beyond 1.6x10^11. 

Michi: We can keep fills a bit longer than optimal, but one has to consider that ~50% of the fills are dumped not by OP. So filling schemes that require longer fills to be at the max performance tend to be less performance, because ~50% will be dumped not by OP (withuot reaching the max length). So it is probably better to push hard at the beginning, since the end might never be reached. 

Jorg: All the numbers in the table are more or less equivalent within the errors.

Filip: But the bunch intensity is very different so you should be very careful comparing them.

Jorg: Yes, but we want to push the bunch intensity.

Chris: The idea of these numbers was to keep the heating at sector 78 constant, so the first three lines are the same heating in sec 78. So with respect to this, the three lines are the same. 

Catrin: Looking at the whole thing in a conservative way, we should ensure that availability is given. Do we want to add this? In some way it is written on the slide, maybe we should make it more explicit.

Michi: One further thing (agreeing that the expectations are fully within uncertainties): what we want to gain out of the last and half year is to prepare for High Lumi: from the machine side, it is worth pushing even if it costs a bit of lumi, since it is better to find out now if there are issues than after LS3. 

Catrin: Our statement was to maximize the total integrated luminosity in pp and PbPb, any risk associated with performance improvement should be conservatively evaluated to ensure they align with these objectives. I understand that this is the wish of the machine, but if we break something and we do not reach the lumi targets, this does not help.

Jorg: The point is that if we don’t push to find a limitation now instead of after LS3, this might impact the performance of HL-LHC (and HI-LHC is just a little LHC upgrade).

Catrin: There is surely no objection, but it should be done at a time when there is no risk to much anymore.

Chris: I’d say that we support the machine efforts to ensure that the HLLHC does not encounter problems at startup, by tests before the end of Run 3.

Jorg: On 21.01: For LBOC, the slides will be shortened compared to the ones for Chamonix and focus more on the different scenarios.

Chris: To be noted that we’re talking of 1.8, which was the target for Run 3, and nobody was worried that anything would go wrong. It’s not pushing beyond what was intended before now.

 

S9: 

Roderik: We have one day of proton ramp up (this is the light green day in the table) for oxygen then we switch to O and then we go back to proton. Would it not be more efficient to start with O?

Chris: If we wanted to save beam we could start with O directly, but I have not yet asked MPP.

Roderik: We can discuss but we will only aim at setup beam with O, so it is a different cycle anyway, different from the pp one, so I guess it might be inefficient to switch back and forth within the cycles. So we can ask Matteo if we can move the green day.

Catrin: For us it’d be better to have all the pp ramp up together because we might need to change detector settings.

Chris: The 3-bunch fill will go into collision and then it is dumped. So it’ll be very very quick, and I’d not even put it in the timetable if we’re just doing that.

Catrin: This is fine, but not for the 75.

Chris: This is why I’ve put this bullet point and we will ask MPP to see if the 75b should be moved after the special runs.

Roderik: On the machine side: request to have MD with Oxygen, which is not in the schedule because the O days are only for the physics program. This will be taken out of pp or PbPb MD (should be asked to MD people). We’re talking not of days, but just 1 or 2 shifts, but it would mean that the VdM program could then start a bit (maybe 1 day) later.

Chris: VdM people should anyway be a bit flexible since this is a quite tight plan, and if it takes a bit longer to take the data, then we’ll have to do that and the VdM will have to be flexible within a couple of days.

Michi: This was probably in the green box, but we have to see when we do the final validation for the VdM cycle, because this is also cycling 150 bunches and stable beams. This is unsafe beam and it will need the 3b or 3x12b fill before jumping to 150. This maybe can be done before, but not too much before. It might be in the block where you put the ZDC out and one has to see how the MD shifts and the availability of people. Depending on this, it could be done just before or a bit in advance, but it will have to be done at some point. It is not like a normal pp cycle so needs validation.

 

Paula: 0.5 nb-1 is the request from LHCb as for the other experiments.

Chris: This is quite ambitious, even for the other experiments.

Paula: This is the number that was always requested, also in the past

Federico: What is in the yellow report and that which is achievable are not always the same.

Chris: I will check what was said in the past.  

 

S10:

Roderik: With 1m b* in ATLAS, CMS will get a bit less because they are not levelled, but they should still reach the target.

Chris: If we skip the squeeze for everyone would this work?

Jorg: yes. While if you squeeze selectively, you make different squeezed and you need really dedicated setups. 

Chris: Then you need optics commissioning at 30 cm again (this is the value in pp).

Roderik: The 36 bunches with this intensity might not be good, we might need more intensity for instrumentation. Should be followed up. We probably need a bit more time for LHCf since we have fewer bunches colliding. To be discussed with Jorg and Matteo.

Chris: If we do 3 fills of 16 hours, we have many more hours in stable beams, and will have more flexibility.

Michi: 7x10^9 is quite ok, but there is burn-off. The limit will be somewhere between 2-3 x10^9 where you will reach the beam interlock.

Roderik: Yes, if we keep the fill 20h long, indeed then the burn off is quite large, and I am not sure we can keep this beam intensity.

Paula: Will the tables be updated?

Roderik: Yes, in the coming weeks with the latest assumptions.

Michi: Also the energy in the table (which is from 2021) will be 6.8 TeV while the table is 7

Roderik: There is a more recent table shown in Chamonix with 6.8 TeV, but there were zero x-angles which now we know are not good, so we should update. 

Roderik: To all experiments: tell which x-angles are acceptable to put down the final numbers.

 

S11:

Roderik: Important to know if ATLAS/CMS have a limit on mu for HI reconstruction (to get the centrality), to do the calculations.

Roderik: Longer time (39 hours in the slides) is driven by the fact that at the time of the estimate, it was assumed to keep a large x-angle and then we run out of aperture and we’d have to step back in b*. If we can use smaller x angles, even zero, the time might go down, because you might have not to step back as much in b*. So if people are interested, we need to check what is the crossing that we can take, what is the smallest crossing, and what is the aperture that is compatible with that. 

Chris: This comes to a complex question: if we want to have b* close to 0.5, we need to recommission the optics. If we want a b* of 1 m we probably don’t?

Roderik: We have to recommission optics for PbPb so have the corrections for that.

Chris: However, if we are at the lower energy then these will not apply so we would need to re-do it in this case.

Roderik: Also, we need to check where in the ramp we reach the 1 m. If this point is before the lower energy, then we can do 1m easily, if it is the other side then it is more complicated. 

Jorg: I need the exact number, but it is either just below, or just above. But the optics should be changed again. So the point may change. Probably we can arrange it such that (it is) at the squeeze and just before that 1 m, provided we know early enough what we want to do.

Roderik: I guess that if we operate at this intermediate point, maybe we want to check the optics also at this energy.

Jorg: I agree, but if it is at the same ramp just cut-off, it simplifies everything, and speeds up. 

Roderik: I would still expect that there is no zero optics commissioning.

Jorg: Agreed.

Chris: We can do pO at top energy, and OO at lower energy and higher b*.

Roderik: It will take more time to reach lumi targets. Probably another day for OO. 

Roderik+Chris: The issue is more the lower energy in OO.

Chris: Maybe less than the 2 days that we anticipated for setup.

Chris: Simulation of running at b* 50 cm and 1 m at low energy and high energy. But for pO we should be able to do it at the top energy. We don’t save anything by doing for both the same thing.

Roderik: Should be easy to switch between the two because you don’t have to change anything in the machine configuration. There might be some commissioning more to be done if you change the cycle in between the two.

Jorg: The minimum is check the optics, then recollide again, resetup the crossing to whatever value we end up… So maybe 1.5 shifts more? 

Chris: We have to re-set up with collisions with different x-angles anyway independent of the energy. So this is not lost time.

Jorg: Then it would only be the optics. Maybe 1 cycle of 8 hours?

Roderik/Jorg: Yes, more or less, with the uncertainty of 1 shift.

Roderik: We need to watch out: we discussed several things that could potentially make the program longer. We need to put everything together and then see to where we end up with in the end.

 

S12:

Chris: Will LHCb be at 1m? (in pO).

Roderik: This is the working hypothesis at the moment. 

Chris: Will LHCb be at 1 m while everybody else if at 1 m? At the ramp?

Roderik: Yes to the first, As for the second, most likely we squeeze LHCb more in the squeeze rather than in the ramp because of the worse aperture. You don’t want to stay at smaller b* at lower energy. The other experiments end up at 1 m b* at smaller energies than 6.8 TeV and the worry is that at 1 m b* at LHCb with the x-angle they will have in PbPb, will not be compatible with aperture there. In this case we have to squeeze LHCb at the separate flat top squeeze segment. If you have to stop at 1 m for the others/LHCf, then LHCb will remain at 1.5 m, and then if LHCb would then want to go to 1m, keeping the others to 1m, you might need to make a  new dedicated squeeze which is another commissioning step and would take more time. All this should be checked with exact numbers.

Chris: If LHCb uses the change in external and internal x-angle from last year in PbPb, they will get the lowest x-angle. 

Poderick: LHCb does not have a ZDC, so there is no restriction on the x-angle, right? And we can put zero. 

LHCb: Yes

Roderik: Last year we started with 210 and ended up with 70 urad. 

Federico: initially we had 235.

Roderik: Yes, after a discussion back and forth, there were worries in ABP group that with 235 we would get too much feed-down effects from magnets and some other issues, so we went down a bit.

Roderik: Why is the low number of bunches an issue for ATLAS trigger?

Catrin: Yes, there is a limit for the inner tracking detector, due to the fixed trigger veto that we have in place. So if we have typically an intensity ramp up with a very low number of bunches, this limits our trigger rate to ~5 kHz L1, while we have 100 kHz at full ring. (This part is a bit elaborated compared to what was said during the meeting, see from last paragraph on p6 of https://cds.cern.ch/record/2221972/files/ATL-INDET-PROC-2016-004.pdf) The fixed trigger veto was put in place to help with the problem of wire-bond failures induced by resonant vibrations. The veto forbids the potentially dangerous frequencies which could damage the detector and has a large effect when the number of colliding bunches in ATLAS is small.

Chris: Useful to know if 12b gives better performance than 6.

Catrin: Being checked.

Roderik: In other high intensity runs, like the high beta, how was it?

Catrin: In some periods, we left out the inner detector (in particular the pixel, the insertable B layer). Also in Run 2 it happened, so to be able to run at a higher rate.

Chris: The problem is reading out the detector regularly at every cycle, at every colliding bunch, and therefore you vibrate the detector. 

Catrin: This is something that happened in CDF and they lost part of their detector.

Roderik: Could you trigger on empty bunches then? To have higher readout frequency?

Catrin: It is a kind of limitation, but you will still readout at a lower frequency. 

Roderik: Let us know.

Chris: It might be that the 12 bunches is much preferable than the 6.

Catrin: Typically in the ramp up if we have to choose between 3 and 12 b we choose 12, because it is more spread out over the beam.

Roderik: the 6 bunches can be spread out, if what matters is that the ring is filled

Chris: Yes, ATLAS will check some filling schemes.

Roderik: We can spread them out as we want, we have only some constraints on how the fill bunched groups are positioned to get the collisions everywhere, but you can spread them out.

Roderik: “quick program (for luminosity calibration)”: how long is it?

Chris: people were talking about extended emittance scans for about 2 hours in each experiment with hopefully the other experiments still taking data.

Roderik: So we don’t add another ½ day because we need long VdM scans?

Chris: This would be with the usual optics, not VdM. So there should be no extra time.

Michi: Of course, for ATLAS, we have to see for LHCf, for the mu, because during the scan, you’ll be head on.

Chris: To LHCb: if we go to mu = 1, will you be impacted? The detector won’t break, you just cannot readout the data properly.

Hiroaki: Yes, but we can move the detector (offline) to safe during the scan period → no need for access.

Chris: Can you do it remotely?

Hiroaki: Yes.

Roderik: If this is both for pO and OO, with 4-6 hours both, you add ~1 shift in total. 

Chris: I am not worried for pO, but OO seems very difficult to get.

Roderik: I think we should assign more than 1 day, if you put all this together: higher b*, no zero-crossing, additional scan, lower energy… 

 

S13:

Roderik: We need to recheck the assumptions for the luminosity, since they were quite conservative for the bunch intensity ans other things.

Chris: Yes, there’s quite a large number of bunches, 27 bunches, but only 9 colliding in the IPs, which seems very inefficient, and indeed we might do better. In one day, within 20%, we should do the same as in OO.

Roderik: We could get a bit less out of the injectors: because of the space charge limitation, we might get less. It impacts the bunch intensity most of all, and also a bit the emittance. To be rechecked. Maybe in a couple of weeks or a month, we should get updates from the machine both for OO and NeNe. 

Chris: If there is interest in Ne, we might need to be faster because it impacts the schedule of the injectors.

 

S14:

Catrin: For Ne, ATLAS needs ZDC, so option 2 is disfavoured.

Catrin: Should we have some consistency?

Chris: If OO takes longer, this is not normally compensated, so it just goes over pp but we do not reduce PbPb. This is what was done eg for high beta. If it is instead a decision that makes it longer, it is different. The question for OO is only if it is run at lower energy, which might add some commissioning time. 

Catrin: OO is priority over Ne, even if it is at the cost of PbPb, e.g. if we run at lower energy. 

Chris: Yes, this is the task: to check how much extra time low energy OO can take.

Catrin: If we do the Ne run, we’d want our ZDC in.

Chris: So option 1 is favoured.

Catrin: Given the discussion on OO before, we should see how much time will need to be subtracted from HI for the pO, and how much it would cost if it is just one day, or if adding more, e.g. contingency, we’d need to see how the PbPb program would start to shrink, which we’re not in favour to.

Chris: If OO takes longer because there are serious problems, this is not normally compensated by rechecking everything. If there is a 12h delay, everything will just get delayed: we’re not going to start subtracting PbPb days.

Robert: If OO takes longer, will it be subtracted from PbPb?

Chris: No, we just continue, we do not rebalance. There is no quota if a special run takes longer. We do not rebalance for short stoppages. If it is a decision, in the sense that we’re taking longer intentionally, it is different. We’re not adding anything: if we run at top energy in OO (and 0.5 m b* - added by Roderik), we’ll do it in the allocated time. For pO we can run at 1 m b* and make it in time. The question is only if we run OO at lower energy, to see if we’re adding anything. For pO, with 1 m b*, both LHCf and LHCb should make it in time. 

Catrin: ATLAS already said that O is higher priority than Ne, even if it may come at the expense of HI, because we want OO at lower energy (which we strongly prefer).

Chris: The work is indeed to now check how much the lower energy would cost in terms of extra time (by Jorg, Matteo, Roderik). But for the pO, 1m b*, we can achieve the goals by the two experiments that requested it. 

Chris: Decision on NeNe should be given in Chamonix, even if there is no consensus.

S15:

Preliminary opinions on NeNe should be presented at Chamonix, even if we don’t have a consensus, we should present the experiments’ preferences.

 

LHCf (Lorenzo)

 

S3:

Roderik: How long does it take to remove LHCf in the middle of the run? 

Lorenzo: About 1 hour, which is a rough estimate.

Hiroaki: It might depend, sometimes it goes to a few hours. We can discuss with the CERN team because we might be able to minimize this time.

Chris: For installation it does not matter, since we do it during the TS. For the removal, I understood it is quite quick but at the same time we need to put ZDC in, and it was estimated to take ~4-6 hours (opening the LHC, getting people down, RP…).

Roderik: Then we need a precycle since we open the LHC, and we’ll lose some time, probably 6 hours, in the middle of the run.

Catrin: This is compensated with the fact that 1 full day is dedicated in the schedule by ZDC out, while it should take much less (max 2 shifts).

 

S5:

Chris: We can probably get close to 2 us (which is the preferred) bunch separation with 33 bunches, with 2 us spacing, in this configuration we probably we’ll have collisions in all IPs.

 

Roderik/Chris: It is very good that we can run also at mu 0.03, it can help, to give time for availability.

 

AOB:

Chris: Concerning the 2 detector positions: will you change it during the run back and forth (e.g. if we do 4 fills), or the switch is when a certain lumi is reached?

Hiroaki: We don't have precise plans yet, because it is quite quick.

Lorenzo: From one to the other position should be 1 minute.

Chris: So it does not need to be done between fills.

Roderik: Can it be done with beam in the machine?

Chris: They are interlocked so they can do with that.

Catrin: The 3% on the precision of the lumi measurement, it can’t be done with an extended emittance scan, I think. It requires a more extensive program.

Michi: 3% sounds quite difficult.

Filip: For the extended emittance scan, they can get to 10%..

Bruce: We had an internal discussion with ATLAS: emittance scan can do 7%. To do better, we’d need at least a short length scale calibration. We started discussing internally, to do it in a very very short sequence, much shorter than is usually done. Maybe it could then be done with physics optics, but it’d need more time. The 3% seems a tough target. 

Michi: The 7-10% in the emittance scan is supposed to be with pp? Because pO has a much weaker beam and it will not have problems with beam deflection, which is an issue with high intensity pp.

Bruce: Yes, the emittance scan will have to be done with pO.

Michi: But the uncertainty 5-10% considers that it is not standard pp, but something cleaner

Bruce: I don’t think we analyzed at that level, but surely we have to think about this more carefully.

Chris: When you are thinking, I’d prefer to do it with no different optics, since then the others can continue taking data.

Roderik: How much time would one need to get to 3%, to see if it fits the program.

Catrin/Chris: They’re working on it.

 

ALICE (Robert)

 

S4: 

Roderik: If you run OO at higher energy, where you don’t have the pp ref, does this data still have some physics impact?

Robert: The extrapolation should not make us lose much.

Chris: Quite different statements in 2021 from ALICE and ATLAS: ALICE: we can project with not large uncertainties, while ATLAS showed large uncertainties. Maybe it depends on the observables, maybe on the extrapolation technique, but ALICE was more confident to do extrapolation.

 

S5:

Michi: The solenoid can be ramped during stable beams. We can either ramp it with no beam in safe, or stable beam. 

Robert: In stable beam or not stable beam is an internal matter, due to TPC. More convenient to do it during the commissioning. 

Michi: Last year it was approved in stable beam, so why not again, since it was validated. So that the other experiments can continue taking data during the ramp.

Robert/Chris: It will be transparent.

Robert: At the end of one fill, we can go down with the solenoid.

 

LHCb (Paula)

 

S1:

Chris: VdM with physics optics?

Paula: Yes.

Chris: With physics optics it is preferable.

Roderik: Is it realistic to get the needed statistics for the 5% in 2 hours?

Paula: The 5% is not proven to the last decimal point. 5% is the desirable target, so obviously with 4 hours we’d do better, but in 2 hours, if there is a program in place, this could be attainable. I suppose that if a bit longer is required, then it is our budget, so that decision is still open for us.

Chris: I believe that in this run, when we’re taking physics data, we don’t need to separate the others during this VdM, so it is entirely up to you how much time you spend in VdM, because the beam beam stuff in the other experiments will be at very low energy. If you take 3 hours instead of 2, it is up to you.

Michi: For this parallele VdM scans: if anyone else is taking data, in the meanwhile, probably being levelled, in particular in this case, if you take 3 hours, probably we have to make it in smaller segments, or we have to allow the other experiments to level in parallel, since otherwise with these burn off rates, we can impact the other experiments. But given that this is very weak beams, I don’t think you will have any significant x-talk through beam beam between the IPs, the easiest is just to allow the other experiments leveling to continue while you’re scanning, and we remove any restriction, and it is just local to your IP.

Chris: We’ll only be doing separation levelling, no b* steps. 

Michi: Exactly. Normally this is prevented for the reason of possible x-talk, but we have a switch to enable it and this is probably the easiest way to allow for parallel scan. Otherwise we have to agree on how much each segment should be, and it is more complicated. 

 

S2:

Catrin: How long would one need at 450 GeV?

Paula: Very short.

Catrin: So it won’t be one of these fills that we normally get at the intensity ramp up.

Chris: The problem is the setup.

Michi: How many bunches? 

Paula: We need to finalize this. 

Michi: Because changing configuration is what needs more discussion: e.g. if you go to non-safe beam. If a few individual bunches (lower than 4, 5) is enough, it is ok, if you need more it is another story. 

Chris: At the beginning of the run, the estimate was something like 1.5 days of setup and 2  hours of running.

Roderik: Going back to the previous slide, a question on Ne. You said priority is to reach pO, then PbPb as much as possible, then NeNe if time allows. Does this mean that if you take time from PbPb for Ne, then you don’t take as much as possible PbPb by definition. So by definition, you say no to Ne.

Paula: Yes, indeed.

Chris: If it is also out of 2026?

General comments by many people: it is difficult to make a decision binding them to the 2025 performance in PbPb which will happen after the possible slot of NeNe, so we cannot know.

Roderik: The target of 2 nb-1 in PbPb for LHCb is close to impossible. So if you have PbPb in 2026, you can reach it, but if it is only in 2025, how can you get there?

Paula: The 2026 discussion will need as input the 2025 performance. 

Roderik: Then you’ll need to set priorities between pPb and PbPb, since LHCb was also very interested in pPb.

Paula: Yes, very interested.

Chris: There is not enough time in the year.

Michi: We cannot say exactly what will happen since it will depend on the performance of this year, and now we have to make a commitment about what to do this year, based on what we’ll be doing next year, this does not work.

Chiara: We cannot bind Ne to Pb, since Pb comes later. 

Chris: We also cannot bind it to the OO thing, if it is successful. 

Michi: We should also ask how much is 1 day within the uncertainty since there might be a cryo problem and you lose 1 day. So 1 day is not a reasonable unit for uncertainty. 

 

AOB:

Chris: It seems we don’t have a huge amount of support for Ne. ALICE was not supporting it essentially, LHCb also. 

Chiara: And for ATLAS< if we keep Ne, they want the ZDC.

Chris: Then we go for O, and we hope we can keep it for 6 hours.