Below is a list of tasks for which we request help from the collaboration in the form of Service Tasks. We have been keeping track of some items which fall into this category while they are currently being worked on and marked as "Taken" in the lists below. The lists are separated by Offline and Online. Items marked by "*" are linked to additional information. If any of these items look interesting to you, please contact Jerome for more information.
If the column Taken displays an X, this means that we are having a potential candidate. However, you should STILL come forward if you are interested in the project. The service task committee no longer maintains the service task page. A white cell used to indicate that the task is also displayed there. Wherever all names are in italic, the task is essentially opened (light gray) or need more manpower.

Urgency

Long Term

Critical

High

Medium

Low

Back.

Done

TPC Calibration tasks

• TPC Gain and Drift velocity management
  TPC gains are recorded by the DAQ group. These need to be sanity-checked and placed into the DB several times during the run period. Automated TPC drift velocity mechanism needs to be monitored for proper operation and sanity of the data. New calibration code needs to be integrated into this scheme.

• Remnant sDCA after distortion corrections
  The signed DCA of tracks to the primary vertex is used to correct for SpaceCharge+GridLeak distortions in TPC data. The corrections intentionally bring the average sDCA to zero, but systematic deviations have been observed as a function of azimuth. It would be educational to characterize past data in this regard.

• Automate conversion of TPC field current into missing resistance
  To correct for an electrical short in the TPC field cage, we must convert a recorded current into a missing resistance value. The current is stored in the database and it would be beneficial to have this automatically converted and the resistances re-entered into the appropriate DB. This should be a relatively small task of just a couple days work.

• Primary vertex deviations from the BeamLine
  The BeamLine at STAR is well-defined and may be useful as fixed reference to study azimuthal anisotropies in SpaceCharge. It would be educational to characterize past heavy ion data in this regard.

• TPC post-membrane data studies
  All datasets acquired using the TPC accumulate data over a time window which extends beyond the drift time of electrons from the central membrane to the endcap. This data is generally dropped, but is potentially useful as a "zerobias" measure of activity in the TPC outside the triggered events. This could be useful as a luminosity measure in the sense that it is indicative of the general loading of the TPC, perhaps useful for SpaceCharge corrections.

• Study of TPC OFC west electrical short location
  An electrical short has been present since 2005 in the TPC outer field cage west, with a bimodal nature of shorting and not shorting (as seen in the measured currents). This short produces a potential distortion of TPC data near the short, but the magnitude and corrections of the distortion cannot be determined until the location of the short is known. Laser data must be studied to see if the location can be determine.

• Study effects of Reduced TPC Gains on Tracking
  The possibility of reducing distortions in the TPC due to ion leakage around the edge (and through) the gated grid via reduction of TPC gains has been demonstrated. Whether this is a viable option in light of its effects on track reconstruction efficiencies and dE/dx measurements is an open question and needs to be studied with the reduced gain dataset which we have in hand.

• Use of BBC granularity in understanding/preventing TPC backgrounds
  It might be possible to prevent collection of data with large TPC backgrounds by using segmented BBC scaler rates to observe anisotropies indicative of backgrounds. This task requires proof-of-concept that the BBC can provide useful information in this regard (for which work is in progress) and implementation of the segmented BBC online scalers for the upcoming run.

• TPC GridLeak Z-dependence
  GridLeak distortion in 2005 pp data shows a z-dependence which is not well-understood and needs to be explained.
  Status: Code to study GridLeak exists, but new ideas need to be invented and explored

• TPC Space-Charge characterization
  Systematic study must be done of the Space-Charge spatial distribution in the TPC as a function of luminosity measures, time, fills, time within fills. Without the knowledge of the spatial characteristics
  of space charge, one cannot code a correction for it, nor know what database parameters will be needed to describe its evolution through the run. Lots of invested time.
  Status: zerobias data needed

• TPC sector alignment
  Inner/outer TPC sector alignment can be studied using laser tracks fit to straight lines in the sub-sectors (inner and outer) and observing systematic deviations. This was done in the past, has not been studied recently, and needs to be reverified/redone for the current data. Should only affect DB parameters.

• TPC End-Cap tilt distortion measurements
  Yet another TPC field distortion. Uncertain what code would be used to determine this (ask Jim). Jim is writing the distortion correction code for this. There is no past experience with this. Likely requires new code and new DB parameters. Also needs Omega-Tau finished.

• TPC Space-Charge measures from SVT
  The SVT is an ideal device for observing systematic deviations in TPC tracks due to TPC field distortion effects. Studying how such deviations between SVT hits and matched TPC tracks vary with luminosity measures may lead to using such information to correct for Space-Charge "on the fly" with ITTF, and possibly to using such systematic deviations to measure other TPC distortions. This is viewed as a possible additional feature for ITTF.

• TPC Omega-Tau determination
  All field distortion corrections depend upon this one fundamental parameter. It needs to be measured in order to be used properly in all distortion corrections. There is also some uncertainty about whether
  this parameter needs to be disassociated into two separate tensor terms for radial-like and azimuthal-like distortions. Jim, Gene, and Howard Wieman are getting close on this and it may be too late in the game, with too much learning curve for anyone else to get involved.

• TPC Twist, Clock, and IFC-Shift distortion measurements
  There are several field distortions with are caused by physical imperfections in the alignment of TPC components. These distortions can be measured by studying differences in primary vertex distributions using east-only vs. west-only TPC tracks. Should only affect DB parameters. Needs Omega-Tau finished before finalization. Additionally may be affected by unfinished Space-Charge corrections.
  Status prior to 2005: Javier and Jamie are still on twist and ifcshift. Clock distortion can be removed as the data couldn't do any better than the survey.
  Status: Done with 2004, 2005 & 2006 data, but we need to look at 2007 data as soon as it comes through fast offline.

GSI enable MySQL The STAR MySQL for GRID project is an effort to integrate MySQL database in the GRID infrastructure. This means providing tools to help management of networks of replicated database and providing GSI authentication for MySQL connection. The project was started in 2003 and not completed due to manpower migration. This task is however essential for running production jobs on a seamless Grid environment. See the initial project page for more information.
Status: SBIR @ ANL granted 2005/2006 ; pending result, this project is aborted in STAR.

SVT calibration tasks

Several SVT calibration related tasks need attendance on a yearly basis. The SVT group pages are available for reading (some material of interest there). The calibration tasks are as follow:

• Individual Wafer alignment: Developed in Year4 by Herb Ward, this would need to be re-assessed in Year5.

• Laser calibration for the SVT: Done in Y4 by Jana Bielcik, the goal is to use time changes of the laser spot positions to remove temperature variations coming from a non-uniform temperature cooling of the SVT. See this link for more details or her presentation at the SVT review.

• Residual studies and alignments: See this link for more details.

Status: Work to be reconsidered after 2005/2006 SVT/SSD alignment efforts.

XML description for the STAR Geometry representation - Geometry Description Markup Language for the STAR VMC project.

With the emergence of abstract interfaces to Geometry modeling and Monte-Carlo simulations, the active HENP community is in need for a solution allowing the transition and support of the many years geometry description developed and in use by the expert teams while migrating to a new framework. The current geometry approach in use in running experiments appeared to be solid and has demonstrated its sturdiness, none of the new approach relies on Monte-Carlo model specific approach but rather integrates with widely distributed and adopted user environment such as the ROOT framework. The need for a higher level of abstraction in this area is required: the development of Geometry Description Markup Languages such as GDML may very well provide tools and base in which the existing geometries can be converted, supporting the existing framework while a transition to a new framework can be undertaken without disruption in productivity and efficiency. We propose to study the feasibility of using GDML (or other XML based approach) as a single source for geometry description and develop a front-end in the STAR environment. To achieve this goal, we propose to develop geometry parsers and converters producing TGeo based geometry description. Static (or fixed) geometry descriptions will be first tried and further study will propose a scheme to introduce mechanism for interfacing geometry descriptions and databases keeping a focus on a experiment non-specific approach.

Database interface to an XML Geometry description language

The project that pursues the XML description of the STAR geometry is now in the prototyping stage, and will allow the creation of a unified source, as well as representation, of the geometry model in the STAR software. Currently, we are using a "static" data in the XML files to define the various detector parameters. However, the approach is lacking the proper interface to the existing databases in order to retrieve time (or year) dependent values and optionally inject the data thus retrieved into the XML document being parsed. This effectively allows for a useful separation of the structure (XML tree) and content (values of tags in the XML code).

The person undertaking the project will have to acquire expertise in the cutting edge XML-data interface technology and choose the solution that would be expedient and robust. The resulting database interface will become a critically important component of the STAR software going forward.

Background and Shielding studies

At the time of this writing, little has been done about quantifying and characterizing the backgrounds inherent in the operation of the STAR detector, within the simulation framework. As the experiment is progressing and our understanding of potential problems associated with the various sources of background is improving, the need for a sophisticated background simulation model becomes more and more obvious.

In particular, we need to understand the implications of having spurious high-energy interactions of the beam particles in the remote areas of the tunnel up- and downstream of the experimental hall. In addition, there is a need to quantify and verify the effect of the shielding system that has been proposed in the late summer of 2005, as well as possible effect it has on the background conditions in the TPC and other central tracking devices. The candidate will need to acquire detailed knowledge of the relevant collider and structural support geometry, model it for the simulation studies, and coordinate the various settings and parameters of the simulation based on the requirements of the subsystem groups.

Online db interface / API development
Problem summary: The diversity of tasks and online processing supported while the data acquisition proceeds has increased for the past few years, ever pushed to a bigger demand as there is a need for Faster calibration turn around. The un-coordinated access to the online databases is however raising concerns as per its scalability and its impact on mission-critical database information gathering.
While the STAR collaboration has an integrated db API for onffline data mining and offline use, the online needs seem to be growing with more monitoring GUIs, fast calibration tasks or computing support in general which would benefit from such unified interface. Currently, several disjoint way of accessing the online databases is in place, not allowing for scalability and robustness (or speed / caching etc ...). This would present a challenge in the long run ... Port of the offline to online is not immediate as the offline database needs relies on schema evolution, short and compact summary database and not event-by-event database such as what is often needed online for the aforementioned tools.
This task would be to evaluate the current usage, identify current needs in terms of data throughput, data amount and propose a solution for an online API. One may imagine that a possible avenue along PHP / Web browsing enhancement may suffice but emphasis and primary goal would be a C++ API design
which could later be interfaced with the diverse existing components. Inspiration from (and understanding of) the offline framework would be a good start. While we noted and suggested for the requirements to be different (offline need extraneous "dimensions" such as treating simulation data and real data differently, schema evolution is an absolute requirement, etc ...) online db may not need all of those conveniences. Skills required would be C++, MySQL, PHP (possibly).
The STAR offline db API documentation is available at
http://www.star.bnl.gov/STAR/comp/db/
http://www.star.bnl.gov/STAR/comp/db/db_cppapi.html

Online web server development / STAR web mirror

This task would include the evaluation and deployment of the Plone web management system on the online Web server. While plone uses a virtual file system, its ability to manage web content through a database is of particular interest. Especially, the approach would allow for a Web automatic mirroring and recovery. We propose the task to include

• A smooth port of the main page available at http://online.star.bnl.gov/ to the plone base system. This may include look and feel, color scheme etc ... at minimum, content. For example, the main tools should appear as left menu for easy navigation as a general web template.

• The evaluation of the database approach should be made and in place before a transition from the old style to a plone based online web server.

• Plone system layout should provide accessible branches for detector sub-systems, each sub-system may manage their branch separately. The branches will be most helpful to keep documentation on the diverse subsystem and provide a remote editable mechanism allowing easy management and modification.

• Depending on time and experience, the development could be applied to the offline Web server to some extend. An area where it could benefit best is the tutorial area and the QA area. Within the plone system, users would be able to leave comments, add new tutorials etc ... a manager would then organize or make available to the public (flexibility of access to be discussed).

FCTP Calibration Task

Joern has completed the AuAu FTPC calibration. The dAu and pp calibration remain to be done. The FTPC calibration must be redone every time the FTPCs are removed and reinstalled. The calibration must be rechecked each time the beam is changed.

The following steps are necessary for calibrating the FTPCs:

1. Produce gain table
   Purpose: locate "bad" chips and adjust gains
   Frequency: ideally after each pulser run
   Method: analyze max ADC and charge distributions from pulser runs to produce gain table (Calibrations_ftpc/ftpcAmpSlope). Gain table entry for bad chips ; i.e. noisy or dead chip, set to zero. Using gain table, analyze clusters from data runs. If spikes and/or large unfolded clusters look again for noisy chips/pads. AuAu -> use pulser runs pp,dAu -> due to the lower multiplicity, use combination of pulser runs and real data.

2. Optimize drift maps by adjusting FTPC gas mixture parameters
   Frequency: at beginning of run, should be checked after each laser run
   Method: with laser data - determine the minimum of the residuals of the inclined laser tracks in the FTPC Compare with drift velocity monitor data.

3. Check inner cathode displacement
   Frequency: after each re-installation

4. Determine FTPC rotation angles
   Frequency: after each re-installation
   Method: AuAu -> vertex extrapolation pp,dAu -> the event multiplicity may be too low for the vertex extrapolation method and a new method may be required.

5. Optimize cluster finding and unfolding parameters
   Frequency: whenever collision type or FTPC gain changes

Disk Resource Manager + Job Scheduler

This task is special in that, while it is envisioned as an integration and testing task, it can go beyond this to include Java & Script code development over several months and is a very important task for STAR! It can also absorb 2 people.

The cost (both in $ and in maintenance/scalability) of an ever expanding centralized disks repository for (m)DSTs will swamp our RCF resources. A model that reduces both of these cost is a utilization of smaller disk volumes local to individual RCAS nodes. A couple of tools have (are being) developed to make use of such a data distribution model.

• Disk Pool,and cache management tools:

  • Disk Resource Manager (DRM) : LBNL developed C++ clients/servers for managing disk systems and data transfers from HPSS to local disk storage.

  • Xrootd : a SLAC tool used in Babar allowing for accessing distributed data in a seamless fashion (by connecting to a unique or DNS aliased redirector or set of redirector).

• Job Scheduler Project : BNL SUMS project (STAR Unified Meta-Scheduler), developed Java tool for job submission in a distributed data environment.

• STAR FileCatalog : BNL developed Perl+MySQL package for describing and locating files in HPSS and on disk

Our current framework make heavy use of distributed disk but has the disadvantage of being very static. Files are populated on demand in a data preparation phase, not allowing for rapid turn around and dynamic evolution based on user demand. The DataCarousel, based on the ORNL batch system is the heart of the distributed disk population and we are envisioning to replace (or alter) this developed Perl package for managing data transfers from HPSS by a new and improved automated framework. This task includes one or more of the following:

• Work on evaluating “a” tool or scheme allowing for dynamically populating our distributed disks

  • Work with the LBNL Storage Management Group to install a test bed for using DRM and test its functionality against our data management needs within RCAS. A “coordinator” would need to be developed, interacting with the diverse DRM. However, the hand-shake with our mass storage, HPSS, would be part f an already deployed strategy based on SRM tools and components ...
    OR

  • Deploy and evaluate Xrootd to serve as the coordinator of requests, and later modify Xrootd to interface with the existing SRM tools and infrastructure ...

• Test the Job Scheduler package on our current analysis nodes and provide feedback to developers as per how to alter the current existing job submission framework to include the new dynamic-distributed-disk population. Issues such as the need for a “planner” (optimizing bundle requests) versus population of disk “on the fly” is a plus.

• Investigate the need to integrate the solution with our FileCatalog, DataCarousel and Scheduler implementations wherever applies. For example, if Xrootd manages the distributed disk, is there a need for indexing all of our distributed disk files ?? The approach may be simpler by leaving Xrootd manage finding the files and reduce the FileCatalog name space to a minimum (persistent storage only files would be kept).

Online Development Tasks

• L0, L1, & L2 scaler processing and DB feed

• Online histogram development/ DB feeder

• Online cluster configuration and documentation

• Integrated beam+scaler+star-data time dependent monitoring tools

• Expand OnlineDB Browsing Tool (RunLog Browser)

These items (as one) were intended to handled by an single assigned/hired person in Online computing. This assignment is unclear but the tasks remain. Although there is overlap in many of these items, they can be worked on independently and represent well defined projects. Ideally, one or two junior level people could be assigned to Online computing (~25% effort) with an initial 3-6 months stay at BNL followed by a reduced effort (5-10%) remotely. In such an arrangement, the items listed here represent the set of tasks that these people would work on.

Extensions of the offline DAQ Reader and DAQ100 Reader

With the arrival of the DAQ100 project (i.e. Clustering being made online), we need to ensure that our offline software is able to

• Read and propagate cluster information when available. Those will appear as new data banks but are part of the TPC implementation.

• Make sure that the old format is still supported (i.e. TPC pad signals)

• Bring the DAQ Reader up-to-date

In addition, an evaluation of whether or not we can use the online Reader code (Pool library) should be made for future development work (and software convergence) and a design/layout suggested. This latest task has a lower priority than getting the current reader compatible with thew information.

Offline trigger code interface

In Year3, the online group is planning to save the trigger(s) information during the run in an independent format rather than in the datastream. The main idea is to accommodate for N triggers (N = 32 at maximum) BUT, they also would like to have the ability to associate a version to each trigger word. For example, a trigger named 'minbias' may have 10 different versions depending on a definition (and as our detector layout evolves), 'central' 5 versions etc ... This is basically creates the need for a potentially infinite (or large) number of pair (trigger,version) not possible to support in any data format. The triggers will thefeore be saved in a database with an triggerID, trigger-name, version and a string definition. The RunTime system will also save information such as run-number, triggerbit set, triggerID, triggerSetupName. The basic 32 bit trigger word would still be present in the data-stream but its exact definition can only be sorted though an association in the database.

This scheme does not allow for a straight forward offline selection of events based on individual triggers. We then need a Class interface to the database information which would :

• Return the appropriate 32 bit data-stream trigger word giving a set of trigger-name (may be additive) and a run-number. This function should be envisioned as a selector for the offline trigger Maker.

• Return a list of trigger-name, or definitions for a given runnumber

• Return a list of trigger-name giving a 32 bit trigger-word and a runnumber

• All method of such class should be designed to work and being usable at any level (trigger Maker, MuDst reading, tracker etc ...) so this Class should be as independent as possible of the STAR framework (Database Maker Interface should be used).

The person taking this task should work in close contact with the offline Software team, Database leader and the online DAQ team.

Hypernews Development

As Hypernews Forums become more and more popular, there will be a need to support and extend the Hypernews capabilities. However, the STAR Hypernews forums system are modifications from Official Hypernews toolkit. Extensions over base HyperNews were done originally for BaBar HyperNews by P. Raines, T. Wenaus. Implemented for STAR and by T. Wenaus. and currently maintained and extended by J. Lauret . This task would be best accomplished by anyone having experience in interacting with a software development group. It would include, as a first step, identify all modifications in our current version, submit to the original developers and obtain a new Hypernews package universally supported. The candidate for this task would further develop our forums capabilities, including, but not exclusively

• Fix forwarding problem (Email from one forum sent to the other bounce back to original forum)

• Limit number of message to display -> Finalize / consolidate message display limit

• Implement submission of messages to several forums (CC list)

• Implement other threading method (by date, by author)

• Fix selective forum search problem

• Prospect the possibility of treating attachments (purely a sociological implementation / attachment are removed from STAR Hypernews but this could become a configurable switch)

• Add the possibility to do a global display (all forums) of the latest N message (latest posted at a glance)

• Extend with a daily or weekly digest possibility (for posting summary but also success, Email delivery failure etc ... any stat info)

• etc ...

Note: A collaborative effort with BaBar and the LHC is underway to provide a consolidated version with all modifications from the community re-merged into a single refreshed distribution.

Studies of the effect of different gas mixtures, temperatures and atmospheric pressure on FTPC physics results
The aim of this work is to understand how wrong measurements (or imprecise knowledge) of gas mixture, temperature and pressure affect FTPC results, such as momentum and charge sign resolution, efficiency, dca distribution... To study this, the FTPC simulation and reconstruction framework (embedded in the STAR software system) will have to be used. Simulations with different reconstruction parameters (use of different gas compositions and temperature and pressure corrections). Many software tools are already available, but will probably need to be refined or adapted. This task may be done in a month time.

E-EMC DAQ event reader

For every sub-system, a DAQ Reader needs to be be written in order to unpack the raw data and propagate its infornation throughout the chain. The E-EMC is in dire need of such a reader (STAR Maker). DAQ format for the E-EMC, well defined, will be provided for this task.

E-EMC hit display

Develop a tool for the hit display and basic histograms for E-EMC, needed for commissioning of E-EMC and real-time debugging.

Gain matching of SMD strips for E-EMC The SMD (Shower Maximum Detector) in E-EMC is built out of 2 orthogonal planes made out of triangular scintillating strips. Matching of MIP tracks from TPS to fired strips allow gain matching. No software exist.

EEMC Integration to ITTF

Use existing and develop required code to incorporate the EEMC geometry and hits in the ITTF Tracker.

The task involved consists in writing three (derived) classes for the EEMC detector group. These include StiEEMCDetectorGroup, StiEEMCDetectorBuilder, and StiEEMCHitLoader. All three classes must derive from existing Sti base classes to be compatible with the existing software. The StiEEMCDetectorGroup class defines a broker class that instantiate the builder and hit loader classes. The StiEEMCDetectorBuilder class is a builder which defines the materials, volumes, and detectors relevant specifically for the EEMC on the basis of information loaded from the STAR EEMC database (if exists). The StiEEMCHitLoader class fulfills the role pf hit loader from StEvent format into StiHit format. The three classes can be inspired from existing classes written for the TPC, and SVT.

FTPC Integration to ITTF & Development of a track transport code for large eta

Use existing and develop required code to incorporate the FTPC geometry and hits in the ITTF Tracker.

The task involved consists in writing three (derived) classes for the FTPC detector group. These include StiFTPCDetectorGroup, StiFTPCDetectorBuilder, and StiFTPCHitLoader. All three classes must derive from existing Sti base classes to be compatible with the existing software. The StiFTPCDetectorGroup class defines a broker class that instantiate the builder and hit loader classes. The StiFTPCDetectorBuilder class is a builder which defines the materials, volumes, and detectors relevant specifically for the FTPC on the basis of information loaded from the STAR FTPC database. The StiFTPCHitLoader class fulfills the role pf hit loader from StEvent format into StiHit format. The three classes can be inspired from existing classes written for the TPC, and SVT .

Task-1: Develop an alternative transport mechanism to enable tracking in longitudinal detectors such as the FTPC and the E-EMC (rather than radial detectors). Large eta TPC track with a low number of hits also to be developed. Track projections to the PMD is of great interest. In the TPC, large eta tracks typically have less than 10 hits. However, using a vertex point as an extraneous constraint and the E-EMC for track purity (Shower Maximum Detector would give an additional point) should be investigated.

Much code can be reused from the existing transport code used in the TPC, and SVT, but a slightly different track model has to be created to enable tracking longitudinally i.e. using "z" as the independent coordinate rather than "r".

FTPC/E-EMC and track extrapolation to PMD

The FTPC would greatly benefit from exercising the track extrapolation to a forward detector such as the PMD within the ITTF framework. Aimed to provide methods to accomplish those tasks, the framework was not used to date for forward tracking demonstration.

GUI Tools for the STAR Event Display

Extend the capabilities of the STAR Event Display to facilitate the development and debugging of the tracker. This involves writing a few ROOT compatible classes for the dynamic instantiation of templated pull down menus. Note that this task may require several service task(er) ...

Specific Functionality Required :

• Dynamic Detector view/ inclusion/ selection selectivity - Currently the detector components to be displayed are selectable and can be turned on/off but hard coded - As the tracker evolves to include new components the display selector must be abstracted to enable the selection of arbitrary number and types of detectors. The selection or automatic recognition of object should consider the re-use of a possible XML based geometry model in STAR or a Virtual Monte-Carlo level approach.

• Dynamic Track Filter - The GUI provides an interface to selectively set the track filters. The interface is somewhat clumsy and limited and needs to be upgraded. Selection based on StEvent model may be considered for this improvement. However, the STAR generic interrator for StEvent is rather slow and need re-inspection and possibly re-design.

• Dynamic Hit Filter - The GUI/Tracker does not provide for hit filtering - This functionality is required to fully debug the tracker.

• Track/Hit Plotting Policy - Currently the color/shape/line type policy is hard coded. It would be convenient to be able to select dynamically the color code (etc) on the basis of abstract display policies so one could display tracks using different colors/line types selected on the basis of (a) MC particle id, (b) whether tracks are matched, merged, split, etc, on the basis of the pt, etc...