Difference between revisions of "Deprecated: JANA/DANA"

From GlueXWiki
Jump to: navigation, search
Line 87: Line 87:
 
#:
 
#:
 
# JEventProcessor objects should be deleted in JApplication destructor.
 
# JEventProcessor objects should be deleted in JApplication destructor.
 +
#:
 +
# Add option so GetParameter will (optionally) print an error message if a requested parameter does not exist.
 
<hr>
 
<hr>
 
<references/>
 
<references/>

Revision as of 15:04, 22 February 2010

JANA Home Page

http://www.jlab.org/JANA


Future development

Here are some thoughts about what things should be put into JANA or how it's current design should be changed. I am starting this to hopefully be a list of things that can be done later since I don't have time to do them right now.

  1. Default Factory Choice: After using the framework a bit, it has become clear that it would be nice to be able to specify the "default" factory for a given data type once and have that used everywhere. The way it is now, if I want to use a tagged factory for a certain data type, I have to create a configuration parameter and have every place that accesses the factory use that configuration parameter. There should be a way to tell the framework to use a specific tag if the request uses an empty string (default) for the factory tag.[1]
  2. JException/jLog: Standardize exception and logging classes.[2]
  3. Replace HDCLASSDEF with virtual method in JObject.[3]
  4. JANA namespace: Place JANA inside a namespace. Let's see, what should we call it ..mmmm.....Oh yeah, "JANA"![4]
  5. Geometry info: Some code was written to help with getting geometry info, but it needs to be revisited and completed. As of right now, folks have started putting geometry info into special factories. The geometry info is really a different type of data than what the factory mechanism is designed to do. This also needs to be tied in to the hdds system. This may entail adding a generic object storage mechanism into JApplication such that an object pointer is stored along with a valid run-range and can be retrieved by any factory of any thread.(??)[5]
  6. Out-Of-Band Factory Data: One thing discussed some time ago is how to access data on macro-scale from a factory in addition to the micro-scale data obtained through the normal factory mechanism. The specific example was how to access residual energy in a calorimeter that does not appear in any of the clusters a factory produces. This can currently be achived via the factory pointer, but maybe there should be a more formal mechanism to access a single object that holds this type of data. (??)[6]
  7. const correctness: Methods should be reviewed so that if they do not change internal object data, they should be declared const methods.
  8. Vertex Object: Create an object to hold the event vertex. For now it can be set to the center of the target, but later we can use tracks to help pin it down. This vertex object should be used by all reconstruction code instead of hard coding the center of the target.[7]
  9. Warn/Crash on auto factory generation: Maybe code should, by default, crash when a user asks for objects that don't exist instead of auto-generating factories. A command line option can be used to bypass this behavior.[8]
  10. Calibration constants: The idea for now is to make an API that allows one to request a set of constants by name. The name can be a colon separated list specifying the system, subsystem, ... down to the actual item one wishes to get. This could be templated to allow one to pass in a reference to an STL vector that the values could be copied into. To start with, the "database" could be a directory structure mirroring the colon separated directories with the "item" being a simple ASCII file. This would be very quick to implement, trivial for others to use, and easy to extend to using a real network-based database later on.[9]
  11. Add an "associated objects" map to JObject and a templated extractor method. This could be used for e.g. holding the hits used on a track. The values would be stored in a map whose key was the JObject pointer and whose value was a "tag". The templated method could pull out objects of the appropriate type by finding the ones that successfully dynamically cast into the desired type and have the appropriate (optional) tag.[10]
  12. Remove jerror_t and replace with exception throwing for call backs. It is also used in event sources for result codes so that needs to be either rethought or retooled.[11]
  13. Move the functionality of toString() from the factories to the JObjects.[12]
  14. Plugin to automatically generate ROOT trees from JObjects based on info gathered from a factory's "toStrings()" method.[13]
  15. Add feature to allow one to specify a number of events to skip and then a number of events to read via the command line[14]
  16. Read in options from a configuration file.[15]
  17. Automatically dump event number when a thread is killed and launch a new thread to take it's place.[16]
  18. Fix bug where fini is called when there are no events and init is never called.[17]
  19. Exit with error if plugin is specified but not found.[18]
  20. GetFactory method of JEventLoop does not attempt a substitution of the command line specified default tag when an empty tag is supplied. This is different than the behavior of the Get method. The GetFactory method should be brought into alignment with the Get method. At the same time, another method should be provided that allows easy access to the un-tagged factory even when a default is given via the command line.[19]
  21. Provide better checking for duplicate settings of default values of configuration parameters. Warn user if different defaults are set.[20]
  22. Emit an error or warning when calibration constants are asked for using a map, implying named fields, but no named fields exist. Similarly for vectors.
  23. Provide some sort of generic counters in framework to allow maintaining statistics on things like which factories failed how often etc. (suggested by Elton)
  24. Add an optional FiniPlugin()" routine for plugins so they can de-register things cleanly before being detached.[21]
  25. Fix problem with return code being 255 when "cleanly" exiting rather than 0 (identified by Mark I.)[22]
  26. Add GetSingle method to JObject[23]
  27. Add GetUsingPath method to JEventLoop to allow one to specify a specific set of factory tags to use when satisfying the request. This will need to somehow temporarily remove objects from factories that already have them since the inputs will be different in some cases. It will also need to have another container to hold all of the objects made since the originals will need to be replaced so subsequent calls to Get() are properly handled.
  28. Add more monitoring capability including statistics for each thread. [24]
  29. Add more control capability including dynamically changing the number of threads.
  30. Create janactl plugin for monitoring/controlling running processes via cMsg.
  31. Automatic runtime determination of the number of threads to use based on available cores/memory. Make this configurable via configuration parameter.[25]
  32. Add AddLog(string&) and AddLog(vector<string>&) methods to JObject so debugging info can be stored on an object-by-object basis. A Corresponding vector<string>& GetLog() method will also be needed.[26]
  33. Add ability to specify objects to write out to janaroot plugin.[27]
  34. Add methods to JGeometry to get list of all values that satisfy a given xpath.[28]
  35. Fix problem in JParameterManager where string values containing white space get parsed by stringstream so that only the first token is copied using SetDefaultParmeter if the parameter is already defined.[29]
  36. From Maurizio: would it be possible to give an option to JANA to log infos on screen only if asked to? And, to have those logs pre-fixed with something like " JANA >> " (notice the space at the beginning) to better identify them?[30]
  37. Add option to janadot to display differential of ticks rather than integral so one can plot ticks used by single factory.
  38. Add virtual methods to JEventProcessor that will get called at brun and erun (possibly init and fini?) for every thread. This would allow for some kind of resource allocation by thread that is a little more natural than doing it with if statements in evnt.
  39. Makefile.config is left for the last platform configuration was run on making it difficult to make new plugins on different platforms. BMS should be installed into prefix to allow 3rd parties to build using it.
  40. There is an apparent bug in the number of events processed with -PEVENTS_TO_KEEP (it is one less than it should be).
  41. JEventProcessor objects should be deleted in JApplication destructor.
  42. Add option so GetParameter will (optionally) print an error message if a requested parameter does not exist.

  1. This change was committed to the JANA repository on July 12, 2007 (r271)
  2. A merge of 2 JException classes (JException and JException2) was made with revision 426 on Mar. 3, 2009 and appeared in version 0.5.2. JLog was removed and JStreamLog and JStreamLogBuffer were re-written to be thread compatible in revision 489 committed on Dec. 16, 2009. That change will appear in JANA version 0.6.0.
  3. This change was made in April 21(rev. 318), 2008. This was actually modified to use a macro called JOBJECT_PUBLIC instead which is defined in JObject.h (as opposed to JFactory.h for the HDCLASSDEF macro). It was decided after all that the simplest and most user friendly way to get the desired functionality was indeed via a macro.
  4. This change was made April 21, 2008 (rev. 318). The namespace chosen was actually "jana" (lower case) to be more consistent with what appears to be the norm.
  5. This change was made on April 4, 2008 (rev. 315). The JGeometry class was made into a base class that specified the API and the a class JGeometryXML was introduced as a subclass implementing it. The JGeometryXML allows one to request geometry info using xpath style queries.
  6. April 24, 2008. ... nay. I think this would unnecessarily overcomplicate the framework. This type of data really should be obtained through the factory pointer.
  7. This is being removed from the list 12-16-2009. It is really more implementation specific and so should not be part of the framework.
  8. This change was committed to the JANA repository on July 12, 2007 (r271)
  9. This change was committed to the JANA repository on July 10-12, 2007
  10. This was committed April 21, 2008 (rev. 318). It has not actually been tested yet, but all of the hooks are there.
  11. This is very unlikely to happen at this point since jerror_t is ingrained everywhere. To do this would require a major modification to JANA that would not be backwards compatible. (Dec. 17, 2009)
  12. This was committed April 21, 2008 (rev. 318).
  13. The initial version of this was committed on July 15, 2008(rev. 349) It was included in version 0.4.7
  14. Committed on July 18, 2008(rev. 352). Included in version 0.4.7
  15. Committed on July 17, 2008(rev. 351). Included in version 0.4.7
  16. Committed on August 28, 2008(rev. 359). Included in version 0.4.8
  17. Committed on March 3, 2009 (rev. 432)
  18. Committed on August 28, 2008(rev. 360). Included in version 0.4.8
  19. Committed on March 3, 2009 (rev. 428)
  20. Committed on March 4, 2009 (rev. 433)
  21. Committed on March 3, 2009 (rev. 429)
  22. Committed on March 3, 2009 (rev. 431)
  23. Committed Dec. 17, 2009 (rev. 492)
  24. Committed Dec. 18, 2009 (rev. 502). This includes ability to probe JApplication for the per-thread values of Nevents, Instantaneous rate, and Integrated rate. In addition, JEventLoops can be probed for the processing time of the last event.
  25. Committed Dec. 17, 2009 (rev. 490)
  26. Committed Dec. 17, 2009 (rev. 491)
  27. Committed Dec. 18, 2009 (rev. 499)
  28. Committed Dec. 16, 2009 (rev. 488)
  29. Committed Dec. 17, 2009 (rev. 496)
  30. Committed Dec. 16, 2009 (rev. 489)