Custom Names for Luminosity Systematics

[dbuchin]

Dear pyhf Experts,

we're currently working on a statistical framework based on cabinetry, using pyhf workspaces. We have just implemented the luminosity systematics (i.e. adding a systematic of type "lumi" to every sample that is not normalised anyway and adding a parameter named "lumi" to the Measurement.
This works as expected, however, we are planning to combine a Run2 and Run3 measurement, i.e. two workspaces/measurements with different luminosities. As it's not allowed to name the luminosity systematic any different, we are worried this might lead to the two luminosities being fully correlated in the combination.
Do you know if this will turn out to be a problem in the combination and if yes, how to solve it (make it uncorrelated)?

Thanks a lot,
Daniel

Just for reference, initially, I tried to name the luminosity differently (e.g. "Luminosity_run2") in the workspace, but the pyhf schema (I think the name is const "lumi" there) didn't let me when I then tried to create a model out of it:

{'data': None, 'name': 'Luminosity_run2', 'type': 'lumi'} is not valid under any of the given schemas.
	Path: channels[0].samples[2].modifiers[75]
	Instance: {'data': None, 'name': 'Luminosity_run2', 'type': 'lumi'} Schema: workspace.json
$Traceback (most recent call last):
  File "/jupyter/lib64/python3.8/site-packages/pyhf/schema/validator.py", line 97, in validate
    return validator.validate(spec)
  File "/jupyter/lib64/python3.8/site-packages/jsonschema/validators.py", line 430, in validate
    raise error
jsonschema.exceptions.ValidationError: {'data': None, 'name': 'Luminosity_run2', 'type': 'lumi'} is not valid under any of the given schemas

Failed validating 'anyOf' in schema['properties']['channels']['items']['properties']['samples']['items']['properties']['modifiers']['items']:
    {'anyOf': [{'$ref': '#/definitions/modifier/histosys'},
               {'$ref': '#/definitions/modifier/lumi'},
               {'$ref': '#/definitions/modifier/normfactor'},
               {'$ref': '#/definitions/modifier/normsys'},
               {'$ref': '#/definitions/modifier/shapefactor'},
               {'$ref': '#/definitions/modifier/shapesys'},
               {'$ref': '#/definitions/modifier/staterror'}]}

On instance['channels'][0]['samples'][2]['modifiers'][75]:
    {'data': None, 'name': 'Luminosity_run2', 'type': 'lumi'}

[alexander-held]

Hi @dbuchin, this is an inherent limitation in the way the built-in luminosity modifier in HistFactory works, for cases like you describe it is not suitable. I recommend not using this modifier at all and instead using normsys modifiers instead. Here's an example for cabinetry. You get the same type of constraint term (Gaussian) and the full flexibility of naming and correlating in the way you want.

The difference is that the built-in lumi has a few other convenience features allowing you to normalize your histograms in different ways. I think this is very rarely used in practice, at least in what I have encountered. There are also some potential issues related to this, see #1516 for details on that.

[dbuchin]

Hi @alexander-held , I see, that's good to know, thanks! We actually implemented it like that at first, but then tried out using the dedicated lumi type. Then we would revert back to that option.

[andrewfowlie]

I guess this somewhat addresses #2547 i.e., it is intended that all luminosity modifiers are named lumi/that there is a single luminosity modifier?

[alexander-held]

I believe so, yes. In the HistFactory xml serialization the name of this modifier cannot be specified so I think pyhf made the specific choice of "lumi" for a name. It is constant and cannot be changed to match the behavior of the ROOT implementation.