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 Jérôme 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

STAR CMS maintenance, web mirror and module development

This task would include

• The maintenance and support for the STAR main Web server's pages (non Drupal based but possibly, the content could be migrated to Drupal as applies) and keep the general information up to date.
• The maintenance and further development of the Drupal based Content Management System (CMS) used in STAR including
  • The primary site (STAR): maintenance, upgrade, security patch, troubleshooting and answer user's requests and problems
  • Inform users of issues through the Hypernews forum created for this purpose (drupal-hn).
  • Maintaining a test/development area (STARdev) where new modules could be tested by users and administrators.
• Adopt first principles for the safety of the Web content by applying backup, redundant copies, use of a snapshot server or other scheme.

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).

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.

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.