Added MG5 cards for toponium (EtaT) + 0j

[AWildridge]

This is for toponium as outlined here: https://arxiv.org/abs/2102.11281 .

[menglu21]

btw, i didn't see this model under https://cms-project-generators.web.cern.ch/cms-project-generators/, maybe it needs to be uploaded there

[afiqaize]

I would also like to take the chance to ask about the rationale behind making this sample now. The version of the model we currently have at hand is incomplete, in the sense that it does not come with the pNRQCD reweighting necessary to have a sample that correctly describes the toponium distributions. Although in my initial discussions with the authors, they mentioned providing this reweighting as an add-on, on a later discussion following one of the talks by the authors on this subject, they mentioned that they decided to change their approach, and instead to provide a complete model with the reweighting already applied out of MG5.

To my knowledge, this has not happened yet. While it remains unclear when will this happen, presumably the initial approach of providing the add-on reweighting is no longer considered by the authors. I think it's best to clarify with the authors what are their plans on this, before we make a large sample with an obsolete use case.

[menglu21]

I would also like to take the chance to ask about the rationale behind making this sample now. The version of the model we currently have at hand is incomplete, in the sense that it does not come with the pNRQCD reweighting necessary to have a sample that correctly describes the toponium distributions. Although in my initial discussions with the authors, they mentioned providing this reweighting as an add-on, on a later discussion following one of the talks by the authors on this subject, they mentioned that they decided to change their approach, and instead to provide a complete model with the reweighting already applied out of MG5.

To my knowledge, this has not happened yet. While it remains unclear when will this happen, presumably the initial approach of providing the add-on reweighting is no longer considered by the authors. I think it's best to clarify with the authors what are their plans on this, before we make a large sample with an obsolete use case.

i agree that discussion with authors is needed, if they are not going to support the add-on reweight, events produced with current model may be useless.

[afiqaize]

I asked Benjamin Fuks, and he confirmed that there is no plans from the author team to support additional reweighting of events generated from the current version of the model.

The team are working on some additional checks before releasing the complete model.

[ajung42]

The idea is to get this done - this is a negligible amount of MC to produce and even if the samples turn out to be non-usable or non-rescuable by a later reweight its still worth doing the production given how small a sample is needed. It can still allow valuable insights into a potential measurement, which needs eff*acc to get anywhere in the first place.

So, as mentioned already to some in other threads/emails: lets just do as best as we can right now with steering cards but then generate this.

[menglu21]

The idea is to get this done - this is a negligible amount of MC to produce and even if the samples turn out to be non-usable or non-rescuable by a later reweight its still worth doing the production given how small a sample is needed. It can still allow valuable insights into a potential measurement, which needs eff*acc to get anywhere in the first place.

So, as mentioned already to some in other threads/emails: lets just do as best as we can right now with steering cards but then generate this.

ok, then please follow @agrohsje comments to modify the top mass stuffs. After that, it's fine to merge these cards, but i would suggest you do the event production privately, as the official production could take long if it's injected with normal priority.

[AWildridge]

All of the suggested changes have been implemented. I am currently working on uploading the model to https://cms-project-generators.web.cern.ch/cms-project-generators/. The changes in the invariant mass of toponium have also been propagated to the LHEInvariantMassFilter even though that change is not showcased in either of these commits. Please let me know if additional changes are required before these commits are merged into the master branch.

[Saptaparna]

Hi AJ, were you able to upload the model? I can upload it for you. Let me know.

[afiqaize]

@AWildridge and myself discussed about making a CMSSW PR for the LHEInvariantMassFilter plugin [1] used in the fragment. After doing some surveys this appears not necessary, as another filter is available in CMSSW that is acceptable for our current purpose [2].

[1] https://github.com/afiqaize/GeneratorEventFilter
[2] https://github.com/cms-sw/cmssw/blob/master/GeneratorInterface/GenFilters/plugins/LHEGenericMassFilter.cc

[AWildridge]

With the generous help of Sapta the model has now been uploaded and is located at: https://cms-project-generators.web.cern.ch/cms-project-generators/

We've also decided to produce the semileptonic channel for toponium so I have now included those relevant cards as well. I also noticed that the b and b~ quarks were missing from the proton for the dileptonic cards so I have added those as I believe they should be included.

Unless there are any additional changes needed for these semileptonic cards I would ask that these cards be approved so that a central production of these samples can commence. Thank you very much to everyone for their help and guidance in producing these cards.

[afiqaize]

Maybe you can elaborate why you believe b should be added to the proton?

The model was implemented only in terms of new top-gluon vertices (g-g-eta, g-g-g-eta and t-tbar-eta, which you can see by checking parameters.py, couplings.py and vertices.py), so the result should be unchanged in any way in the 0j scenario being explored here.

[AWildridge]

Maybe you can elaborate why you believe b should be added to the proton?

The model was implemented only in terms of new top-gluon vertices (g-g-eta, g-g-g-eta and t-tbar-eta, which you can see by checking parameters.py, couplings.py and vertices.py), so the result should be unchanged in any way in the 0j scenario being explored here.

My thought process was that the parton distribution for b's is non-zero and could therefore radiate additional gluons depending on the factorization scale that is set. However, I am now recalling that fixed_fac is set to zero so perhaps I am not certain how factorization is treated for this sample.

If these radiated gluons cannot participate in the hard process, then I can see why this would not be relevant for a 0j sample. I am still a novice when it comes to MC generation so sorry for any misunderstandings I may have. In essence, I just felt this was a more accurate description of the proton and therefore should be included to remove any additional scrutiny to these MC samples.

[AWildridge]

@menglu21 Just a friendly notification regarding the status of this PR :) Please let me know if I need to change anything else about these cards so that they can be accepted.

[menglu21]

Hi @AWildridge sorry for the late reply. as for the proton definition, i think @afiqaize is correct, another reason is that you may need to keep the proton flavor consistent with the "4 = asrwgtflavor" in the run card, so i think you can use 4flavor proton definition. btw, how did you choose this value "DECAY 9000005 7.0", i run a local test and found the width is very small ~0.003 GeV

[afiqaize]

The DECAY parameter is based on the recommendations made by model author, so I don't think it needs changing.

The lineshape gotten from the sample as-is is not supposed to be physically sensible, it's only a starting point for subsequent reweighting we discussed.

[menglu21]

ok, the shape is expected to be very similar with those decay width, it will affect the final cross section, so i can bypass it if you don't care much about the cross section.

[AWildridge]

@menglu21 Sorry for the delayed response, wanted to check with people more senior than myself before I commented. But yes, we are aware that this sample has cross-section issues and will need to be appropriately re-weighted. Currently, this is the best model we have available for toponium so we would like to proceed with the production of this sample and perform the required reweightings as necessary.

[menglu21]

thanks, sounds reasonable to me. @Saptaparna @GurpreetSinghChahal @mlizzo please have a look and fell free to merge.