Grabbing and copying this service page to use the html as a template for a new STAR Junior. Thank you to creator of the original page!

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.

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.