Suggestion: expose model library on command line? 'pyhf model --template'

[lukasheinrich]

Description

We keep a small (ok, it's one entry) library of example models in pyhf.simplemodels, which makes it easy to get started (see the nice example we have in README)

It might be interesting to expose this on the command line e.g. a pyhf model command that dumps a fully specified pyhf spec from a simpler input JSON (which we don't really validate, it's not another spec, but just a short-cut, we should keep this dead-simple key-value JSON without any nesting)

I'm not sure how I feel about this, so curious about inputs

pyhf model --template hepdata_like --signal 5.0 --bkg 50. --bkg_uncrt 7. | pyhf cls

^ which I think would be a great line to have in the README

cat << EOF| pyhf model --template hepdata_like |pyhf cls
{ 
"signal": 5.,
"bkg": 50.,
"bkg_uncrt": 7. 
}
EOF

[matthewfeickert]

I was thinking about something similar (though not as well formed like this) today while writing some slides. So I would be in favor of it. :+1:

[lukasheinrich]

@kratsg ?

[kratsg]

Only if all templates can take the same set of inputs -- otherwise, this will get very confusing fast.

One way I see this being very useful, is to do the teaching exercise of expecting 0 events, seeing 3 events, calculating the CLs, and then adding in systematics (uncertainties) to see how the same CLs changes.

[lukasheinrich]

My thinking was that they'll should all take the same data format (JSON, I guess), but not necessarily the same contents. The implementation should always be just a single function like this one

https://github.com/diana-hep/pyhf/blob/master/pyhf/simplemodels.py#L3

which would document what the expected input is (could dump that help string via e.g. pyhf model --template <name> --help)

if this grows beyond a small handful of models (like the counting experiments you mention) it should probably be factored out (similar discussion as w/ visualization etc) into a separate package