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

Add positivity observables #124

Closed
cschwan opened this issue Feb 9, 2022 · 11 comments · Fixed by #132
Closed

Add positivity observables #124

cschwan opened this issue Feb 9, 2022 · 11 comments · Fixed by #132
Assignees

Comments

@cschwan
Copy link
Contributor

cschwan commented Feb 9, 2022

Do we want a generator in this repository for the positivity observables? This would be basically https://github.com/N3PDF/pineappl/blob/master/examples/python/positivity.py.

@felixhekhorn
Copy link
Contributor

Maybe this is the more suitable place then pineappl examples, even more if this will become a proper dataset (in the NNPDF sense)

@cschwan
Copy link
Contributor Author

cschwan commented Feb 9, 2022

That was my train of thought also. I'd volunteer to take care of it, if you're busy with other projects.

@alecandido
Copy link
Member

We're slowly completing most of the chores, but still I would not do it before ~10 days. If you can start, do it :)

Were you thinking something about a new backend (like yadism, mg5, and conversions the moment we'll get there), a new subcommand, or just moving the script?

@cschwan
Copy link
Contributor Author

cschwan commented Feb 10, 2022

We're slowly completing most of the chores, but still I would not do it before ~10 days. If you can start, do it :)

Were you thinking something about a new backend (like yadism, mg5, and conversions the moment we'll get there), a new subcommand, or just moving the script?

I was thinking about making it a new backend, which isn't too complicated given that we already have that script.

@alecandido
Copy link
Member

Indeed, I just wanted to understand.

At the end, a backend is not doing so much:

  • __init__: used to load backend specific runcards, or define variables, if needed
  • run: used to compute the actual numbers and dump in a backend specific format (but here might be even skipped) ❌
  • generate_pineappl: here goes the script ✔️
  • results: used to display the comparison (I guess it can be left empty in the first shot) ❌
  • collect_versions: not needed, this backend would be fully integrated in the runner ❌

@cschwan
Copy link
Contributor Author

cschwan commented Feb 10, 2022

OK, thanks for your pointers, let me try to implement it!

@felixhekhorn
Copy link
Contributor

* `collect_versions`: not needed, this backend would be fully integrated in the runner x

then it should be the runner version

@alecandido
Copy link
Member

runner version is included always by default:
https://github.com/NNPDF/runcards/blob/500e06c14cf2b42c2897fd6360fc0df347af6516/runcardsrunner/external/interface.py#L110-L116

(even though maybe we can even drop pygit2 at some point, and try to use the poetry-dynamic-versioning provided one, they should coincide)

@felixhekhorn
Copy link
Contributor

yes, I meant just not to leave it empty or something, but put the version twice (such that one can guess the generator, i.e. if they are the same the generator is built-in)

@alecandido
Copy link
Member

No, why twice? It is redundant, and runner is runner, so leave it empty.

Consider that there is no standard field for external, yadism add a yadism_version, and mg5 add an mg5_version. Here there is nothing but the runner, so leave it empty.

@alecandido
Copy link
Member

alecandido commented Feb 10, 2022

If you want to log the generator used let's add a separate field, and make it explicit (even though it might already be logged somewhere, but I'm not sure).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants