Correlated shapesys across channels

[alexander-held]

Summary

It is possible in 0.7.0rc1 to correlate shapesys modifiers across channels, and these modifiers behave in strange ways. 0.6.3 raised an error instead.

OS / Environment

n/a

Steps to Reproduce

import pyhf

spec = {
    "channels": [
        {
            "name": "SR",
            "samples": [
                {
                    "data": [24.0, 25.0],
                    "modifiers": [
                        {"data": [0.1, 0.2], "name": "par", "type": "shapesys"},
                        {"data": None, "name": "mu", "type": "normfactor"},
                    ],
                    "name": "Signal",
                }
            ],
        },
        {
            "name": "CR",
            "samples": [
                {
                    "data": [10.0],
                    "modifiers": [{"data": [0.1], "name": "par", "type": "shapesys"}],
                    "name": "Background",
                }
            ],
        },
    ],
    "measurements": [
        {"config": {"parameters": [], "poi": "mu"}, "name": "minimal_example"}
    ],
    "observations": [
        {"data": [24.0, 24.0], "name": "SR"},
        {"data": [10.0], "name": "CR"},
    ],
    "version": "1.0.0",
}

model = pyhf.Workspace(spec).model()
print(model.config.par_names())  # model contains mu and par[0]
print(model.expected_actualdata([1.0, 1.1]))  # modifier scales both SR bins

File Upload (optional)

No response

Expected Results

Expected behavior is that of v0.6.3

ValueError: Trying to add unshared-paramset but other paramsets exist with the same name.

as this setup does not make a lot of sense.

Actual Results

['mu', 'par[0]']
[10.  26.4 27.5]

The two bins in the SR get scaled by a parameter that looks like it should instead scale the first bin of both channels.

pyhf Version

0.7.0rc1

Code of Conduct

• [X] I agree to follow the Code of Conduct

[kratsg]

This is a regression introduced in #1625. https://github.com/scikit-hep/pyhf/pull/1625/files#diff-7d54bb3436a206408115628e40554cb9a17a488979fcc3cce12478655fc819c8L50-L67

Basically, we've lost the is_shared functionality check and we need to add it back and add tests for it.

[matthewfeickert]

Thanks for raising this @kratsg and @alexander-held. We'll have to be sure to address this before v0.7.0.