Yellow Report Physics Common

From eicug
Jump to: navigation, search

Greetings!

This page has been created to manage content of common interest to all subgroups in the Physics sector of the Yellow Report effort.

Detector requirements

NEW (Sept 3, 2020) The PWG has compiled the detector requirements in the following spreadsheet:

- Detector matrix requirements

  • The first tab in the spreadsheet shows the combined requirements for all physics working groups in the format of the detector matrix/table. Additional requirements are described at the bottom of the table.
  • Cells colored green indicate that the current (as of 9/3/2020) values of the interactive detector matrix are suitable for all working groups.
  • Cells colored red indicate that at least one working group has found the current values insufficient. The cell shows the most stringent constraint from all working groups.
  • Cells left white indicate that at least one working group did not check the current value, but all other groups found it sufficient.
  • Additional tabs in the spreadsheet show the requirements of each individual working group.

Studies that drove the requirements summarized in this spreadsheet are documented in the wikipages of the different working groups:

YR outline

Latest version from the PWG (9/2/2020)

PWG meetings (indico)

How to communicate your detector requirements to the DWG:


Once you think you have some concrete detector requirements out of your work, please follow the following procedure in order to let the DWG (and everybody else) know about them:

1) Discuss your results within your WG

2) Document the work in your WG wiki area

3) Your WG conveners will then contact the DWG conveners by email describing the results and pointing to the corresponding documentation in the wiki

4) The DWG conveners update the interactive detector matrix

Charge for the Pavia meeting


We had previously communicated the following:


Straw-man plan of attack:

a.- Review previous existing work related to your subgroup.

b.- Converge on a set of important and representative measurements for your subgroup.

c.- Break-down physics deliverables into “physics objects” (PO) [electron, hadron (ID/noID), muon, jet]; map out kinematics for each PO.

d.- Cross-check PO maps across physics subgroups to determine the most challenging constraints in terms of detector design; resolve overlaps [decide who runs what].

e.- Focus on fast simulations for the most demanding measurements first; determine the optimal/acceptable detector performance; confirm/check resulting impact on the rest of the measurements.


Progress on items a) and b) has been presented at the Temple meeting. For the Pavia meeting we should proceed to item c) in order to present initial concrete constraints on the detector systems. In this regard we would also like to encourage you to communicate already completed studies which have revealed specific detector requirements to the DWG so that they may update the numbers in their interactive detector matrix. This is not a request for large event samples but for specific numbers, such as resolution requirements, in the detector matrix.

To forward your analysis to the DWG, please summarize it in 1-2 slides and send those by email to the conveners of the appropriate DWG, with Cc to eicug-yr-detector-conveners@eicug.org and eicug-yr-physics-conveners@eicug.org . Feel free to use the EICUG YR wiki to share your work: https://wiki.bnl.gov/eicug/index.php/Main_Page

The conveners of the DWG and PWG have agreed on the following set of benchmark parameters for the YR activity. (The table below contains additional ion species compared to what we had communicated to you previously.) We would like to emphasize that we do not request you to consider all the cases/energies but to select from that list the combination that best suits your physics topic and leads to the most stringent detector requirements.

Based on the current BNL design, we suggest, as a starting point for our physics simulations, to study one or several of the following beam energy combinations:

p-e 275 on 18 GeV 100 on 10 GeV 100 on 5 GeV 41 on 5 GeV
d/3He/4He-e 110 on 18 GeV 110 on 10 GeV
41 on 5 GeV
C/40Ca/Cu-e 110 on 18 GeV 110 on 10 GeV
41 on 5 GeV
Au-e 110 on 18 GeV 110 on 10 GeV
41 on 5 GeV


(For nuclei the energy refers to the energy per nucleon.)

Please assume integrated luminosities of 10 fb-1 and 100 fb-1. A polarization of 70% may be assumed for electrons and light ions as a baseline.

Charge for Temple meeting


Here we give some further information about the charge for the Yellow Report physics subgroups in order to optimize their output within the time constraints of the exercise. Please let us know if you have specific suggestions to improve this plan.

A large effort has taken place over the past decade to define the physics case for the EIC and to develop detector concepts required to deliver these measurements. Building on this groundwork, the goal of the extensive Yellow Report initiative is to review the theoretical progress made since the EIC White Paper and NAS Report, and optimize the detector concepts through a broad range of simulation studies.

Capitalizing fully on the EIC physics potential will impose many challenges on the detector design, particularly in the forward region. With the site selection in place, re-evaluation of the major kinematic observables with specific beam energies/species combinations, while considering distinct physics processes (as established by our subgroups structure), is a first natural step to establish the baseline requirements for detector R&D (as well as IR design).

Several key measurements would require high precision detection of all particles in the final state. Others may put high demands on acceptance or experimental resolution. We see another main goal for the Yellow Report exercise to go beyond the Monte Carlo studies that provide only particle kinematics and some representative examples of these reactions. We should now establish detailed constraints on the required detector performance. It is also important to understand the potential differences in the optimal detector configuration from different physics goals / physics processes, therefore comparison of detector requirements between the different subgroups (e.g. constraints on design for exclusive vs. semi-inclusive reactions). Finally, developing approaches for ensuring the exclusivity of the reactions can play an important role in progressing towards a CDR.


Straw-man plan of attack:

a.- Review previous existing work related to your subgroup.

b.- Converge on a set of important and representative measurements for your subgroup.

c.- Break-down physics deliverables into “physics objects” (PO) [electron, hadron (ID/noID), muon, jet]; map out kinematics for each PO.

d.- Cross-check PO maps across physics subgroups to determine the most challenging constraints in terms of detector design; resolve overlaps [decide who runs what].

e.- Focus on fast simulations for the most demanding measurements first; determine the optimal/acceptable detector performance; confirm/check resulting impact on the rest of the measurements.


We do not expect the physics subgroups to run full (detector) simulations. Detector requirements could probably be established by fast simulation only. The Detector Working Group would use the requirements defined by the physics subgroups to come up with specific detector technology choices/recommendations, after full detector simulations of different experimental configurations. Notice that the Detector/R&D Handbook provides some rough numbers that can serve as start values for further refinement. We encourage you to use as much as possible the tools provided by the EICUG Software Group (http://www.eicug.org/web/content/eic-software).

Handbook Detector Released in eic-smear 1.0.4 and Simple Instructions for Anywhere

As previewed and showcased in the recent fast simulation tutorial https://indico.bnl.gov/event/8243/, the newly released version 1.0.4 of eic-smear now contains an implementation of the handbook detector from http://www.eicug.org/web/sites/default/files/EIC_HANDBOOK_v1.2.pdf.

We recommend all users use this detector as starting point for their studies. In the future, more detailed and realistic reference parameterization will become available, but until then it serves as a documented common ground across the YR effort.

The simplest way to use it with a wide range of HERA generators is to take advantage of cvmfs and singularity to be placed directly into the environment that's running natively at BNL. This combination is widely available at national labs, CERN, and many other facilities, as long as CVMFS_REPOSITORIES contains eic.opensciencegrid.org. But simple instructions for any system can be found at the bottom of this email.

In all cases, a single line


% singularity shell --writable -B /cvmfs:/cvmfs \
/cvmfs/eic.opensciencegrid.org/singularity/rhic_sl7_ext


and one setup script:

% source /cvmfs/eic.opensciencegrid.org/x8664_sl7/MCEG/releases/etc/eic_bash.sh

or

% source /cvmfs/eic.opensciencegrid.org/x8664_sl7/MCEG/releases/etc/eic_cshrc.csh



will place you in the same environment where the libraries are installed natively. All libraries and executables are in your $PATH and $LD_LIBRARY_PATH, and the full packages can be found under ${EICDIRECTORY}.

That means you can directly copy and paste instructions from https://eic.github.io/software/eicsmear.html and the README's of MCEG packages at https://gitlab.com/eic/mceg


For example


% cp -r $EICDIRECTORY/PACKAGES/eic-smear/tests .

% cp $EICDIRECTORY/PACKAGES/eic-smear/scripts/smearHandBook.cxx .

% pythiaeRHIC < tests/input.data.ep_hiQ2.20x250.small.eicwill create pythia e+P output.% root -l


root[] gSystem->Load("libeicsmear");

root[] BuildTree ("tests/ep_hiQ2.20x250.small.txt");

root[] .L smearHandBook.cxx

root[] SmearTree(BuildHandBookDetector(), "ep_hiQ2.20x250.small.root")


will smear the result. The documentation in


https://eic.github.io/software/eicsmear.html


contains instructions on how to work with the result, and files in $EICDIRECTORY/PACKAGES/eic-smear/tests provide practical examples.

Also in the $EICDIRECTORY/PACKAGES and $EICDIRECTORY/bin are the generators BeAGLE, Milou, DJANGOH, RAPGAP, and PEPSI.


Of course, eic-smear and many MCEGs are also part of the escalate package:


https://eic.gitlab.io/documents/quickstart/


Instructions and examples on how to use it in conjunction with PYTHIA8, how to write your own eJana plugins, how to perform analyses within JupyterLab or on the command line and much more are part of the included tutorial, and the recording of the recent tutorial is (soon) in our YouTube channel at https://www.youtube.com/channel/UCXc9WfDKdlLXoZMGrotkf7w


As always, we appreciate any feedback, comments, or questions on mailing lists or in our slack #software-support channel!


Best,


Kolja for the EIC Software Group


Note: Future updates will allow more fine-grained control over the eic-smear version, but at present only 1.0.4 is installed and is the only one that should be used.


Details on the handbook detector:

- In the absence of angular resolution specifications, all particles are smeared by 1 mrad in phi and theta.

- Calorimeter parameters were given without constant term. Since this may play an important role for some measurements, we used input from the calorimetry group to refine specifications to:

EMCal:

- back 2% \oplus 1%

- midback 7% \oplus 1%

- forward 12% \oplus 2%


HCAL:

- back and forward 45% \oplus 6% (Pb/Sc)

- barrel 85% \oplus 7% (~CMS)


For more information on singularity, see Wouter's excellent introduction here:

https://eic.github.io/software/singularity.html

-- Singularity+cvmfs at JLAB


on your computer


ssh login.jlab.org- on login.jlab.orgssh ifarm1802


- ifarm1802.jlab.org>


module load /apps/modulefiles/singularity/3.4.0


-- Singularity+cvmfs anywhere:


You can also use the software on any computer that can run VirtualBox

(i.e., Windows, OSX, Linux, even Solaris)

https://www.virtualbox.org/


A ready-made image can be downloaded at

https://www.phenix.bnl.gov/WWW/publish/phnxbld/sPHENIX/Singularity/Fun4AllSingularityDistribution.ova


Some more instructions at

https://github.com/eic/Singularity/blob/master/VirtualBox.md


Note: All that's needed is cvmfs, singularity, and eic.opensciencegrid.org in CVMFS_REPOSITORIES.


The image just has this already done for you.


At BNL


No need for containers, just add


setenv EIC_LEVEL pro source /cvmfs/eic.opensciencegrid.org/x8664_sl7/MCEG/releases/etc/eic_cshrc.csh


to your ~/.cshrc

(or, exuse the lslight version mismatch,


setenv EIC_LEVEL dev


source source /afs/rhic.bnl.gov/eic/restructured/etc/eic_cshrc.csh)<\verbatim>

Standard histogram to display kinematic coverage

We suggest to use the following histogram to display the kinematic coverage of each of the particles of your channels. This will help compare/combine plots from different processes and WGs.

This ROOT script will set the style and drawing options for a 2-D histogram filled with Theta:Momentum (in deg and GeV). Please use it and share the output ROOT file (which contains the histogram and the canvas).

  • Please add several histograms/plots to the same ROOT file corresponding to the different particles of the same process. Please clearly label each histogram.
  • Create a different ROOT file for each channel.

Output example:

Sample output showing the kinematic coverage


A python script is also available to make a nicer display like the one below:

Output of python script

Kinematic coverage files

This section summarizes the kinematics studies of the XXX working group. We have simulated the following processes:

My favorite physics process 1

  • Species and energies used: 20 GeV electrons on 250 GeV protons
  • Generator used: pythiaeRHIC (/cvmfs/eic.opensciencegrid.org/x8664_sl7/MCEG/releases/env/pro/bin/pythiaeRHIC)
  • Generator input file: input.data.ep_hiQ2.20x250.small
  • ROOT file containing a small tree of simulated data (only the variables required for the plot): ep_hiQ2.20x250.small.root

Electron coverage

Kinematic coverage for process 1

Plot description

This plot illustrates the following requirements for electron detection:

  • Comment 1
  • Comment 2

Proton coverage

Kinematic coverage for process 1

Plot description

This plot illustrates the following requirements for proton detection:

  • Comment 1
  • Comment 2