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

New node type for systematic variation #4

Open
IzaakWN opened this issue Jan 19, 2021 · 2 comments
Open

New node type for systematic variation #4

IzaakWN opened this issue Jan 19, 2021 · 2 comments
Labels
enhancement New feature or request schema Issues related to the schema definition

Comments

@IzaakWN
Copy link
Contributor

IzaakWN commented Jan 19, 2021

Right now a central/up/down variation might be defined as

{
  'nodetype': "category",
  #'input': "syst",
  'keys': ["nom", "up", "down"],
  'content': [ 1.0, 1.1, 0.9, ],
}

but since this is a frequently used scheme, one could predefine a node type / pydantic model that already generates the keys. One could create different node subtypes depending if the uncertainty is symmetric, asymmetric, or has many variations with different keys.

An uncertainty might be stored with which the reader tool computes the up and down variation, e.g.

{
  'nodetype': "symerr",
  #'input': "syst",
  'content': [ 1.0, 0.1, ],
}

yield 1.0+0.1=1.1 and 1.0-0.1=0.9. The "nom", "up", "down" keys of the "sys" variable are implicit in this node type object.

I don't know if this would improve performance, but it might enforce uniform style, such that the analyzers have to use only one consistent flag/key across all POG SFs ('up', 'down', ...). The default output could be the central one, if no variation key/flag was given.

@nsmith-
Copy link
Collaborator

nsmith- commented Jan 26, 2021

I think introducing a special node type to handle systematics is worthwhile, since it is common to have a mixture of symmetric and asymmetric uncertainties, and some might be better parameterized as shifts from nominal. Probably a type similar to Category. We could have nominal as the default, though its not obvious if requests for a nonexistent systematic should return nominal or throw an error.

@pieterdavid
Copy link
Contributor

Would the systematic category axis (preferably) be the outermost or innermost? In the (much more limited) JSON format we've used in our group for a while, there's only one uncertainty (nominal value, up and down - for multiple uncertainties we'd need to multiply with another one with unit nominal values); that's very readable, but with a high amount of redundancy in the JSON.
Allowing it to be the outermost would make it easier to add systematic variations that are not specified per-bin, but as an overall scaling of the nominal, e.g. something like this (probably too simplistic because I haven't studied the format in detail yet, but essentially a category axis with some extra features):

{
  "nodetype": "systematic",
  #'input': "syst",
  "keys": ["nominal", "stat_up", "stat_down", "syst1_up", "syst1_down"],
  "content": {
    "nominal": {...},
    "stat_up" : {...},
    "stat_down" : {...},
    "syst1_up" : {
      "nodetype": "variation",
      "from" : "nominal",
      "scale" : 1.1
      },
    "syst1_down" : {
      "nodetype": "variation",
      "from" : "nominal",
      "scale" : 0.9
      }
    }
  }
}

@nsmith- nsmith- added the enhancement New feature or request label Feb 16, 2021
@nsmith- nsmith- added the schema Issues related to the schema definition label Mar 18, 2021
lwezenbe referenced this issue in lwezenbe/correctionlib Apr 7, 2021
…s/actions-gh-pages-v3.8.0

Bump peaceiris/actions-gh-pages from v3 to v3.8.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request schema Issues related to the schema definition
Development

No branches or pull requests

3 participants