This page describes step-by-step the process to make a B2OC MC requests

Previous considerations

Guidelines exist for the size of requests which can be made without special PPG approval:

• For requests with no stripping-level filtering, a maximum of 20M events may be requested if the output is microDST, and 4M if it is regular DST
• For requests with stripping filtering no more than 100M events may be generated, and no more that 4M(10M) events kept in the output DST(microDST)

These figures apply per DecFile and Run (2011+2012 / 2015+2016+2017+2019). Larger requests are possible but the justification must be presented (normally by the convenors) to the PPG

Some of these constraints may be skipped by considering fast simulation options such as ReDecay

Unfiltered requests

---

To start a MC unfiltered request send a mail to the B2OC conveners and B2OC MC liaisons for approval, this mail should contain the following information:

• Brief motivation for your request
• Event number of the channels requested (corresponding to an approved DecFile merged in the https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles
• Number of events requested for each year/polarisation
• samples format (.mDST, .DST)
• Stripping version
• simulation version:
  • the general recommendation from the simulation team is to always use the newest simulation version, if you need samples from an old version this MUST be justified and will require the approval from the simulation conveners

• Generator and fast simulation options (Pythia 8, BcVegPy, ReDecay... )
• Priority (1-3) following the next scheme:
  • (1) We honestly need it ASAP - we are being held up without it.
  • (2) We need it ASAP but are not actually being held up by it.
  • (3) We want it soon but it is not that urgent.
  • Note that it is easier to justify higher priority for smaller samples
  • Priorities will be reassigned by conveners if necessary

• 10% finalization date: date at which the analyst needs roughly 10% of the MC to start performing some checks
• Full samples finalization date: date at which the analyst needs the complete sample for the analysis

• Please be realistic when considering these dates, taking into account that for most of the requests, it takes about 2 weeks to get everything sorted out, and about a month for the request to run
• If you want the samples to get finished as soon as possible please consider using fast simulation options (ReDecay)

Once you get the approval of your request from the B2OC conveners you can add this information to the request tables for each year. A part from the information included above you will need to include in the tables the following information

• Status: add "proposed" when adding the request to the tables, the MC liaisons will update this when the requests are submitted
• Dirac ID: to be filled by the MC liaisons to get track of the requests in Dirac

At this point the MC liaisons will be able to create the request in Dirac and submitted. They will ask you to double check the request one last before submitting it.

Filtered requests

---

To start a MC filtered request send a mail to the B2OC conveners and B2OC MC liaisons for approval, this mail should contain the following information:

• Same information than for an unfiltered request

• Events requested before/after filtering and the retention rate
  • you can obtain the retention rate by testing locally your filtering script on an unfiltered sample
• DaVinci version associated to the stripping version used (you can find it here
• CPU usage: can be found usually in the newest decay files, if it is not given there you can assume it is <1min
• Filtering script:
  • The filtering script must be given through a merge request into the B2OCConfig repository. the merge request must contain:
    • Filtering script (tested locally)
    • Updated release notes
  • You can use the template to write the filtering script
  • If you have any other problems to write the filtering script please contact with the MC liaisons
  • The filtering script should be tested locally on an unfiltered .DST before making the merge request if possible, you can find how to test it locally in the template

As for the unfiltered requests, once this is done and you get the approval from the conveners, you can write your request in the tables for each year. A part from the information included above you will need to include in the tables the following information

• Status: add "proposed" when adding the request to the tables, the MC liaisons will update this when the requests are submitted
• Dirac ID: to be filled by the MC liaisons to get track of the requests in Dirac, they will include the Jira task number for your request

• Also please specify that this is a filtered request in the tables

After this the MC liaisons will create a Jira task with all the information and will ask for you to revise it one last time. Finally the filtering liaisons will create and submit your request and include the Dirac ID in the Jira task.

Contact information

---

• B2OC conveners:
  • Mark Peter Whitehead (mark.peter.whitehead@cernNOSPAMPLEASE.ch )
  • Agnieszka Dziurda (agnieszka.dziurda@cernNOSPAMPLEASE.ch)

• B2OC MC liaisons:
  • Philipp Ibis (philipp.ibis@cernNOSPAMPLEASE.ch)
  • Arnau Brossa Gonzalo (arnau.brossa.gonzalo@cernNOSPAMPLEASE.ch)

Request tables

---

There is a specific TWiki page with the tables for the MC for each year:

• B2OC 2011 MC
• B2OC 2012 MC
• B2OC 2015 MC
• B2OC 2016 MC
• B2OC 2017 MC
• B2OC 2018 MC

Other information

---

• sim09 bugs
  • An overview of all known bugs in Sim09 can be found here: Sim09_bugs.pdf
  • All the changes included in all Sim09 versions can be found here: Sim09Differences

-- ArnauBrossaGonzalo - 2020-01-10