Home » Groups » STAR Protected

Considerations for integration of FMS software into StRoot

Updated on Mon, 2013-10-07 12:35. Originally created by tpb on 2013-09-16 10:33.

Update 2013-10-07:

Please see the attached PDF (fms20131007) for notes from my meeting with Jerome.

--------------------------------------------------------------------------------

Jerome has been on holiday lately, so I am awaiting an opportunity to talk with him (hopefully this week if he is back). In the meantime, here are some thoughts I have had regarding the code. A lot of these points are things I want to discuss or clarify with Jerome, so please consider them "preliminary"; I will update them once I have talked with him. Feedback is welcome.

In no particular order:

  1. There is a very large amount of code in the PSU package; I count about 37,000 lines. My experience with software reviews tells me this will be (far) too much for a single review. We would need to decide on how to split it up into chunks for review purposes. I don't mean that the package actually needs to be broken up into sub-packages, but it would be helpful to review the code in chunks that each cover some area of functionality.
  2. Not all of the PSU package functionality is directly related to data production. See e.g. parts of the AnalTools class. Is it suitable to have all this functionality in a single library, or should code we provide for a STAR production chain be related solely to that?
  3. Using the "traditional" PSU package functionality (i.e. trigger data, external calibration files, environment variables etc) may be considered an "unofficial" method of analysis compared to the StRoot approach, as it doesn't have the same reproducability as using MuDST and the database, and doesn't integrate with embedding. Will we be allowed to provide two alternative approaches side-by-side, or will we be restricted to just providing a single, "official" StRoot approach? If the latter, how would this impact our code development and maintenance if the traditional PSU code is developed separately from the StRoot equivalent?
  4. I doubt we will be allowed to set our own environment variables when running in a production chain. We would therefore need to remove any dependence on environment variables when running in StRoot mode. e.g. the macro RunF6.C provided as an example fails if the SetFmsEnv script is not sourced beforehand.
  5. We should put some thought into how we store the resultant clusters and points; Yuxi has an alternative scheme in his version of the code that may be more suitable.
  6. Do we envisage supporting additional clustering algorithms? Currently the Yixun class is essentially our "StFmsClusterAlgorithm". Do we want to allow for users to plug in alternatives to this? It seems like a reasonable option to me, and I believe Yuxi's version of the code allows something along those lines.
  7. While getting the package in the form we want is a higher priority, we will need to check all code existing for compliance with the STAR coding and naming standards before submitting for review. This will be quite a big job, so having more than one person working on it will likely be necessary. We should also keep the standards in mind before we add or rewrite any code to save ourselves time later.

References:

Groups: