Difference: HCALOP (1 vs. 8)

kakwok@xaas-hcal ~ > sudo systemctl list-dependencies hcal.target hcal.target ● ├─hcal.addon.target ● │ └─hcal.addon@kvm-s3562-1-ip151-94.target ● │ ├─hcal.spotlightocci@kvm-s3562-1-ip151-94.service ● │ └─hcal.tstore@kvm-s3562-1-ip151-94.service ● └─hcal.service.target ● └─hcal.service@kvm-s3562-1-ip151-94.target ● ├─hcal.b2in-eventing@kvm-s3562-1-ip151-94.service ● ├─hcal.bridge2g-sentinel@kvm-s3562-1-ip151-94.service ● ├─hcal.bridge2g-xmas@kvm-s3562-1-ip151-94.service ● ├─hcal.directory-service@kvm-s3562-1-ip151-94.service ● ├─hcal.heartbeat@kvm-s3562-1-ip151-94.service ● ├─hcal.heartbeatds@kvm-s3562-1-ip151-94.service ● ├─hcal.sensords@kvm-s3562-1-ip151-94.service ● ├─hcal.sentinelds@kvm-s3562-1-ip151-94.service ● ├─hcal.timeline@kvm-s3562-1-ip151-94.service ● ├─hcal.tracerd@kvm-s3562-1-ip151-94.service ● ├─hcal.xmas-admin@kvm-s3562-1-ip151-94.service ● └─hcal.xmas-slash2g@kvm-s3562-1-ip151-94.service

3:00 voila Dan Arcaro 3:02 PM uhh 3:03 still not sure what to restart martin kwok 3:04 PM last one: it’s slash2g on it: hcal.xmas-slash2g@kvm-s3562-1-ip151-94.service

System Manager

This long living application writes IP addresses to the uTCA cards based upon their crate and slot. It should detect movement or power cycles and be able to write the new IP address. This does not work properly for the AMC13 yet and instead the application needs to be restarted if an AMC13 is exchanged or moved.

904:

P5: (Use on hcalutca01)

$ sudo systemctl restart sysmgr.service

$ ~hcalsw/bin/restart_sysmgr.sh
$ sudo -u hcalpro ~hcalpro/scripts/Service_fix.sh
$ sudo -u hcalpro sysmgr ~hcalsw/config_files/Sysmgr/sysmgrHCAL.conf

AMC13

AMC13Tool2.exe -c ~hcalsw/uTCA.connections.pro.xml -i hcal.crate$1.amc13 ${@:2}

This is the p5 script. The 904 is almost identical but the location of the connection file is hcalsw/HcalCfg/uTCA/connections.xml. Just use this to connect:

$ ~hcalsw/bin/AMC13Tool2.sh crate#

6/24/16 To add the AMC13Tool2.sh script to hcalsw used: $ sudo -u hcalsw then_a_command Example to edit the shell script: $ sudo -u hcalsw emacs AMC13Tool2.sh

Elog + Shiftlift

https://cmsonline.cern.ch/webcenter/portal/cmsonline/pages_common?wc.contentSource=

https://cmsonline.cern.ch/webcenter/portal/cmsonline/pages_common/elog

Elog: Common -> Elog -> Subsystems -> Hcal -> Hcal, Hcal904, etc

Shiftlist: Common -> Shiftlist

Random

Killing Stale Xdaq Processes When a run is destroyed there can be processes that were not destroyed. These will interfere with the next run and cause errors on initialize.

Processes NOT to kill: root 35246 18.7 7.3 6499672 2399100 ? Ssl Apr20 11439:33 /opt/xdaq/bin/xdaq.exe -h srv-s2f17-19-01.cms -p 9950 -u file.append:/var/log/hcal.xaad.log -e /opt/xdaq/share/hcal/profile/xaad.profile -z hcal

root 35247 8.2 0.2 4319652 91404 ? Ssl Apr20 5045:51 /opt/xdaq/bin/xdaq.exe -h srv-s2f17-19-01.cms -p 9999 -u file.append:/var/log/hcal.jobcontrol.log -e /opt/xdaq/share/hcal/profile/jobcontrol.profile -z hcal

Example of stale xdaq process to kill: hcalpro 41955 9.1 0.2 4261576 93072 ? Sl 22:37 1:01 /opt/xdaq/bin/xdaq.exe -h hcalutca01.cms -p 15002 -s 294342 -u xml://cmsrc-hcal.cms:16010 -l INFO

Stale XDAQ example: hcalpro 13038 4.1 0.3 2588468 122480 ? Sl Sep15 71:14 /opt/xdaq/bin/xdaq.exe -h hcalutca01.cms -p 16789 -u xml://cmsrc-hcal.cms:16010 -l INFO

Do not kill things that are run under root like job control, controlhub, xaad, etc. Be careful with pkill and such that use the name xdaq since it will pick up those other ones as well.

~hcalsw/bin/dump_all.sh See if relevant card ispingable. If uHTR of AMC13 is not pingable: -Restart sysmgr: Using script on hcalutca01 machines: ~hcalsw/bin/restart_sysmgr.sh

Basically ~hcalsw/bin/ contains all the magical scripts to do most things.

Crate Locations and FEDS: http://cmsdoc.cern.ch/cms/HCAL/document/CountingHouse/Crates/Crate_interfaces_transition.htm

Dump: ~hcalsw/bin/dump_all.sh

ps aux (just to check what is there, if no stal xdaq it should be fine to just run: (sudo service xdaqd restart)

sudo service xdaqd stop pgrep xdaq (just to check what is there) pkill xdaq sudo service xdaqd start

THESE CHANGE QUITE OFTEN: Restart Services 904 I have begun working on service fix at 904. To run it, type:

sudo -u hcalpro ~hcalpro/scripts/Service_fix.sh

The currently functioning options are:

-tomcat -sysmgr

The possible functioning option is:

-ccmserver

Please use this and email/elog any issues or desired functionality

Restart System Manager p5 Here is the start system manager command. It should be used sparingly. In most cases (such as swapping uHTRs), the system manager will not need to be restarted.

sudo -u hcalpro sysmgr ~hcalsw/config_files/Sysmgr/sysmgrHCAL.conf

HCAL Operations

On Call Cheat Sheet

Setting up Tunnels

HCAL Connectivity

Setup Environment

Snippets

MCH Commands

telnet hcal-mch-20 (the hcal-mch-20 is like in HcalCfg/uTCA/connection.xml with hcal-card-crate-additionaloption)
>> show_fru
(M4 is on)
>> shutdown <fru_number>
(Probably do show_fru again to make sure the state goes to M1 of the particular card)
>> fru_start <fru_number>

Run Control Websites

http://cmsrc-hcal.cms:16000/rcms/gui/servlet/RunGroupChooserServlet

uHTR

Log Files

Data Analysis with CMS

Finding Data

here

The second option is by brute force looking through directory on eos (disk storage).

• eos can be entered into a terminal on an lxplus machine and an interactive session will start. Commands such as ls and cd can be used to navigate directories. There is a directory called data that has most of the relevant global runs. Enter quit to get out of the session.
• Another way is to use eos like this:

      $ eos ls eos/cms/store/data 

These file locations such as eos/cms/store/data/Run2015C/Cosmics/RAW/v1/000/253/982/00000/AAF77D5F-FF3F-E511-83B4-02163E0143BA.root are then entered into python files to be used by cmssw. More on this below.

Raw Data Analysis / Data Quality Monitoring

Old DQM

EricDIM

Unpacker

Unpacker

CMSSW Unpacker

CMSSW Unpacker

CMSSW Tricks / Notes

All of this is for lxplus machines except for a few things in the root section. To install a CMSSW version use $ cmsrel CMSSW_#_#_#. Change to the CMSSW_#_#_#/src direction and enter cmsenv to set the environment. To select a specific version number read the Data section. Since some of those tools below require the environment already set just use CMSSW_7_4_2 for the first version and get others when needed.

Analyzers

The best place to start with an Analyzer is the SWGuide. The section mkedanlzr will show how to create a skeleton analyzer to then edit. Once created there are three main files to edit. The first is the analyzerName.cc file which has all the analysis code. The next file is the BuildFile that links any outside code to the analyzer. The last is the python ConfFile_cfg.py script which the cmssw code reads to run your analyzer.

The CMSSW Unpacker as listed above is a good place to start looking at some source code examples. Another good example is the built in CMSSW analyzers that can be seen here. The amount of code there is quite hard to sort through so here is a fairly simple one under the data formats directory.

Root

Dependencies / Buildfiles

example

example

#include <cmsswtools/unpacker/interface/FedEvent.hh>

as if CMSSW_#_#_#/src is the home directory (or ~/). The same should be done with the source code for the user created libraries like can be seen in the previous example.

Another place to look is at the built in libraries source code or even other peoples libraries/analyzers. A good place I have gathered a lot of information from is here. The link has a huge list of both built in analyzer source code and user created libraries plus analyzers. The format used there has worked for current CMSSW version such as 7_4_2.

CMSSW Version

This section is for determining what CMSSW version to choose for a specific data file and see the contents of the file. The data files are all root files and can be found using the procedures above. The main tools are the Event Data Model (edm). Entering edm on lxplus and then pressing tab twice will give a list of all the different edm tools. The two ones used more are edmProvDump which provides the CMSSW version used the create the file. This version should be the version you are using to do any of the analysis. The other tool is edmDumpEventContent which gives a list of the type of data contained in the file. This is explained in more detail in the analyzer section.

Another option is to use a built in cmssw analyzer. An easy implementation of one is in this python script. There are two options for analyzers: EventContentAnalyzer and DumpFEDRawDataProduct(source code)**. The content analyzer will be a similar to edmDumpEventContent and the raw data product just prints the raw data in hex.

The edm tools should always work for global root files but may not work for the local ones. For the recent local runs any CMSSW_7_#_# should work fine since the edmProbDump does not work and cannot tell the exact version.

**The source code for DumpFEDRawDataProduct is a pretty simple one page analyzer because if only prints some data to screen so it is a very good reference. The site also provides pretty much all the source code for the analyzers. It may be quite complicated but very useful.

Analysis

Drell-Yan Process

Theory

Data

Papers

-- DanielArcaro - 21 Jun 2017