riga
commented
6 months ago Hi @mafrahm,
yeah, this is actually a more general problem I think. In the current version of "order", processes can only have a single cross section per ecm, but this is generally not sufficient - as in your case.
In the variant of "order" that is going to replace the current one, processes can contain multiple values per ecm, mapped to descriptive keys such as "nnlo", "nlo_k", "recommended", etc. This should solve the issue in a generic way.
That being said, for the current version we use, we can think of a solution that "just does the job", but of course, without being too cumbersome ;) So I think storing the k-factor as aux information is ok. However, I would not remove it from the cross section itself. Instead one could divide the cross section again by the k-factor if needed. In this sense, I would consider things like "our vector boson pt reweighting also applies these k-factors" a special case that would require having the special treatment.
Does this make sense?
nprouvost
There are some processes where we already apply k-factors to the cross sections (e.g. [1]). However, the vector boson pt reweighting also applies these k-factors. It might therefore be a good idea to
1.) store the k-factor information as part of the process (e.g. as an auxiliary), such that a user can decide for themselves whether to apply them or not. 2.) be consistent with what is stored as cross section (probably always the cross section with best precision)
[1] https://github.com/uhh-cms/cmsdb/blob/cd1ffdac057540e76d47903db1c59a43d8554a8d/cmsdb/processes/ewk.py#L229