1 / 6

BaBar offline code’s ecological niche

BaBar offline code’s ecological niche. Set of non-overlapping idioms Event - our software bus? Manages ownership of all common data Provides access by name & type Rendesvous is outside the software, among the people Not all Tracks are really alike, and those differences can matter

oren
Download Presentation

BaBar offline code’s ecological niche

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. BaBar offline code’s ecological niche • Set of non-overlapping idioms • Event - our software bus? • Manages ownership of all common data • Provides access by name & type • Rendesvous is outside the software, among the people • Not all Tracks are really alike, and those differences can matter • Environment - slower changes, common config/conditions • Blind request via proxy cache-handlers • Writing the proxies was tricker than anticipated • Significant update computation built in by systems • Used by non-overlapping “modules” • Simple inherited interface • Not strongly typed!

  2. Execution & Configuration Idiom • “What to execute” mixes two levels • Sequence of modules • Specific settings in those modules • Configuration via “Framework” tool • TCL & command line • Several forms • Now using “execute scripts” plus “dump&restore” • Execution (event loop, start/stop, etc) via same tool • Multiple implementations to handle specific event sources • Visible in the event loop implementations, start/stop, error handling

  3. Components == Modules? • Most composition is of small algorithms • E.g. a track finder, an alignment processor, etc • This is where variation happens • Much more often than “a new histogrammer” • Much more necessary • Composition by coding vs composition by configuration

  4. Application building vs exploration • We have >100 “production” applications • Routinely built, run past author’s end of interest • Alignment, QA, etc • Plus 100’s of “analysis” executables • Built by composition of modules • Getting it to link, run is not hard • Hard questions: • What components are needed? • How exactly should they be configured? • E.g. “run at all” vs “give right answer”

  5. Configuration • Configuration management via releases • Configuration sanity checking? • Distribution of knowledge • Computer vs human reasoning

  6. Role of general knowledge • We didn’t actually speak FORTRAN… • C++ from books, other labs, vs local idioms • “Burden of proof” approach by collaborators

More Related