"Biasing factor is too large" warning

[tvami]

Is your feature request related to a problem? Please describe.

After running https://github.com/LDMX-Software/ldmx-sw/issues/1533 successfully I see

[ PhotoNuclearXsecBiasingOperator ]: [ WARNING ]: Biasing factor is too large.

This means

https://github.com/LDMX-Software/ldmx-sw/blob/9458b6baf1a4d0beb04dba82073037b1e40cacc6/SimCore/src/SimCore/BiasOperators/PhotoNuclear.cxx#L63C25-L63C40

emXsecBiased == pnXsecUnbiased_

which kinda makes me wonder if we are not actually biasing?

Describe the solution you'd like

Well this is more of a question on what all this means

[tomeichlersmith]

https://github.com/LDMX-Software/ldmx-sw/blob/9458b6baf1a4d0beb04dba82073037b1e40cacc6/SimCore/src/SimCore/BiasOperators/PhotoNuclear.cxx#L61-L66

These lines are just there to make sure that the biased electromagnetic xsec never falls below the normal (unbiased) photon-nuclear cross section. In that regime, the PN events generated would almost certainly be over sampled.

You'll notice that this message is only a warning and that's because it could happen a few times in a run by chance and we aren't way over sampling. I'd be concerned if you are seeing this hundreds of times per event (meaning almost every interaction is over biased).

[tvami]

I ran on 10 events, this came up 226 time, I guess it's fine?

[bryngemark]

When we tuned the PN biasing factor to 450 and 550 respectively, the advice from Natalia was to pick the highest biasing factor (to reasonable level of precision) where these warnings would no longer come up. If you choose a higher value than that, it is up to you to demonstrate that you aren’t skewing the resulting distribution (like pushing interactions to lower z). I don’t think we have any other handles on this but the warning is there for a reason.

[tvami]

Oh interesting, but this is with the default biasing, i.e. 550

[tvami]

OK, closing this now as my question was answered and the rate of this is not concerning enough, thanks for the answers

[bryngemark]

Sorry to be late here but then I think we should retweak the biasing factor. 20 warnings per event is way too high in my opinion, if I were to put a number larger than 0, I'd say it should be less than percent-level.

[tvami]

OK I reopened it

[tvami]

Oh interesting, but this is with the default biasing, i.e. 550

Actually I think the defaults were never updated, so it's still 450 even:

https://github.com/LDMX-Software/ldmx-sw/blob/b3195994ada82b76b2e540bcca00de8140ed26d5/Biasing/python/ecal.py#L60

 sim.biasing_operators = [ bias_operators.PhotoNuclear('ecal',450.,2500.,only_children_of_primary = True) ]

[bryngemark]

Huh. Then it might be a beam energy thing? Hopefully it goes away with the right biasing and filter threshold (550, 5000).

[tvami]

with 450 & 2500 --> 239 / 10 event (took 1039 events to produce 10) with 550 & 5000 --> 251 / 10 event (took 1122 events to produce 10) with 550 & 5000 & tagger & target filters changed --> 229 / 10 (took 765 events to produce 10)

After this I made a scan with 400 & 5000 & tagger & target filters changed --> 558 / 10 (took 1679 events to produce 10) with 450 & 5000 & tagger & target filters changed --> 432 / 10 (took 1001 events to produce 10) with 500 & 5000 & tagger & target filters changed --> 166 / 10 (took 676 events to produce 10) with 550 & 5000 & tagger & target filters changed --> 229 / 10 (took 765 events to produce 10) with 600 & 5000 & tagger & target filters changed --> 253 / 10 (took 486 events to produce 10)

Seems like the 500 is around the minimum, I also looked at with 525 & 5000 & tagger & target filters changed --> 210 / 10 (took 477 events to produce 10)

[tvami]

@tomeichlersmith @bryngemark I update the comment below with more data points. Werent we expecting that lowering the factor will reduce the number of these msg?

[bryngemark]

@tvami i agree this is bizarre. does going to something very low (100? 10? 2? 1?) make the warning go away?

[tvami]

OK here is some other points (all have the conditions as in https://github.com/LDMX-Software/ldmx-sw/pull/1548 + changing xsec_bias:

100: 0/10 (Started 5554 events to produce 10 events) 200: 0/10 (Started 1920 events to produce 10 events) 300: 410/10 (Started 1274 events to produce 10 events.) 400: 558/10 (Started 1679 events to produce 10 events.) --> this is the same number as earlier, this was more of a sanity check

Finer scan: 250: 248/10 (Started 1685 events to produce 10 events.) 240: 187/10 (Started 1954 events to produce 10 events.) 235: 117/10 (Started 2117 events to produce 10 events.) 230: 0/10 (Started 869 events to produce 10 events.) 220: 0/10 (2043 events to produce 10 events)

So I ran 230 with a 100 events and 1000 events 230: 0/100 (Started 21216 events to produce 100 events.) 230: 0/1000 (Started 178725 events to produce 1000 events.)

So this seems to be an ok number? I'm not sure what to do next, since I think trunk is not ready for this update. I guess this should go in before the next production campaign after the DR is finalized? Tho I can make the PR and just have it draft for some time?

[tomeichlersmith]

I think that is a good plan. I fear that we doubled it when we doubled the energy but didn't see any messages because they went into the silenced G4 messaging system. Thinking about it, it does make sense to (approximately) half the biasing factor when we double the energy.

[tvami]

ok I'll open a draft PR and we can just merge it when we are ready

[bryngemark]

hm. i thought that as the xsec for PN events decreases with higher beam energy, it made sense that we could increase the biasing. but i admit i haven't thought about it much and the logic may be backwards. i did see warnings when trying more than 550 (increasing from 450, not 225) so i'm not sure message suppression is the explanation.

regardless, if we cut the biasing in half, it would be great to see a comparison (between 550 and 230) of the distribution of ecal z position of the photon interaction vertex, to verify that we haven't been doing something bad all along.

[tvami]

For documentation; here is the link to the SWAN meeting talk regarding this: https://indico.fnal.gov/event/68163/#32-biasing-factor-studies-for

[tvami]

I made the changes as implied by Natalia's comments in https://github.com/LDMX-Software/ldmx-sw/pull/1566

Now tho, if I increase the factor to huge numbers, there are no warnings...

[tvami]

From Natalia

I think our estimates of the appropriate biasing factor are based on tungsten, which dominates the ecal material budget, or on some sort of weighted average of materials.

BUT we’re biasing in the whole ecal. Brem xsec scales like Z^2, while PN scales like A. So if sigma_PN / sigma_brem ~ few x 10^-5 in tungsten (leading to about 1/70 production efficiency overall as seen), then in hydrogen it's close to 1e-3 and with a biasing of 550 we may be close to saturating that warning. The fraction of events where we sample the hydrogen cross-sections is low, and completely random.

If this is what's going on, then I'm not worried at all -- what we're getting wrong is the effect of the hydrogen on the total radiation thickness of the detector, which is a minor effect to begin with and we're probably getting it wrong by a factor <2. Indeed the histograms Tamas showed tell us that we're not sculpting the z distribution to a noticeable degree.

[tvami]

Final talk at SWAN: https://indico.fnal.gov/event/69925/#34-ecal-pn-overbiasing