1) pMonitor 2) online “logbook”

1) pMonitor 2) online “logbook” • Without too many words: pMonitor has been resurrected to work with root 2.2.23. • Runs on RH6.1, glibc 2.1, egcs and what not • Problems are with an ever-changing root build procedure and behavioral changes which are not adequately reflected in version numbers pMonitor runs the actual analysis, filling of histos, etc as a background thread, so you have the command prompt to look at / work with your histograms. A flashback, we are at the computing meeting Sept the previous millennium…

Flashback Why multi-threading? • When you work offline (batch-style analysis, etc) you fill your histograms, and write them out when the data file is processed. You look at them later, fit them, analyze them, etc. Easy. • For online monitoring, you want to work with your histograms, display them at will, clear them, fit them, store them, whatever, while they are being filled in the background by your monitoring task. • At any time, you want your prompt (or a GUI) active so that you can give commands. • Until recently, ROOT couldn’t do that easily. You get the prompt back only after the processing has finished or has been suspended • Unless you built commands into your process loop to actually display histograms, you can see them only after processing has stopped or has been suspended (Timer). • “Stop processing” is something you don’t like too much in online monitoring -- you don’t want to miss events and miss the detector problem. • That’s where threads come in -- one thread fills, another waits for your command.

Flashback Now, how does it work? Compile a function into a shared lib. This function can be “forked off” as a thread. Both the “main thread” (your command prompt thread) and the background thread can manipulate the same objects [with some limitations]. Example: The background thread can fill histograms, at the prompt, you can work with your histograms, display them at will, clear them, fit them, store them, whatever -- you get the idea.

Flashback Making that mechanism into a framework • Given that basic principle, we have made a framework. • It loads libraries and sets up root for threads • it provides you with a handful of commands to steer the analysis • at well-defined points, it calls your routines (which you provide) • at your command, it will start the analysis background thread until it terminates or you stop it. • From the command prompt, you get access to all histos, etc. • In its simplest form, you provide 2 functions (copy from template) • int pinit() -- initialize, get histo factory, book histos, open files, etc. • int process_event (Event * evt) -- process an event, which is delivered by the framework. • This is the top-level entry to your analysis -- you are free to call or make whatever function or whatever object is needed for the analysis. You can use nodes, the histo factory, the toolbox, all the goodies. We called this framework “pmonitor”.

Flashback Example root [0] gSystem->Load("$PMON/lib/libpmonitor.so") root [1] ptestopen(); root [2] pstatus(); Not running Stream open: -- testEventiterator (standard) root [3] pstart(); Thread Main ID=1025 requested root [4] pstatus(); Running at Event 68 Stream open: -- testEventiterator (standard) root [5] 0 - load the library 1- open a test stream (testEventiterator) 2- get status (”Not running”) 3- start processing 4- get status (“running at event 68”)

Flashback User source code example #include <Event.h> #include <PhHistogramFactory.hh> #include <TH1.h> #include <time.h> #include <pmonitor.h> PhHistogramFactory *hf; int init_done = 0; PhH1 *h; // the one histogram int pinit() { if (init_done) return 1; init_done = 1; hf = PhHistogramFactory::instance(); if (hf) { h = hf->CreateH1F("H1", "Channel 0", 101,-49.5,49.5); return 0; } else return -1; } int process_event (Event * e) { // static int i = 0; Packet *p = e->getPacket(1003); if (p) { h->Fill (p->iValue(0)); delete p; } nsleep(100); // 100 milliseconds return 0; }

Flashback Standard pmonitor “commands” int pddopen (const char * ddname); int pfileopen (const char * filename); int ptestopen (); int pclose (); int pstatus (); int pstart (); int pstart (const int nevents); int pstop (); int pidentify (); int pidentify (const int n); int pclearidentify (); int pcontrol (); int pcontrol (const int seconds); open a dd pool as input open a file as input open a test stream close the stream print status information start processing start, but stop after n events stop processing have events id themselves have the next n events id themselves clear the “id” flag, no more id bring up status GUI (doesn’t work yet) update GUI each seconds (ditto)

pMonitor outlook Won’t invest manpower to make it happen on RH5.2 - concentrate on RH 6.1 add to nightly rebuilds on 6.1 machines -> available in RCF Manual /Howto started - action item for me get subsystems addicted to that Before we forget… what is this oMonitor we keep hearing about? Different goal here - aimed at the “RHIC TV monitor” type of application, cycle through displays of interesting but less interactive stuff, such as events/sec, number of errors, GB written/s, events monitored, and so on. PAdChamber is “oMonitoring” at this time, but once you have the “analysis” part right, it’s easy to migrate between frameworks.

Online logbook We something like that RSN now when we want to write down what we did. It should be… • be Web-interfaced • authenticated • backed-up • user-friendly • searchable • WAN-accessible • have an API so programs can make entries there • use a strong database • support all kinds of data, not just text • < your buzzword here>

We think we have a good candidate Of all things, it’s funded by DOE and goes under the project name DOE2000, developed at Oak Ridge, we got an implementation from FNAL Is in this incarnation, it appears to be geared towards shift logs in a nuclear power plant, well. highly configurable, PERL scripts with some utilities as CGI-scripts. Took me about 2hrs to install on my machine, you can play with it there (screenshots taken from my machine)

Playing around... Edward made some entries, and put a gif picture in...

Is it close to what we want? Very close. We can use the entry locking mechanism, the web interface, the way to make entries from a shift, most of the PERL scripts. We might want to eliminate the current state machine where you are bounded by shift start and end (want to enable that later again, maybe). We will replace the storage mechanism by - you guess it - Objectivity.This is very important, because it solves most of the other problems, such as backups, access control, and API’s from control processes.

Objy storage gives us interesting possibilities... …which I had not quite thought of before. Do not think in terms of entries in a log book. Think of objects put into the database, with the functionality they need to have. Just as before. Now give the objects the ability to spit out information in HTML about themselves. Now you have something much better, an object stored in the DB that can make itself show up in the logbook view, with adjustable detail. Any kind of object (GEO, Calib, run, whatever) can be taught to provide HTML output to be viewed Decouple content from formatting - we can fine-tune the HTML output at any time Run Control would put objects into the database as planned, no extra logging needed, just format the already existing info as HTML output

Logbook w/ Objy store I had about 3 hrs to play with this… In the Objy database you have (here) 5 objects which give HTML output. They are actual “Notes” in the “I typed it” sense, but they could be any object. I is amazing how much we can re-use here - the PHFileStore, PHTimeStamp, took only 3 hrs to get this framework

Run log entry You can ask the HTML output generator for different levelks of detail

Summary The DOE2000 project gives us nice possibilities for an online notebook All object can be made to give HTML output for web display without changing the inner functionality of the object We can make use of the extensive selection mechanisms of Objy Separate contents from formatting in an easy and natural way Objects can give different levels of verbosity, using hyperlinks to zero in on information the general web server can be distinct from the web server for log entries in the Countinghouse can cash in on security investments for Objy ( firewalls, Backups, etc) We wait for Objy on RH6.1, started to plumb the Objy storage into existing scheme Will adapt the scheme to our needs. Possibility for an Objy + HTML -savvy person

1) pMonitor 2) online “logbook”