Time	Talk	Presenter
14:00	Follow-ups ( 00:20 ) 0 files	All
14:20	Overview of the current online security plan ( 00:10 ) 0 files	J. Lauret (BNL)
14:30	SSH Key management tool - Overview of functionalities ( 00:10 ) 0 files	W. Betts (BNL)
14:40	Progress on Run QA ( 00:10 ) 0 files	G. Van Buren (BNL)
14:50	AOB ( 00:10 ) 0 files	All (All)

Introduction

The purpose of this document is to describe step-by-step the setting up of embedding infrastructure on a remote site i.e. not at it's current home which is PDSF. It is based on the experience of setting up embedding at Birmingham's NP cluster (Bham). I will try to maintain a distinction between steps which are necessary in general and those which were specific to porting things to Bham. It should also be a useful guide for those wanting to run embedding at PDSF and needing to copy the relevant files into a suitable directory structure.

Pre-requisites

Before trying to set up embedding on a remote site you should have:

• a working local installation of the STAR library in which you are interested (or be satisified with your AFS-based library performance).
• a working mirror of the star database (or be satisfied with your connection to the BNL hosted db).

If these two things are working correctly you will be able to process a daq file with the usual bfc.C macro. Check that you can do this and do not proceed further if this is not the case as you will be wasting your time. You can find the correct bfc.C options to use with a particular daq file and software release combination here.

Collect scripts

The scripts are currently housed at PDSF in the 'starofl' account area. At the time of writing (and the time at which I set up embedding in Bham) they are not archived in CVS. The suggested way to collect them is to copy them into a directory in your own PDSF home account then tar and export it for installation on your local cluster. The top directory for embedding is /u/starofl/embedding . Under this directory there are several subdirectories of interest.

• Those named after each production, e.g. P06ib which contain mixer macro and perl scripts
  
• Common which contains further subdirectories lists and csh and a submission perl script
• GSTAR which contains the kumac for running the simulation

Therefore you need to create a replica of this directory tree. From your home directory e.g. /u/user do

mkdir embedding
cd embedding
mkdir Common
mkdir Common/lists
mkdir Common/csh
mkdir GSTAR
mkdir P06ib
mkdir P06ib/setup

Now it needs populating with the relevant files. In the following /u/user/embedding as an example of your new embedding directory in your user home directory.

cd /u/user/embedding
cp /u/starofl/embedding/getVerticesFromTags_v4.C .
cp -R /u/starofl/embedding/P06ib/EmbeddingLib_v4_noFTPC/ P06ib/
cp /u/starofl/embedding/P06ib/Embedding_sge_noFTPC.pl P06ib/
cp /u/starofl/embedding/P06ib/bfcMixer_v4_noFTPC.C P06ib/
cp /u/starofl/embedding/P06ib/submit.starofl.pl P06ib/submit.user.pl
cp /u/starofl/embedding/P06ib/setup/Piminus_101_spectra.setup P06ib/setup/
cp /u/starofl/embedding/GSTAR/phasespace_P06ib_revfullfield.kumac GSTAR/
cp /u/starofl/embedding/GSTAR/phasespace_P06ib_fullfield.kumac GSTAR/
cp /u/starofl/embedding/Common/submit_sge.pl Common/

You now have all the files need to run embedding. There are further links to make but as you are going to export them to your own cluster you need to make the links afterwards.

STAR First Cut and Production Geometries

Follow the link below to find the list of geometries implemented for a given year / RHIC run.  In general, the most recent version of the geometry (highest letter) should be used for simulations.   The availability of the geomtries in a given library (geometry.so or xgeometry.so) is indicated in the table.  NOTE:  xgeometry.so is preferred for all production geometries since 2006.  We do not support geometries after 2011 in the old geometry.so library.

The geometry naming scheme is as follows:

Geometry tags take the form Y<year><revision> or Y<year>_<configuration><revision> where <year> is  the 4-digit year, <revision> is a single letter denoting a  different approximation of the detector in a given year, and <configuration> denotes a distinct reconfiguration of the detector.  e.g. HFT installed or out.

• First cut geometry tags (e.g. y2010, y2011, etc... ) are the first approximation to the STAR detector, suitable for online production.  Minor changes which should not affect tracking may occur during the run.

• Production geometry tags (e.g. y2010a, y2010b, ... y2013_1a, y2013_2a, etc...) are denoted by a trailing letter appended to the first cut tag.  Once established, these geometries will be frozen in the DEV library, forming a reference for the production which used them.  In general, the latest geometry tag will be the best approximation of the STAR detector.

• Asymptotic geometry tags (e.g. y2004y,  y2010x, y2013_1x, y2013_2x, etc...) are tags with a trailing "X" or "Y" in their name.  These are TEST geometries, whose definition in DEV may change without notice, and should not be used in data production, simulation, embedding or offline analysis.

		starsim		Big Full Chain
		geometry.so	xgeometry.so	AgiGeometry	AgmlGeometry
1	y2001 geometries	x	x	x	x
2	y2002 geometries	x	x	x	x
3	y2003 geometries	x	x	x	x
4	y2004 geometries	x	x	x	x
5	y2005 geometries	x	x	x	x
6	y2006 geometries	x	x	x	x
7	y2007 geometries	x	x	x	x
8	y2008 geometries	x	x	x	x
9	y2009 geometries	x	x	x	x
10	y2010 geometries	x	x	x	x
11	y2011 geometries	x	x	x	x
12	y2012 geometries		x		x
13	y2013 geometries		x		x
14	y2014 geometries		x		x
15	y2015 geometries		x		x
16	y2016 geometries		x		x
17	y2017 geometries		x		x
18	y2018 geometries		x		x
19	y2019 geometries		x		x
20	y2020 geometries		x		x

 

1. Introduction
2. Getting an account and performing work at BNL
   • New users in STAR

1. Check you run in debug mode
   % echo $NODEBUG
   should give:
   NODEBUG: Undefined variable.

The above plots show 2-d histograms of eta and phi for pion candidates.  The plot on the top shows the candidates from the production L2-G trigger.  The plot on the bottom shows the eta and phi distribution for candidates from the L2-G 'test' trigger.  As of May 2007, I am not using these to exclude any runs.  I used Frank's pion trees to make these plots, imposing the following cuts on any pion candidate:

This is a plot of the tower status as a function of relative day (since the start of the second longitudinal period.)  The 4800 towers are on the Y-Axis and Days are on the X axis.  A dot means that that tower had a status other than good during that time period.