Question/feature request: squared matrix element as double instead of float

[Romendakil]

Hi all, for processes with initial state radiation (ISR) at the ILC, matrix elements can become rather large. Within the Linear Collider Generator Group we decided to write squared matrix elements as event-by-event (pseudo-)weights into the LCIO header. The parameter containers there allow only float, not double variables (file size, I assume?). For the event weights the matrix elements get rescaled by the corresponding phase space fluxes and Jacobians and end up as "reasonable" numbers, but the pure matrix elements can potentially exceed the numerical range of float. There are a few options: (1) WHIZARD only writes out the weight, not the squared matrix elements, as the float ME is not reliable as a number (2) the parameter collection is changed in LCIO from float to double. Could raise problems with file sizes and the ILCSoft framework later in the chain. (3) introduce a special class member sqme similar to weight in the LCEventImpl class. This would work for "the" ME, but not for alternate weights if one is scanning over a selection of model parameters. Then a collection is needed, or a single parameter for sqme and a collection for alt_sqme. For options (2) and (3) we could simply make the interface to LCIO dependent on the LCIO version, and to the 'right' thing for the corresponding version. Also open to discuss this in the Zoom meeting or so. Best, JRR (Juergen Reuter)

[gaede]

Hi Juergen, sorry for the late reply. This is not entirely trivial (as usual I guess;-)). It turns out that the event weight should be a double, yet it is not stored as such in the event header but as an extra float parameter. I honestly don't remember why we did it that way ~14 years ago... So there are indeed several solutions:

• we do store the event weight as true double in the event header

  • needs some minor coding and a new release
  • you could then use this, however this would probably be not what we/you want as then the event weight is 'abused' and cannot be used as that anymore
  • we might do this anyways to be consistent with the API and what is stored on disk

• we could add proper double parameters to the LCParameters class

  • a bit more coding would be needed for that, as well as a new release
  • we would not simply replace float parameters with double but rather let the user choose what is needed...
  • you could than add any set of MEs, event weights, etc with a proper naming of parameters

• you could store the needed ME as string parameter with scientific notation and the needed precision

  • no coding or release in LCIO needed
  • not super elegant but would be available right now
  • you wouyld have to do the string-to-double and reverse transformation yourself

Let me know what you prefer. Cheers, Frank.

[Romendakil]

Hi Frank, no worries, the most important thing was to get a possibility for Jakob's rescan working, for which we simply had to ignore existing entries and always recalculate. We are also open to your preferences, we will have our next meeting Tuesday, June 29. If you have time you could quickly join for half an hour to discuss this, otherwise we discuss this amongst us, and come back to you. Whatever you prefer. Cheers, JRR

[Romendakil]

Hi Frank, also sorry from my side for coming back so late on this. We discussed this in our WHIZARD meeting, clearly option 3 works as a hacky workaround with all existing versions of LCIO (and WHIZARD), but is considered as a hack. Option 1, adding the squared matrix element in the header solves the problem for the case of a single squared matrix element, but not with alternative setups in a parameter scan, so we definitely prefer your option 2: to add a proper double parameter container. Clearly we then have to special case this in our LCIO interface, but this is easily done using your LCIO_VERSION_GE preprocessor magic. How would you envision the user to set this, simply via the type: evt->parameters().setValue ("", value) just uses either float or double, depending on whether the user provides value as float or double?