A proposal for MCnet and anybody interested.

Problem

MC setups have diversified and become more complex with the increased interfacing possibilities between different softwares. This has made them much more versatile and powerful, but referencing the contributions correctly has become trickier and is often done poorly in plots, talks, posters, and sometimes even papers.

At the same time, reproducing published results is often difficult, because the exact setup used is rarely (never?) published.

Proposed solution

Both referencing and reproducibility can be improved by creating a website where users store the full setup related to a particular publication/plot/curve/slide: references, version numbers, config files. The website provides a short, human-readable identifier, such as mcref:1611.12345, and a permalink. That number or link is added to plots, slides, papers, etc.

Obviously papers and similar publications should still include full references in their bibliography as they currently do.

The exact usage recommendations can be developed by MCnet in the future and communicated to theory colleagues and the experimental collaborations.

Disadvantages

  • Work (fair amount for the developers; very little for users if we do ours well)
  • Indirection, if users only write the mcref:xxxx.xxxxx on a plot — but this could be steered via clear guidelines

Advantages

  • Concise, exact, complete referencing
  • Version numbers or revisions of generators in addition to release notes and papers
  • Greater reproducibility — much greater if full config files can be included
  • Raise awareness of what should be cited — MC generators could directly provide an uploadable/parsable setup documentation file, like the current BibTeX files that some provide
  • Granular reference counting can be implemented, including of backend work that perhaps doesn’t currently get enough credit
  • Could implement meta-analysis, e.g. smart diff between setups
  • Provides input to guide generator development and documentation: which features the MC authors think are useful vs. which knobs the experimentalists play with / know about
  • High degree of automation possible if we write a good command-line interface or API