Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing constraint terms for nuisance parameters #820

Open
alexander-held opened this issue Apr 14, 2020 · 2 comments
Open

Changing constraint terms for nuisance parameters #820

alexander-held opened this issue Apr 14, 2020 · 2 comments
Labels
feat/enhancement New feature or request follow up schema and spec JSON schema

Comments

@alexander-held
Copy link
Member

Question

It can be useful to test the effect of uniform constraint terms when debugging fits. What is the pyhf way to do this? When converting a workspace from xml (with pyhf 0.4.1) with this measurement

<Measurement Name="freeFloating" Lumi="1" LumiRelErr="0.1" ExportOnly="True"  >
  <POI>NF_ttH</POI>
  <ParamSetting Const="True">Lumi</ParamSetting>
  <ConstraintTerm Type="Uniform" RelativeUncertainty="1">ttb_Rad</ConstraintTerm>
</Measurement>

the ConstraintTerm is not picked up, even though it should act on the systematics with name ttb_Rad. I am not sure whether this is within or beyond HistFactory scope.

Relevant Issues and Pull Requests

none that I am aware of

@kratsg
Copy link
Contributor

kratsg commented Apr 14, 2020

We don't support both (a) uniform constraint terms; (b) having configurable constraint types.

It's not technically impossible to implement it in pyhf, but I need to think about the use-case. In this example, are you constraining the parameter ttb_Rad to only be [-1,1] when it's normally an unconstrained normalization factor? How does this differ from changing the bounds on that parameter in this case?

@kratsg kratsg added the question Further information is requested label Apr 14, 2020
@alexander-held
Copy link
Member Author

The parameter ttb_Rad in this example controls a HistoSys and OverallSys term, and would usually come with a Gaussian constraint term. It is not a NormFactor. I am looking for a way to remove that constraint term, and one way of doing this in ROOT is as shown in that snippet above (there might be other ways to achieve the same).

@kratsg kratsg added feat/enhancement New feature or request follow up schema and spec JSON schema and removed question Further information is requested labels Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat/enhancement New feature or request follow up schema and spec JSON schema
Projects
Status: To do
Development

No branches or pull requests

2 participants