Noot in Circle

Which candidate gets the vertex?

Fri, 06 Nov 2026 15:22:54 +0000

Suppose the model proposes two places where a particle might have decayed, and the simulation gives me one eligible decay. Which proposal should learn from that decay? I spent part of this week working through that question with an example small enough to fit on a scrap of paper.

Give each prediction two jobs

The prototype reads the segments from one collision together. Each candidate slot gathers a weighted summary of those measurements, then predicts a position and a score for whether it found a vertex. The number of slots sets the maximum number of predictions. The scores determine how many candidates I keep at inference.

Try it on a line

Imagine the true position is 10 and the two candidates predict 9 and 13. Their distances are 1 and 3, so I match the candidate at 9. I train its position towards 10 and its existence score towards active. The candidate at 13 gets an inactive target for its score. It has no coordinate target for this event.

With two eligible decays, each gets a different slot. I choose the pairing with the smallest total position error and hold that pairing fixed while the model updates. The matched coordinates can move towards their targets because the position error changes as the coordinates move. The next pass makes new predictions and matches them again. A related set-matching idea appears in object detection. DETR paper

What I checked this week

I ran the training loop on synthetic events where I could control how many vertices were present and where they were placed. That exercises the cases I care about in the software, including empty targets, more than one vertex and spare candidates. The next step is to define the eligible decays for the endcap pilot and agree what distance counts as a match. Then I can compare missed, duplicate and extra vertices against the existing reconstruction on the same held-out events.

Earlier in the Cambridge notebook

One collision, one place in the dataset

Fri, 06 Nov 2026 15:22:54 +0000

My first useful unit of data was a collision. One collision can leave several short segments in the muon spectrometer. They are clues from the same event, so I keep them together from the first read of the ROOT file through to the final test.

Give the collision an identity

Event numbers can repeat across independently generated samples. I pair the run and event numbers with the identity of the simulation sample. Copies or reprocessings of the same collision need to keep the same identity. The split uses the collision identity and a fixed seed, so rereading the events in a different order gives the same assignments. I save those assignments alongside the information needed to trace each extracted record back to its source.

Imagine one collision leaves three segments. If two land in training and the third lands in testing, the model gets part of the test event during training. With an event-level split, all three go to the same partition. The training set fits the model, the validation set guides choices such as the score threshold, and the test set is where I check those choices on held-out collisions.

Keep the answer in a separate envelope

The model inputs describe reconstructed segments, starting with their positions and directions. In simulation I can also read the generated decay positions, which I keep in a separate truth record. An eligible target is a generated decay that meets the agreed detector region and selection. A complete record with zero eligible decays supplies a negative example. A missing truth record leaves the answer unknown.

I checked that extraction preserves the collision identity, the segment arrays line up and the split joins back to the same collisions. That gave me a way to test how the data move through the pipeline. The next step for physics training is to settle the eligible decay region and confirm the coordinate conventions. Two files that open perfectly can still disagree about where a metre starts.

Next in the Cambridge notebook

Which candidate gets the vertex?

A short line in a very large detector

Fri, 06 Nov 2026 15:22:54 +0000

When I started my MPhil in October, I kept returning to a drawing with a few short lines. Each line tells you where the muon spectrometer saw a particle pass and which way it was heading there. My question was whether several of those lines could help me work backwards to the same place.

What a segment measures

A segment is a local fit to hits in a detector chamber. It carries a position and a direction. A displaced vertex is the point where a particle decayed away from the original proton collision. If a long-lived particle reaches the outer detector and decays there, its decay can produce a spray of particles. Some leave enough hits for the chambers to measure local directions. ATLAS muon spectrometer · ATLAS displaced-vertex search

Sketch of the geometry. The solid lines are measured segments. The dashed lines extend their local directions backwards.

When a drawing turns into reconstruction

On paper, I can extend two lines with a ruler. In the detector, segment directions have measurement uncertainty, magnetic fields bend charged trajectories, and some segments come from unrelated activity. A cluster of compatible directions gives a candidate. The reconstruction still needs a way to decide which segments belong together and where the candidate lies. The published standalone ATLAS method is the starting point for understanding that problem. Standalone vertex finding in the ATLAS muon spectrometer

This is the part I like. A line in a chamber is a measurement I can reason about. An event contains a whole collection of them, and the geometry only starts to tell a story when I look at them together.

See the geometry in motion

Try the displaced-decay walkthrough

What counts as replaying the same collision?

Fri, 06 Nov 2026 15:22:54 +0000

Writing up the openlab project in October made me separate two questions I had been treating as one. Can I run PEPPER again with the same sampling setup? And can I ask two arithmetic builds to evaluate the same candidate collision? The distinction decides what a difference in the output can tell me.

Reuse the sampler, then match the input

An event generator learns where to spend its effort. It can save settings that guide it towards parts of phase space that contribute strongly to a process. In my precision study I reused that optimisation state to study the production stage separately. That held the sampling setup fixed while leaving the generator free to draw new candidate collisions.

For an event-by-event comparison, I need each build to see the same momenta and to match the choices that affect the weight, such as the incoming particle types and any sampled spin states. The random seed starts a sequence. Which step uses which number depends on how the run proceeds. Imagine that drawing momenta normally uses the first three random numbers and choosing a spin state uses the fourth. If I read the momenta from a file and skip those first three draws, the spin choice now gets the first number.

PEPPER’s current manual describes how its file-based replay keeps those later draws aligned. It draws and discards the numbers that would have been spent generating the momenta. It also lists the settings required to reproduce the original run, and explains why recalculation from stored momenta can still differ at the level of rounding. PEPPER manual on reusing phase-space points.

Check the route before comparing precision

I compared direct generation with writing and reading events while keeping the arithmetic in FP64. That isolated the effect of changing how the input reached the calculation. It also gave me a better order for the next comparison. First I’d match the input, settings and relevant sampling choices. Then I’d compare weights before unweighting and follow any discrepancies through the calculation.

“Run it again” sounds like the easy part. For this project it turned out to be one of the more interesting experimental controls.

Start with the project

How many digits does a collision need?

Before a collision becomes a histogram

Fri, 06 Nov 2026 15:22:54 +0000

A cross section is a number I know how to look at. A log full of calculations that led to it is a rather different proposition. During openlab I learnt to keep the individual event weights in view, because the final sum can hide exactly the thing I’m trying to understand.

What an event carries

PEPPER proposes configurations of outgoing particles and works out how much each contributes to the predicted rate. The weight includes the physics of the hard scattering and factors that account for how the configuration was sampled. Some workflows then unweight those events by accepting heavier events more often, so the accepted events can usually be handled with a common weight. PEPPER paper, event generation framework.

Here’s a tiny positive-weight example. Suppose two candidates have weights 1 and 3, and we use 4 as the acceptance bound. The first gets accepted one quarter of the time and the second three quarters of the time. If both happen to survive, they look alike in the unweighted sample. Their original weights explain why the second was more likely to get there.

Where I put the diagnostic

I recorded numerical diagnostics after each candidate’s weight was calculated and before the accept-or-reject step. That gave me the original weighted calculation to inspect. I could look at the evaluated matrix-element quantity alongside the other ingredients and ask where the sensitivity to rounding entered. A warning from CADNA points to an operation worth investigating. Several such warnings can come from the same candidate. CERN openlab project and talk.

Imagine a distribution split into two bins. A shift from weights 4 and 6 to 3 and 7 leaves the total at 10, but it moves weight from one bin to the other. That is why I want both views of a precision comparison. The overall rate and the shape tell me how a physics prediction moves. The individual weights give me a place to start looking for the reason.

Next openlab note

What counts as replaying the same collision?

Making precision a setting I could test

Fri, 06 Nov 2026 15:22:54 +0000

In early July I wanted to answer a deceptively small question about PEPPER. If I asked the generator to calculate with 32-bit numbers, which parts of the calculation would actually run in 32 bits? I started by making precision a choice I could build, record and repeat.

Four builds, two questions

I set up separate builds for ordinary single and double precision, called FP32 and FP64, and for each precision with CADNA on the CPU. The ordinary builds let me compare the arithmetic used by the generator. CADNA added a different kind of evidence. It varies the rounding across copies of a calculation and uses their spread to estimate how many digits remain stable. Comparing the four modes gave me a way to ask both whether an answer moved and where it became sensitive. CERN openlab project and talk · CADNA project.

A tiny example from C++

Take a variable x declared as a float. In x * 0.5, C++ treats 0.5 as a double, so the expression is evaluated as a double-precision expression at the language level. Write x * 0.5f and the expression has type float. Both expressions can give the same result in this example. The interesting bit is that the type of the variable and the type of the operation are two things to check. C++ floating-point literal rules.

That distinction mattered in the generator. I used a shared numerical type for the core calculations, then checked the places where other assumptions could creep back in, such as constants, mathematical functions and complex numbers. The diagnostic builds also needed an explicit conversion when passing values to libraries that expect ordinary floats. The numerical type tells me how a result was calculated. The storage type tells me how it was written.

By the time I could switch between builds, I had something much more useful than a collection of edited source files. I could say exactly which arithmetic I was testing and reproduce the setup when the next calculation surprised me.

Next openlab note

Before a collision becomes a histogram

What is ATLAS, and what does it do?

Fri, 06 Nov 2026 14:57:58 +0000

On the homepage, two dots go around a ring and meet at ATLAS. In the real Large Hadron Collider (LHC), beams of protons travel in opposite directions in separate pipes. At a few points around the ring, the beams cross and some of the protons collide. ATLAS is a general-purpose particle detector built around one of those crossings, Point 1. It is also the name of the collaboration that operates the detector and studies the data. CERN’s ATLAS overview and guide to the collision points.

Start with one collision. Particles fly out from the centre and cross layers that measure different things. ATLAS pieces those measurements together to reconstruct what happened.

Original cross-section of the ATLAS barrel, looking along the beam pipe. Illustration · Not to scale. Based on the ATLAS detector documentation.

What each layer measures

Inner tracking detector. Charged particles leave a series of hits as they pass through sensors near the beam pipe. A magnetic field bends their paths. From the direction and amount of bending, we can infer the sign of a particle’s charge and help determine its momentum. ATLAS inner detector.
Calorimeters. When particles interact with dense material, they can produce a shower of secondary particles. The calorimeters sample the energy deposited by the shower to estimate the original particle’s energy. The electromagnetic layers are designed for electrons and photons. The hadronic layers measure showers from particles such as pions and protons. ATLAS calorimeters.
Muon spectrometer. Muons often pass through the calorimeters and reach the outer chambers. By measuring how their paths bend in the field of the large toroidal magnets, the spectrometer can estimate their momentum independently of the inner tracker. ATLAS muon spectrometer.

How a collision becomes a physics measurement

Collisions arrive too quickly to save all the detector data. A system called the trigger makes a fast first decision using hardware. Software then examines the selected events in more detail and decides which ones to record. Reconstruction software combines the detector signals into things we can analyse, such as tracks, photons and jets. ATLAS trigger and data acquisition.

The Higgs boson is a good example of what you can do with that record. In one type of analysis, we use the energies and directions of two photons to calculate the mass of the particle that could have produced them. When many such events are plotted together, Higgs decays contribute a peak near 125 GeV above the background. The same detector can measure known processes in more detail and search for patterns we have yet to see. ATLAS Higgs measurements.

Where my Cambridge project comes in

A hypothetical long-lived particle could reach the muon spectrometer before it decays. The resulting tracks can point back to a spot away from the beam crossing, called a displaced vertex. In my MPhil, I’m investigating whether machine learning can help use those short segments to locate the decay. Read what a segment measures or see ATLAS’s displaced-vertex search.

See how reconstruction works

Try the displaced-decay walkthrough

Explaining numerical precision in a lightning talk

Fri, 06 Nov 2026 14:50:14 +0000

On 18 August I took PEPPER to the CERN Council Chamber for the openlab lightning talks. I had about five minutes to explain where floating-point rounding matters in a simulated collision. The public agenda has my slides and recording.

How I’d test a faster calculation

The next question I’d ask is where a mixture of 32-bit and 64-bit arithmetic can work. I’d start by feeding the same event kinematics through both versions and comparing intermediate quantities as well as the final weight. Using the same inputs matters because two independent Monte Carlo runs will differ even when the arithmetic is identical.

I’d trace the largest discrepancies back to the first operation that accounts for them, then test that operation in FP64 or rewrite it in a more stable form. Next I’d compare cross sections and distributions across processes. I’d pay particular attention near cuts and in sparsely populated bins, where a shift in event weights can matter even if the overall rate barely moves.

The final check is a benchmark on the target hardware. Keeping sensitive operations in FP64 leaves a practical question: does the remaining FP32 work save time across the whole workflow?

Back to the notebook

This is what made the project interesting to me. A question that starts with a data type takes you all the way back to which events matter for a physics analysis. Thanks to Enrico Bothmann and František Stloukal for supervising the project.

Read from the start

How many digits does a collision need?

What happens when you let the rounding vary?

Fri, 06 Nov 2026 14:50:14 +0000

A program can print ten digits even when some depend on a rounding choice made several operations earlier. During my openlab project, I used CADNA to vary those choices and see how much the answer moved. The output looks considerably less self-assured once you give it a second opinion.

Try it with five significant digits

Subtract 1.23454 from 1.23456. The exact difference is 0.00002. If you first round both inputs to five significant digits, you subtract 1.2345 from 1.2346 and get 0.0001. If you round both inputs down to that precision, you get zero. Both calculations start from the same values. The difference is small enough that changing how you round the inputs changes the answer considerably.

That example uses decimal arithmetic to make the cancellation visible. In a real program, rounding happens in binary and can accumulate over a long chain of operations. CADNA runs several copies of the arithmetic with different rounding choices and uses the spread of the results to estimate how many significant digits are stable under those perturbations. CADNA for C and C++.

What to do when a number moves

In PEPPER I looked for rounding sensitivity in matrix elements and event weights. When a weight moves, intermediate values help locate where the two calculations first diverge. It could be a subtraction of nearly equal numbers or a threshold that sends the calculation down a different branch.

Read a warning as a pointer to an operation. One event can raise several, and the estimate of stable digits describes that calculation under those test conditions. For the physics check, compare the overall rate and the regions of the distribution that the analysis uses.

Next in the series

Explaining numerical precision in a lightning talk

How many digits does a collision need?

Fri, 06 Nov 2026 14:50:14 +0000

I started my CERN openlab placement with a question about PEPPER: which parts of a particle physics event generator need the extra digits of 64-bit arithmetic? I came in thinking about speed. I spent the summer learning where the digits go.

From a collision to a number

During my summer project, I worked with Enrico Bothmann and František Stloukal on PEPPER, a generator for the parton-level stage of a collider simulation. This is where the simulation calculates the hard interaction between incoming partons such as quarks and gluons, before later stages model the development of the event and its passage through a detector. A matrix element helps determine how likely a particular configuration is. The event weight also reflects factors such as how we sampled that configuration. If the arithmetic changes the weight, it can change how much that event contributes to a prediction. PEPPER paper.

What a smaller number format changes

FP32 stores fewer significant bits than FP64. The gap between the numbers it can represent grows as the numbers get larger. When a calculation subtracts two nearly equal quantities, the difference can be smaller than the rounding errors already in them. The subtraction can then be perfectly legal arithmetic and still return a misleading answer. There’s a small mass reconstruction example on the homepage that lets you see this happen.

Start with the same event kinematics and compare the matrix element and weight. Then ask whether the difference changes a quantity the analysis uses. A few digits matter a lot more if they decide which side of a cut an event lands on.

Some hardware can do 32-bit arithmetic faster. My summer project focused on the step that comes first: finding where rounding affects the calculation. I started by making precision a setting I could test. The CERN openlab lightning talk programme has the project description.

Next in the series

What happens when you let the rounding vary?

Wrapping up UCL: what I built, what I learnt, and what I’d do next

Tue, 20 Oct 2026 11:41:04 +0000

Time to close the UCL chapter.

The project finished before the blog did. I’m calling that an unusually thorough editorial process.

Figure 1. Artist’s impression of UCL Illuminated, showing the Portico and Wilkins Building lit up for UCL’s bicentenary celebrations in 2026. Image credit: © Double Take Productions. Source: UCL News.

The previous posts went from simulating collisions and tagging boosted Higgs candidates to comparing model implementations and testing the results with Contur and Spey.

Here’s what came together, where I got stuck and what I’d try first if I went back to it.

The original question

My BSc project, supervised by Professor Jon Butterworth, investigated Higgs physics at the Future Circular Collider, focusing on associated ZH production at 85 TeV.

The signature was an invisibly decaying Z boson alongside a Higgs decaying into a bottom quark and an antibottom quark. In the boosted regime, the Higgs decay products can be reconstructed inside one large jet.

I wanted to use the Higgs Effective Lagrangian to see how modified Higgs interactions would change this process, then estimate how sensitive the analysis might be to those changes.

The plan sounded straightforward. Generate events, analyse them, vary the coefficients and interpret the results.

Then the software was given an opportunity to comment.

What I built

I connected the main stages of the project into one working analysis chain:

Event generation → Rivet reconstruction → signal–background comparisons → Contur/Spey interpretation.

Each arrow required its own checks.

Getting the generation under control

I loaded the HEL implementation into Herwig and compared its cross sections with MadGraph in the Standard Model limit and at exploratory nonzero coefficient settings.

The checks gave me a baseline and showed how strongly some of the benchmark coefficients could change the predicted rate.

They also taught me to be precise about “agreement”. In one benchmark, both generators predicted a large enhancement, yet the difference between them exceeded the quoted integration errors. The final report made that distinction clearer than my early posts did.

I used Standard Model samples for the main event analysis.

Turning simulated events into Higgs candidates

I developed the custom Rivet routine, FCC_MC_ZH2BB_MDT, to reconstruct large jets, apply missing-momentum and b-hadron requirements, groom the candidates, and inspect their masses.

The routine produced distributions and cutflows, so I could see how many events survived each step. I could vary the MET requirement, jet radius and grooming parameter without rewriting the routine.

I also matched the generation to the final state I wanted: boosted Z bosons decaying invisibly.

At one representative working point, the routine retained about 21.7% of the generated signal sample. That fraction applies to the boosted generation cuts and selected decay mode used in the study.

Bringing in the background

I then established a comparison using one million signal events and one million background events. Stephen generated the main background sample: Z production alongside a bottom-quark pair, with the Z decaying invisibly.

The background sample let me measure what else passed the same selection.

Varying the MET selection showed how much signal I lost as I removed background.

In the highest MET bins, a few surviving events could make the ratio look impressive. I learnt to check the counts before celebrating the ratio.

Connecting the analysis to a statistical test

In the final stage, I adapted Contur and Spey to use simulated pseudo-measurements from the custom analysis.

I wrote helper code to prepare the histograms, matched reference and theory objects, added the database entries and selected the observables for the scans.

The resulting workflow ran a 13 TeV closure test and an 85 TeV FCC-like study. Both scans preferred an added contribution near zero.

How the project changed direction

The project finished as a controlled Standard Model analysis with a statistical workflow I could exercise using simulated inputs.

The HEL calculations established benchmarks for the two generators. To turn the scan into direct EFT constraints, I’d need reliable event generation with the translated model and a statistical treatment that accounts for uncertainties and correlations.

That change made the remaining problems much more specific.

“Study new physics at the FCC” is a large ambition. “Understand how this template’s Monte Carlo uncertainty enters this likelihood” is a task I can investigate.

Less impressive as a conversation starter, perhaps. Considerably more useful when deciding what to do on Monday.

What I’d do next

1. Establish reliable EFT event generation

I would start with a small number of carefully checked benchmark points.

Before a wider scan, I’d check that the operator conventions, coefficient normalisations and generator inputs give the intended predictions.

I’d carry those benchmark samples through the analysis and check that a change in the coefficient produced the expected change in the observable.

2. Validate the statistical treatment

Next I’d trace the uncertainties from the simulated reference, the baseline and the added template into the likelihood, including correlations between bins.

I’d start with controlled cases where I know what the fit should return.

Those checks would tell me whether I could attach a confidence level to the scan crossings and explain where the uncertainty came from.

3. Extend the analysis on those foundations

With the model and statistics checked, I’d generate more events in sparse regions and compare a wider range of selections and observables.

I’d then test how detector effects and pile-up change the results from the particle-level study.

What I’m taking away

The project taught me to follow a result all the way back through the analysis.

A model that loads, a cross section that looks sensible, a usable event sample, a tagged candidate and a completed statistical scan each answer a different question.

By the end I could run that whole chain and point to the next check at each stage.

A big thank you to Prof. Jon Butterworth for supervising the project and helping me work through its changing direction. He remains, as previously reported, probably the nicest professor I’ve met.

That wraps up the UCL project and, finally, this part of the blog.

Contur has received its ending. I can now introduce the next research adventure without leaving the previous one permanently labelled “coming soon”.

And the project earned a first-class grade, which was a lovely way to finish. ;)

What the numbers actually said: Contur at 13 and 85 TeV

Tue, 20 Oct 2026 11:33:34 +0000

In the previous post, I connected the Rivet analysis to Contur and Spey using simulated pseudo-measurements.

Once the histograms and the database were talking to each other, the scans returned two numbers: 41.8 and 8.11.

A satisfying moment, followed by the harder question of what those numbers meant.

Figure 1. Schematic view of a proposed Future Circular Collider (FCC) location in the Geneva region, showing its ring alongside the existing LHC. Image credit: Daniel Dominguez/CERN, © 2025 CERN. Source: CERN Document Server, CERN-GRAPHICS-2025-002.

A quick reminder: what am I varying?

I used distributions from Standard Model simulation as my reference, so the comparison started from a known set of modelling assumptions.

Against that reference, I tested a prediction consisting of:

Standard Model baseline + μ × an additional test contribution.

The parameter μ, pronounced “mu”, controls the size of the added component. At μ = 0, there is no extra contribution. At μ = 1, I add the nominal template once.

The added templates also came from Standard Model simulation. That gave me controlled inputs for the statistical workflow while I worked on EFT event generation.

With the Spey statistical backend, I scanned μ to find the best fit and see how the fit changed as I added more of the template.

First: does the 13 TeV test behave sensibly?

The 13 TeV study used the fat-jet mass distribution as a closure test.

A closure test asks whether the procedure gives the answer you expect in a controlled case. With an SM-like reference and baseline, the fit should prefer μ close to zero.

The scan’s best-fit μ was effectively zero.

My synthetic Standard Model reference was happy with the Standard Model baseline. That was the check I needed before moving to 85 TeV.

Figure 2. The 13 TeV scan. The black curve reaches its minimum near μ = 0. The blue vertical line marks the crossing of the red reference threshold at μ ≈ 41.8. Source: my UCL BSc project report.

As the contribution grew, the scan curve rose. It reached the plotted threshold at μ ≈ 41.8, about 42 times the nominal added template.

The nominal template at μ = 1 sat well below that crossing.

The fit behaved as expected in this closure test. Interpreting the crossing at a stated confidence level would require checks of the uncertainty model.

Then: the 85 TeV FCC-like study

For the 85 TeV setup, I examined the groomed mass of b-tagged Higgs-candidate fat jets.

I plotted the distribution before applying the explicit Higgs mass window. That let me see whether the candidates clustered near the Higgs mass before I selected on it.

Figure 3. The 85 TeV candidate-mass distribution before the Higgs mass-window selection. Black markers are simulated pseudo-data; red is the SM baseline; blue includes the nominal added template. The original legend labels the blue curve “BSM+SM”, although this test used an SM-derived template. Source: my UCL BSc project report.

The distribution showed a feature around 125 GeV, where I expected the reconstructed Higgs candidates to sit.

The reference and baseline agreed closely. Adding the template raised the prediction around the peak and at higher masses.

The mass observable responded where I expected it to. The scan showed how that response changed the fit.

Figure 4. The 85 TeV scan. The minimum again lies near μ = 0, with the plotted threshold crossing at μ ≈ 8.11. Source: my UCL BSc project report.

The best fit again lay effectively at zero. The curve reached its threshold at μ ≈ 8.11, about eight times the nominal template.

Does 8.11 versus 41.8 prove an FCC improvement?

I would quite like to divide the two numbers and let the arithmetic finish the physics for me.

Each crossing is in its benchmark’s own units. The benchmarks used different observables, and the size of one unit of μ depends on how each template is normalised.

To isolate the effect of collision energy, I would need to compare setups with consistent observables, template definitions, luminosity and uncertainties.

The unfinished part: uncertainties

Some bins in the simulated reference had very small uncertainties. In the 13 TeV distribution, a modest difference between curves could look large when expressed in units of those uncertainties.

The next checks are how the calculation handles the added template’s Monte Carlo statistical uncertainty and correlations between bins.

These details matter. Shared uncertainties can make several bins move together, affecting how much independent information the distribution contains.

The lower panels helped me inspect the comparison. Checking how each uncertainty entered the fit was a separate job.

The red lines show the chosen threshold of 3.84. The confidence level associated with a crossing depends on the test statistic and its distribution, which still needed checking.

What did this stage achieve?

The custom analysis could now produce distributions and use them to build a simulated reference and run statistical scans with Contur and Spey.

The 13 TeV test returned the expected best fit near zero. The 85 TeV study produced a Higgs-sensitive mass distribution and a scan that responded to the added template.

The crossings were provisional. A direct EFT interpretation would require validated predictions connecting the Wilson coefficients to these distributions, as well as the uncertainty checks above.

The computer had successfully returned numbers. The remaining work was understanding exactly what those numbers deserved to mean.

Next, I’ll bring the UCL project together: what I set out to do, what I completed, and what I would tackle first if I continued it.

Finally, Contur: making measurements for a collider that hasn’t run yet

Thu, 15 Oct 2026 23:29:44 +0000

After several posts of promising to get to Contur, here we are.

I had a working Rivet analysis, simulated Higgs events and a way to compare signal with background. The one thing I couldn’t get was a measurement from the FCC.

The collider hadn’t been built. A slightly inconvenient detail.

My original plan was to generate events with modified Higgs interactions and find out how tightly I could constrain them. The coefficient study depended on getting the model translation and event generation to work.

I used the samples I had to test the statistical workflow. Could it recover the expected answer against a reference I had simulated myself?

What does Contur actually do?

Contur stands for Constraints On New Theories Using Rivet.

Figure 1. The ship illustration used as the Contur logo. Illustration by Chris Wormell, from A Map of the Invisible, as credited in the Contur tutorial. Logo source: official Contur documentation.

Contur starts with a collider measurement. Even a distribution measured to study a Standard Model process can constrain a proposed model if its extra contribution changes the shape or rate.

Contur uses measurements preserved in Rivet to test whether predictions from a proposed model are compatible with the data. The Contur toolkit paper explains the approach in detail.

In the extra-contribution setup I was studying, the question was:

How much could I add to an acceptable Standard Model prediction before it stopped agreeing with the reference?

That gives us something more informative than looking at two curves and deciding that one seems suspiciously enthusiastic.

Making a reference dataset

For the FCC study, I used simulated Standard Model events to build the reference distributions.

These pseudo-measurements are the distributions I would expect under the Standard Model assumptions used in the simulation.

They gave me a controlled way to test the workflow. How much the resulting scan can tell us depends on the uncertainties assigned to that reference.

My Rivet routine supplied the distributions. A jet-mass histogram records the simulated contribution in each mass bin, so it keeps the shape of the distribution as well as the total yield.

That matters for a Higgs analysis. An additional contribution concentrated around the Higgs-candidate mass region can behave differently from one spread across the entire distribution.

Rivet stored these histograms in YODA files. Those became the inputs to the next stage.

Teaching the files to talk to each other

A histogram can look perfectly good on a plot and still be invisible to the next program in the chain.

I came here to study Higgs physics and ended up negotiating with histogram names. Fair enough.

I wrote helper code to prepare matching reference and theory objects, labelled /REF/ and /THY/, with consistent analysis names and histogram paths.

I also extended the Contur database with the entries needed for the custom analysis, including its grouping and luminosity information.

I kept the observables intended for the statistical study and excluded empty objects and diagnostic plots from the Rivet output.

Once Contur could read the custom FCC analysis, I could start checking the statistical assumptions.

Turning up the extra contribution

The comparison can be written in plain English:

Total prediction = Standard Model baseline + μ × extra test contribution.

The symbol μ, pronounced “mu”, controls the size of the additional contribution:

μ = 0 means the baseline alone.
μ = 1 adds the test contribution at its nominal size.
μ = 2 adds twice that test contribution.

I built the test templates from Standard Model simulation to give the pipeline controlled inputs. A constraint on cH, cHW or cHB would require validated predictions for how those coefficients change the distributions.

For the statistical calculation, I used Contur with the Spey backend. Spey provides tools for likelihood-based hypothesis tests: assessing how well a prediction describes the reference within a specified statistical model.

Scanning μ then shows where the agreement is best and how it changes as the extra contribution grows.

First, check the obvious case

Before interpreting the FCC-like study, I ran a 13 TeV closure test using an SM-like reference and SM-derived predictions.

With an SM-like reference and baseline, I expected the fit to prefer an additional contribution close to zero.

The best-fit μ was effectively zero. The workflow passed that qualitative check.

I still needed to check how the calculation handled the simulated uncertainties, especially for the added template, and how it treated correlations between bins. Those choices determine how much weight a difference between curves carries.

By this point, I had a working chain:

Simulated events → Rivet distributions → pseudo-measurements → Contur/Spey statistical tests.

That was a substantial step beyond getting a Higgs tagger to run.

Next came the results at 13 and 85 TeV, and the job of deciding how much confidence to place in those numbers.

Lost in translation: from HEL to SMEFT

Thu, 15 Oct 2026 23:21:25 +0000

The drafts have made it out of the drawer.

The Contur cliffhanger can wait one more post.

First, what happened to my original plan to change the Higgs interactions and see what that did to the predictions?

In the early posts, I introduced the Higgs Effective Lagrangian, or HEL, and started varying three Wilson coefficients, written here as cH, cHW, and cHB. These control additional interactions that can change the rate and kinematics of Higgs production.

HEL describes modifications to Higgs interactions using dimension-six operators. Moving to the Warsaw-basis implementation of Standard Model Effective Field Theory (SMEFT) meant expressing the same interactions in a different set of operators. The HEL model paper describes the implementation I used for the initial checks.

I compared Herwig and MadGraph with all Wilson coefficients set to zero, then switched on individual coefficients and combinations.

One exploratory benchmark used:

cH = 0.2
cHW = 0.1
cHB = 0.1

At 85 TeV, MadGraph returned a cross section of 197 ± 1 pb, while Herwig returned 205.4 ± 0.3 pb. Both predicted a substantial enhancement over the Standard Model rate.

The generators predict a similar enhancement, and their cross sections differ by roughly 4%. That difference exceeds the quoted Monte Carlo integration uncertainties, so my earlier description of statistical agreement was too strong.

This was an exploratory benchmark. To judge whether the parameter point was physically viable, I would need further checks, including whether the EFT approximation held in the energy region I studied.

The next challenge was expressing these HEL settings in the Warsaw basis used by the SMEFT implementation I was investigating.

A basis is the set of independent operators used to write the effective Lagrangian. The same interaction can look different in two bases: one nonzero coefficient in the first can become several in the second.

Rosetta can translate between bases such as SILH and Warsaw. I still needed to check how the specific model files defined and normalised their coefficients.

The cH comparison came closer after I accounted for a normalisation factor involving the new-physics scale and the Higgs vacuum expectation value. That pointed to a convention issue in this particular check.

The momentum-dependent cHW case remained unresolved. The translation gave several Warsaw-basis coefficients, as can happen in a basis change. The test was whether the complete setup reproduced the HEL prediction, and the much larger HEL cross section did not reappear.

Loading a model and obtaining a cross section were only the first two checks. Rivet needed a usable event sample, and I hadn’t established a reliable way to generate one with the translated SMEFT model in Herwig by the end of the project.

I continued with Herwig’s built-in Standard Model signal and Standard Model background samples. Those gave me stable inputs for the event selection, jet tagging and signal–background comparison.

The HEL studies gave me a set of generator benchmarks. Direct Wilson-coefficient constraints would need reliable EFT event samples.

That brought me back to Contur. I now had a narrower question: could I use simulated measurements to test the statistical interpretation?

Yearly Catch up: a Higgs candidate is only half the story

Thu, 15 Oct 2026 23:17:04 +0000

It’s been a while. Here’s a favourite ATLAS event display to get us back into the physics.

Figure 1. ATLAS event display of a candidate Higgs decay into four muons, H → ZZ* → 4μ, recorded on 10 June 2012. Image credit: ATLAS Collaboration, © 2012 CERN. Reproduced without modification under CC BY-SA 4.0. Original source: CERN Document Server.

Last time, I showed how my Rivet routine looks for a boosted Higgs. It finds a large jet, checks for b hadrons, grooms the jet and asks whether its mass is close to the Higgs mass.

The routine could now tag candidates. How often could something else pass the same selection?

A background jet does not politely remove itself just because I have written a Higgs analysis.

My project follows a different channel from the one in the ATLAS image. In the proton–proton process pp → ZH, the Z decays into neutrinos and the Higgs decays into a bottom quark and an antibottom quark.

When the Higgs has high transverse momentum, the two bottom quarks can end up inside one large jet. The neutrinos escape detection, so the visible particles carry an imbalance in transverse momentum. I call that imbalance MET here.

I generated signal with Z-boson transverse momentum above 400 GeV and selected invisible Z decays. The efficiencies below describe that restricted, simulated signal sample.

I varied the MET requirement, the radius of the large jet and the grooming parameter z_cut.

One working point used MET above 400 GeV, a jet radius of 1.0 and z_cut = 0.1. It retained 217,297 tagged candidates from one million generated signal events, about 21.7%.

I used that working point for the background comparison. Optimising the selection would take a broader study.

The main background I studied was Z production alongside a bottom quark and an antibottom quark, again with an invisible Z decay. It can give us the same ingredients as the signal: missing momentum and bottom-quark jets. Here the pair comes from a process with no Higgs decay.

Stephen generated the background sample. I ran one million simulated events of each process through the analysis.

To compare the expected event counts, I used each process’s cross section, the assumed integrated luminosity and the fraction of events that passed the selection:

Expected event count = cross section × integrated luminosity × selection efficiency.

I called the expected numbers passing the selection S for signal and B for background.

I compared S/B, the signal-to-background ratio, with S/√B, a simple sensitivity proxy that is most useful for sufficiently large, background-dominated counts.

They answer different questions. A selection can produce a cleaner sample while throwing away enough signal to make the measurement less sensitive.

Tightening the MET cut could reduce background, at the cost of losing signal. At the highest MET values, so few simulated events survived that a fluctuation in one nearly empty bin could make the ratio look impressive.

The comparison gave me signal and background yields for the same particle-level selection. An experimental sensitivity estimate would also need detector effects and a fuller treatment of uncertainties.

Meanwhile, I was still trying to get reliable event generation with the translated EFT model. The early benchmarks remained exploratory, and I continued the main analysis with a controlled Standard Model baseline.

Once I had the distributions, I could ask how much room they left for an additional contribution.

That meant returning to Contur and working out what to use as a measurement for a collider that hasn’t run yet.

Hunting boosted Higgs bosons with Rivet at FCC-hh

Wed, 26 Nov 2025 14:48:07 +0000

Once I have a pile of simulated events, how do I find the ones that look like boosted Higgs production? That’s where Rivet comes in.

A rivet, in the other sense.

Rivet stands for Robust Independent Validation of Experiment and Theory. It’s a C++ framework for analysing Monte Carlo events at particle level. I can run an existing analysis from its library or write my own selection.

My analysis is called FCC_MC_ZH2BB_MDT. I’m looking for a pair of signatures in the same event:

The Z decays to neutrinos, leaving a large imbalance in transverse momentum (MET).
The Higgs decays to a bottom quark and antiquark. When the Higgs has high transverse momentum, both sprays of particles can fit inside one large-radius jet.

Here’s how I select a candidate:

Require large MET. A cut on the imbalance selects events consistent with an energetic, invisibly decaying Z. Background processes can also produce MET.
Build large-radius jets. I cluster jets with a radius parameter of about 1.0 and use the highest-p_T jet as the starting Higgs candidate.
Check the transverse-momentum balance. If the Higgs and the Z recoil against each other, the jet’s p_T should be comparable to the MET. I apply a loose cut on the ratio.
Look for bottom hadrons. Rivet’s particle-level b-tagging utilities let me check whether the jet contains a bottom hadron.
Groom the jet. With FastJet, I apply the modified mass-drop tagger (mMDT). It undoes the clustering until it finds a sufficiently balanced split, discarding soft branches along the way.
Check the mass. I keep candidates with groomed masses in a window around the Higgs mass, roughly 115–140 GeV in this setup.

I can run the same selection on signal and background samples and compare:

How many signal events pass the selection.
How often a background event passes the same cuts.
How distributions such as jet p_T, MET and jet mass change as I apply the cuts.

I start with Standard Model samples to understand the cut flow. Then I vary the HEL coefficients c_HW, c_HB and c_H to see how the selected yield and distributions respond, especially in the high-p_T tail.

I use particle-level events to study the selection. An experimental sensitivity estimate would also account for detector response and realistic pile-up.

The Rivet routine gives me a test bench. Can a boosted-Higgs selection keep enough of the changes I saw in the generator to make this channel worth a closer look?

How we simulate collisions before they happen: MadGraph and Herwig

Wed, 26 Nov 2025 14:44:12 +0000

One slightly strange thing about studying a future collider is that I spend most of my time analysing collisions that have never happened. The events come from Monte Carlo generators, which let me test an analysis before there’s a detector to run it on.

For this FCC study I use MadGraph and Herwig. Both generate simulated events. In my workflow, they also provide an independent check on each other.

MadGraph handles the hard scattering, the short-distance part of the collision. For associated Higgs and Z production, I specify the process (for example, p p > z h), the model (the Standard Model or HEL) and the beam energy. It uses the matrix elements to sample parton-level kinematics and assign event weights.

Herwig can also generate the hard process. I use it for the stages that turn a few outgoing partons into a whole event:

Parton showering models further emissions, such as quarks radiating gluons.
Hadronisation turns the coloured partons into colour-neutral hadrons.
Unstable particles decay, leaving the final-state particles I can analyse.

Before running Rivet, I compare the two generators on a small set of checks:

Compute ZH cross sections with matched process definitions and inputs at 13 and 85 TeV.
Check the Standard Model limit by setting the HEL Wilson coefficients to zero.
Turn on one benchmark with non-zero c_H, c_HW and c_HB, and compare the resulting changes in the rate.

In my literature review, the coefficient-zero cross sections agreed within the quoted statistical uncertainties at both energies. At the illustrative 85 TeV benchmark, both generators predicted a much larger cross section than the baseline. Their predictions differed by about 4%, more than the quoted Monte Carlo integration uncertainties.

The comparison gives me two checks before I run Rivet. The two setups recover the same baseline within their quoted uncertainties and both respond strongly when I switch on the benchmark coefficients. A process definition or model setting can quietly change which events end up in the sample.

Once the checks are in place, I use Herwig’s showered and hadronised events as particle-level input to Rivet. MadGraph is still there for cross-checks as I change energies or coefficients.

That’s what I mean by “simulated FCC collisions”: a sample of possible events under a specified model and set of inputs. Rivet then gives me a way to ask whether the differences between two HEL settings would show up in an observable I can actually build.

From the LHC to the FCC: why build an even bigger collider?

Mon, 24 Nov 2025 17:17:45 +0000

AI-generated tunnel illustration.

I spend a lot of time thinking about a machine that doesn’t exist yet: the Future Circular Collider (FCC). The LHC is still running and has already given us the Higgs. What would we learn from building another collider?

The Large Hadron Collider is a 27 km ring beneath the French–Swiss border. In Run 3, two proton beams at 6.8 TeV each collide at a centre-of-mass energy of 13.6 TeV. ATLAS and CMS are general-purpose detectors. LHCb specialises in flavour physics, while ALICE studies heavy-ion collisions.

Since its first physics run in 2010, the LHC has discovered the Higgs and made precision measurements of electroweak, top and flavour processes. The High-Luminosity LHC upgrade aims for about ten times the integrated luminosity of the original design. That larger dataset will give rare processes a better chance to show up.

Collision energy sets a different limit. Heavier particles can require more energy than the LHC can provide, and even Standard Model processes such as Higgs-pair production are hard to measure precisely. Higgs pairs are one of the ways to study how the Higgs interacts with itself.

The 2025 FCC feasibility study outlines two stages in a proposed 90.7 km tunnel:

FCC-ee: a high-luminosity electron–positron collider.
- The proposal covers several energies: the Z pole, the threshold for W-pair production, Higgs production around 240 GeV, and the top-pair threshold programme extending to roughly 365 GeV.
- The well-defined electron–positron initial state would let us measure Higgs and electroweak properties with much smaller uncertainties.
FCC-hh: a later proton–proton collider in the same tunnel, in the region of 100 TeV depending on the magnet technology.
- This is the stage I study. My simulations use 85 TeV as a benchmark.
- The higher energy would extend the search for heavy new particles and yield many more events from rare processes such as Higgs-pair production.
- The challenge is experimental: many proton collisions can overlap in one bunch crossing, on top of the backgrounds already present in the hard collision.

For Higgs physics, the stages ask complementary questions. FCC-ee would sharpen measurements of absolute Higgs couplings and help infer the total width. FCC-hh would reach further into rare processes and the high-p_T tails, where some departures from the Standard Model would be easier to see.

I study Higgs production alongside a Z boson. I want to know whether a boosted ZH analysis can isolate the signal well enough to probe Higgs–gauge interactions at FCC-hh.

What would another collider give us?

More precise measurements of Higgs properties that are still poorly known.
Access to higher energies and more events from rare processes.
Two complementary ways to look for new physics, whether it appears as a new particle or as a small change in a familiar interaction.

Effective Field Theory and why I am using the Higgs Effective Lagrangian

Mon, 24 Nov 2025 17:15:59 +0000

One of the questions behind my project is whether we can learn about new particles that are too heavy to produce directly. Effective field theory (EFT) gives us a way to look for their indirect effects.

I start with the Standard Model and ask what extra terms we can build from its fields while respecting its symmetries. The higher-dimensional terms are suppressed by powers of a heavy scale. At energies well below that scale, the first few terms give a useful description of how heavy new physics could change what we measure.

With those terms in hand, I can ask which changes to Higgs interactions are consistent with the symmetries and how large the data allow them to be. The description applies to different high-energy theories that produce the same low-energy interactions.

I use a particular implementation called the Higgs Effective Lagrangian (HEL). It extends the Standard Model Lagrangian with higher-dimensional operators. Each operator has a Wilson coefficient that sets the size of its contribution in the chosen basis.

Some useful groups of operators are:

CP-even bosonic terms, which can change the Higgs kinetic term and potential as well as interactions with W and Z bosons and photons. This is the part I spend most of my time on.
CP-odd terms, which can introduce new sources of CP violation.
Fermionic terms, which can alter Higgs interactions with quarks and leptons or add dipole interactions.
Pure gauge terms, which can change interactions among gauge bosons.

I vary a small set of coefficients, including c_H, c_HW and c_HB, and look at Higgs production alongside a Z boson (ZH). I’m interested in both the overall rate and the shape of the transverse-momentum distribution.

Some operators give Higgs interactions a new dependence on momentum. A small effect in an inclusive rate can stand out in the tail of a distribution. That is where I check whether the energies still fall within the EFT’s range of validity.

A future proton collider such as FCC-hh would make those energetic events easier to study. My job is to find out whether the changes survive event generation, jet reconstruction and selection strongly enough to constrain the coefficients.

Three things I keep in mind when reading the plots:

The operators describe possible low-energy effects without specifying the particles that caused them.
The coefficients act as dials, but which dial changes what depends on the operator basis.
Boosted events can be especially sensitive to momentum-dependent terms.

The rest of the project is about turning that clean theoretical idea into a messy collider analysis. If nature has turned one of those dials, would I notice?

Week 5 – Tightening cuts, first BSM point, and a dark matter detour

Mon, 24 Nov 2025 17:10:37 +0000

This week I tightened the ZH selection, switched on my first non-zero Wilson coefficients and took a detour into dark matter detection.

Monday 27 October · Dark matter and “scintillates like a pig”

Monday’s dark matter lecture was a nice break from arguing with Herwig run cards.

Galaxy rotation curves, gravitational lensing and the cosmic microwave background all give us evidence for dark matter through gravity. Its particle nature remains open. We looked at three ways to search for it:

Direct detection, looking for scattering in a target such as liquid xenon deep underground.
Indirect detection, looking for possible decay or annihilation products.
Collider searches, looking for signatures such as missing transverse momentum.

The fun part was comparing the detector technologies:

Dual-phase experiments such as LZ and DarkSide-50 record prompt scintillation (S1) and a delayed signal from electrons extracted into gas (S2). DEAP-3600 instead uses scintillation in single-phase liquid argon. Liquid xenon “scintillates like a pig”, apparently.
Cryogenic solid detectors can read out phonons, sometimes alongside light or ionisation, depending on the material and design.
Gaseous detectors can give lovely track information, though the low density makes it harder to achieve a large target mass.

We also talked about backgrounds: uranium and thorium decay chains, radon, neutrons from (α, n) reactions and cosmic-ray activation. Before a possible dark matter signal ever appears, the detector is already busy with the Standard Model.

I liked seeing the same question approached from so many angles, each with its own background to understand.

Focusing on the boosted region in Herwig

Back to ZH.

To get closer to the phase space where my boosted-Higgs tagger is useful, I tried generator-level transverse-momentum cuts in Herwig:

set /Herwig/Cuts/JetKtCut:MinKT 150*GeV
set /Herwig/Cuts/JetZ0Cut:MinKT 150*GeV

The cross sections behaved as I’d hoped:

The ZH cross section dropped sharply once I selected events with a high-p_T Z.
MadGraph and Herwig agreed on the smaller rates within the statistical uncertainties quoted for those samples.

I also tried a Z transverse-momentum cut around 400 GeV. Both generators gave rates of order 10⁻² pb at 85 TeV for that selection. In these boosted events, the two sprays from the Higgs decay are often close enough to fit inside a single large-radius jet.

My first BSM benchmark

With the Standard Model baseline in place, I tried a deliberately large HEL benchmark:

c_H = 0.2
c_HW = 0.1
c_HB = 0.1

I ran the benchmark at 85 TeV to check how MadGraph and Herwig responded to the same changes.

The benchmark comparison gave:

A coefficient-zero cross section of about 5–6 pb.
About 197 pb in MadGraph and 205 pb in Herwig at the non-zero point.

Both generators showed a large increase at this point, giving me an implementation check. For a wider grid of coefficients, I’d first establish where the EFT approximation holds.

Reading the Rivet cut flow

I ran larger samples through the Rivet routine so I could see what each cut was doing.

An event has to pass all of these checks:

Missing transverse momentum above the threshold.
A leading large-radius jet that passes the p_T and pseudorapidity cuts.
Bottom-hadron content in that jet.
A groomed jet mass between about 115 and 140 GeV.
A jet p_T to MET ratio of roughly 0.8–1.2.

The Herwig logs let me count:

Events that pass the MET cut.
Events that survive the large-radius jet and b-tagging requirements.
Higgs candidates left after the mass window.

The early cut flows were stable enough to show where the selection was losing events.

Small quality-of-life improvements

I also got tired of typing the same commands:

Set up shell aliases for quicker cluster logins.
Wrote a small qsub script to submit Herwig jobs.
Organised the runs by model and selection so I can tell which settings produced which output.

Future me will probably be grateful.

Friday 31 October · ATLAS and Halloween

Alex gave a talk on the Global Trigger at the Friday UCL ATLAS meeting.

We also went through collaboration updates, which was a change of scale after spending most of the week on one event selection.

The updates covered committee roles, institutes joining ATLAS and the work that keeps the collaboration running.

It was slightly surreal to sit in a small room on Gower Street and see my project supervisor’s name come up in a discussion of outreach for a collaboration of thousands.

The list of roles went well beyond physics analysis: computing, data preparation, trigger, publications, early-career support and more. Every plot depends on people doing that work.

I spend most days thinking about a narrow FCC study. It was useful to see how many ways there are to contribute to a large experiment, and how much of that work happens long before the analysis.

What came together this week

I now have ZH samples in the boosted region, one benchmark that tests the generator setup, and a Rivet cut flow I can read from start to finish.

P.S. Easily the coolest Halloween costume ever. 👻

Week 4 – Cross-section detective work and the Rivet Routine the goat

Mon, 24 Nov 2025 16:54:16 +0000

Three patties for nine quid at the UCL burger shop. A decent start to a week of theory revision, digging through old configs, and finally getting my Rivet routine to run.

Tuesday 21 October · Why was the cross section so big?

We started Tuesday’s meeting with a quick bit of theory.

The Higgs doublet has four real degrees of freedom. After electroweak symmetry breaking:

Three provide the longitudinal polarisation states of the W⁺, W⁻ and Z bosons.
The fourth is the physical Higgs boson.

That’s why the Higgs and electroweak gauge sectors are tied together. The connection matters for my boosted ZH study, where I’m testing changes to Higgs interactions with gauge bosons.

Then we sorted out what we meant by inclusive and exclusive:

An inclusive measurement could count events with a high-p_T ZZ system reconstructed from four leptons, regardless of what else is produced.
For the generator comparison, I wanted a hard-process sample restricted to ZH, excluding contributions from ZZ and HH.

That distinction turned out to explain the surprisingly large cross section I’d attributed to ZZ in Herwig over the summer.

I compared the two generator configurations:

MadGraph was only generating p p > z h.
The Herwig HEL constructor was generating several processes together, including ZH, ZZ and HH.
W production was switched off in my Herwig configuration, but the model still included Higgs-sector couplings to W and Z bosons.

I’d been comparing unlike samples. Once I set HPConstructor:Processes to Exclusive and restricted Herwig to ZH, the coefficient-zero cross section came down to about 0.56 pb, in line with MadGraph for that setup.

Mystery solved by a configuration change. A useful reminder to check what’s actually in the sample before interpreting the number.

Does HEL recover the Standard Model?

The next check was to set the HEL Wilson coefficients to zero and see whether the total rate recovered the Standard Model baseline.

I generated ZH samples in MadGraph and Herwig at 13 and 85 TeV. With the coefficients set to zero:

MadGraph’s HEL cross sections matched its Standard Model setup.
Herwig’s HEL cross sections agreed with MadGraph within statistical uncertainties once I restricted it to ZH.

The matched ZH rates at 13 and 85 TeV give me a baseline for the next comparison, with the coefficients switched on.

Turning ZH into something I can measure

The other big job was getting the Rivet analysis into shape.

Here’s the process I’m targeting:

A quark and antiquark produce a Higgs and a Z boson.
The Z decays to neutrinos, leaving missing transverse momentum (MET).
The Higgs decays to a bottom quark and antiquark. At high boost, their particle sprays can fit inside a single large-radius jet.

That gives me two things to look for in the same event:

A large-radius jet with bottom-hadron content.
Large MET.

The selection in analyze(const Event& event) goes roughly like this:

Check MET. Keep events above a threshold to focus on the boosted region.
Build large-radius jets. Use a radius parameter around 1.0 and take the highest-p_T jet as the starting Higgs candidate.
Apply basic jet cuts. Require the leading jet to pass thresholds in transverse momentum and pseudorapidity.
Check the recoil. Require the ratio of MET and jet p_T to sit in a loose window, around 0.8–1.2. Approximate balance is consistent with a Higgs recoiling against a Z.
Look for bottom hadrons. I use Rivet’s b-tagging utilities. For example, pre_mmdt_bTags = leading_fj.bTags() lets me inspect the jet before grooming.
Groom the jet. Apply the modified mass-drop tagger (mMDT) to look for a hard two-prong split.
- Discard soft branches as the clustering is undone.
- Keep a split with two sufficiently hard branches.
- Use z_cut to set how balanced the split must be.
Apply the Higgs mass window. Keep the candidate if the groomed jet mass is between about 115 and 140 GeV.

I fill histograms for jet p_T, MET and jet mass. I also count how many events pass the selection so I can see what each change does to the tagging efficiency.

Rivet versus Contur

My original plan was to let contur-batch generate the Herwig jobs, then drop in the new Rivet analysis.

That took longer than I expected:

Contur’s config.dat kept overwriting my edited herwig.in.
Herwig jobs started by Contur couldn’t see the analysis.
I read the Contur Rivet README and still couldn’t get Herwig to load it.

Here’s what got the routine running:

Use Contur to create a baseline herwig.in and directory layout.
Edit the run card and launch Herwig directly.
After a fresh login, add the directory containing the compiled Rivet analysis to RIVET_ANALYSIS_PATH.
Check herwig.log to confirm the analysis was loaded and that its cut flow appeared.

That workflow now runs reliably for this setup. Contur turned out to be useful as a starting template while I was getting the analysis to work on its own.

What I can build on

I have a cross-checked coefficient-zero ZH rate, a Herwig sample restricted to the right process, and a Rivet routine that finally produces numbers. A week for getting the basics right.

Week 3 - Less working, more meetings

Wed, 22 Oct 2025 14:29:18 +0000

Figure 1. Marble Arch, finally free of scaffolding.

Master’s applications took up most of this week. The project moved forward in meetings, where I got a clearer idea of what to check next.

Tuesday 14 October · FCC group meeting
I joined Jon, Tim, Wei, Lauren and Stephen for my first group meeting. We went back over my summer study of ZH production, where I used a modified mass-drop tagger to look for highly boosted Higgs bosons.

The event samples are ready. I’ll check which events the tagger keeps before starting another scan.

We also talked through the Higgs Effective Lagrangian (HEL). I’m trying to understand which of its effects can be expressed as shifts in Standard Model couplings in the κ framework, and which need a different description.

I showed the group my summer plots of the high-p_T tails in ZH production. Some deviations were large enough to catch the eye. I’ll check the generator setup for Higgs production alongside a vector boson before interpreting those tails.

Models and tools
We use MadGraph and Herwig to generate events, and Rivet to analyse them. The main channel is ZH, with the Z decaying to neutrinos and the Higgs to a bottom quark and antiquark. Other processes can leave a similar signature. We discussed di-Higgs production as a possible extension.

Main goals
The broader question behind these checks is:

Is the Higgs truly a fundamental scalar particle?

For this project, that means asking how sensitive the high-p_T region is to changes in Higgs interactions. My next steps were:

Compare Standard Model and HEL cross sections at 13 TeV and at several energies between 50 and 90 TeV. With all Wilson coefficients set to zero, the HEL samples should recover the Standard Model baseline.
Cross-check Wei’s MadGraph setup against HEL in Herwig.
Work out how Contur uses measured distributions to constrain simulated new-physics contributions.

Figure 2. The short-term plan and a sketch of quark–antiquark production of ZH.

Friday 17 October · ATLAS meeting
I also sat in on an ATLAS meeting. My notes were mostly about how many separate pieces have to work before anyone gets to analyse a collision.

Phase II upgrade: progress on power converters and other detector preparations.
Inner Tracker (ITk): preparations for the High-Luminosity LHC.
Accelerator: configuration for high-intensity running.
Data taking: a reported efficiency of 96.5%.
Detector and trigger: performance updates.

Figure 3. A summary of the ATLAS and CMS Run 2 Higgs-pair combination.

Week 2 - BRAVO Tuesday!

Mon, 13 Oct 2025 00:59:17 +0000

Time for the researching of the research papers. I wanted to find published bounds on two of the Wilson coefficients in our study, c_HB and c_HW.

Lucky me. The second paper I picked, The Effective Standard Model after LHC Run I by John Ellis, Verónica Sanz and Tevong You, already discusses the operators I’m looking at. I’ll check with Jon how directly their bounds apply to our setup.

Two terms helped me read the paper. An operator is a term built from fields in the Lagrangian, and a Wilson coefficient sets how strongly that term contributes.

Coupling constants

A coupling constant sets the strength of an interaction between fields or particles.
Examples:
- g is an example of a gauge coupling.
- y_f is the Yukawa coupling for a fermion of flavour f.
- g_hZZ denotes a coupling between the Higgs and two Z bosons.
In the Standard Model, the theory fixes the form of the interactions. Measurements determine the values of the input parameters.
Higher-dimensional operators can shift some couplings or add interactions with new momentum dependence.

The paper shows why the high-p_T region matters. Operators such as the one multiplied by c_HW can introduce momentum-dependent terms in Higgs interactions with electroweak gauge bosons. Those terms can leave a larger imprint in energetic events, so the shape of a distribution can tell us more than its total rate.

Next on the list is Complete Higgs Sector Constraints on Dimension-6 Operators, by the same authors. I’m still working out how to connect these coefficients to the κ framework. I’ll ask Jon, and this time I promise to write it all down.

That’s enough paper reading for now. Tomorrow is a day off from the project. 😌

Mid-Autumn Festival

Mon, 06 Oct 2025 19:32:06 +0000

At Monday’s meeting, I showed Jon my Run 3 and Run 4 heat maps. I’d zoomed in too far on Run 3, so I widened the view for Run 4. We traced the approximate contours by hand. Firm limits on the Wilson coefficients will take a more detailed study. My next step is to connect the coefficients to the κ framework, which describes deviations from Standard Model coupling strengths.

It was also the Mid-Autumn Festival, so I brought Jon and Peng some mooncakes. The festival falls on the fifteenth day of the eighth lunar month, around the full moon. The round mooncakes are a symbol of reunion. Perhaps unification in physics is within reach too. :)

Jon’s sketch of the Feynman diagrams that can contribute at different energy scales.

Next on my list are the papers that cite the Higgs Effective Lagrangian. I didn’t get to them today. Tomorrow, then.