Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. be able to process svac, cal and beamtest input data files.
  2. provide soon feedback information to the web front-end (perhaps a "fake" run mode, which would be started by typing "skimmer try" ?)
  3. have a "merge" options for the output data files ? => do study hadd.
  4. generically scan, display, and copy auxiliary objects found in ROOT files.
  5. The GlastDataTypes C++ class have harcoded data types and values. They should rather be read from a configuration file, under the controll of the user.
  6. That same configuration file, or a separate one, should contain parameters instead of the environnements variables. Why not GAUDI parameter files ? Should we depend on GAUDI ?
  7. For the communication with the Web front-end, we should favor a early detection of problems, and setup a standard way to feed back the front-end with such early information (which could include an evaluation of the job end).
  8. Study the use-case "no tcut". In such a case, we should perhaps skip the use of a file containing the list of all data files.
  9. Enable tcuts through multiple data kinds.
  10. Idea : ensure that when a skimming is failing, the incomplete output data files is erased. Then, change the skimming step so that it will check that some output files already exists or not, and only do the ones which are lacking ? (a SK_FORCE_SKIP would enforce the skimmign skimming whatever the files, and perhaps would be "true" by default).

...

  1. I think we should plug to the FileListManager a list of PipelineConfig.
    When a FileListManager needs an information for a given task, it would ask to all
    instances of PipelineConfig, and see which one recognize this task and provide
    information about where to find the files. Such a structure should greatly help to
    manage the many kinds of pipelines under work.
  2. The use of CINT interpreter is a great source of bugs. We should make
    anything we can compilable.
  3. We need a complete redesign and implementation of errors management.
  4. To be explored : the use of ROOT MakeClass/MakeProject so to avoid loading libraries. First experiments are not very successfull, especially with mc/digi/recon files. But perhaps with tuples-like and FileHeader it could be of use.
  5. To be explored : hadd.
  6. Would be useful in skimmer to have a function so to expand Unix variables when they are used in scalar strings .
    When a release needs to be identified, thanks to file header, perhaps we should automatically search for such a FileHeader in all the available kinds of files=> gSystem->ExpandPathName.
  7. The different datakinds are skimmed one by one. We could investigate if we can skim them in parallel. In the same topic, perhaps we should think if we must reduce the number of different ROOT macros which are (slowly) started one after the other. Perhaps we should find a way to decorrelate what we call the "steps" from the processes (currently, each step is necessarily a separated process).
  8. Study Riostream.h .

...