Figure out double bump in number of primary vertex distribution in signal

[caredg]

As described here there is a new problem with the observation of a double bump in the number of primary vertex distribution in the signal. It seems like there are two minbias profiles embeded in the simulation. I will run some tests to figure out how to fix it.

[caredg]

First, let's look at one of the files that we got before "fixing" the spike in the electrons eta (#35). This one correspond to the ntuple from the signalStudy_round3 batch. The npv distribution look like:

It is not very clear, but it seems that I see structure there as well.

[caredg]

Now, will try to generate a few thousand events (in separate jobs, as always) and look at the merged. First, I ran without pileup altogether. Just to check what is the npv distribution. As expected, there is no pile-up. So the PU mixing module is working (at least doing something)

[caredg]

I also switched off the file randomization lines I introduced earlier and made a test keeping just the first minbias file and the seed randomization: The structure remains.

Then, I switched off the seed also (although this would be the same as what we had before, I just wanted to double check):

with similar results.

[caredg]

Then, I was checking the production of track-enriched QCD samples. If I look one of these file I see this distribution: It looks more complete, although one can still appreciate the holes. So, after looking at their configuration, it looks like giving the whole MinBias dataset does the trick. This seems to be the only difference with our original configuration (before trying to fix the electron eta issue). I will try to run like this, maybe I am misunderstanding how the mixer works.

[caredg]

I ran the simulation with no random seeding but with the whole dataset of MinBias files. It seems that the same file (although not the first one) is always opened. As expected structure is present in the npv plot: and the old electron eta problem is also present:

Next I will run with less statistics (because I do not think that is the problem) but with the random seeding and the full minbias dataset.

[caredg]

Simulating with the random seed and all the MB files, I get similar results The hole is somewhere different. So I will test just randomizing the MB files but without seed.

[caredg]

@JonaJJSJ-crypto When I run without randomizing the seed but only randomizing the picking of the MB files, I obtain this distribution:

So my interpretation now is that the random seeding that I was trying is introducing some bias. If I do not randomize the seed but neither I randomize the file, however, the same MB file is run over and over, which introduces also a bias.

So for now, I guess I will reprocess all the signal files with this new procedure, i.e., only randomizing the picking of the MB files.

To check that we do not see any of the previous structures (in the electron eta, for instance), I also checked this plot, which seems fine:

[caredg]

This still no good enough. One can still see structure. More study pending....

[caredg]

Estoy tratando de hacer pruebas adicionales. Para descartar problemas con la generación de la señal, intenté generar DrelYan desde gen. Primero generé 200 eventos utilizando el cmsDriver y todos los switches exactamente como lo hacemos para LW: Este es el gráfico para eta de electrones: Es difícil de decir algo con tan pocos eventos. Así que generé 2000 en el cluster, con idéntica configuración. El gensim tomó como 16 horas, el hlt como 3 horas y el reco otras 3 horas. Mi preocupación es que el cortar la generación en porciones pequeñas de eventos esté generando alguna redundancia en el mixingmodule por lo que quiero ver cuál es el resultado generando más eventos de corrido (el framework se supone que debe poder lidiar con eso). Estos son los gráficos: Parecería ser que no existe estructura.

Voy a intentar generar LW con miles de eventos en una sola corrida para ver si hay cambios....