2
OpenPAW A reimplementation of PAW with OpenScientist tools. http://www.lal.in2p3.fr/OpenScientist Commands : Today the C part of KUIP extracted from old CERNLIBS. But a C++ rewriting of KUIP would be welcome (Any volunteer ? No one, as usual). pawcdf.cdf taken from old CERNLIBS, then SAME command syntax than PAW. Obviously not all commands and options yet implemented, but things are underway… pawex1.kumac up to pawex24.kumac already emulated with quite same rendering than PAW. Graphic done with : OpenGL as a rendering layer (then very fast on most local machines (especially on Macs)). Open Inventor as a scene manager. Coin3D implementation of SIM is used. HEPVis / SoAxis, SoPlotter nodekits to handle a “plotting” scene with axes. XY, Lego, function, contour plotting are here. Obviously with better rendering (especially 3D) than PAW. PS production done with gl2ps (ok ok, big files, but WYSIWYG (especially with 3D)). Remote X11 ruled out : too slow (especially on crowded central systems). USE YOUR LAPTOP. GUI done with OnX, then : Native GUI (Cocoa, Windows, Qt, gtk, Motif) produced with OnX from an XML description of the GUI. Then the best speed that we can get on a local desktop. GUI described in XML with interpreted callbacks : <widget class=“PushButton”> <activate exec=“kuip”> h/plot the_awful_10</activate> </widget> “OperatingSystem> opaw “ to start with a PAW-like GUI (one prompt and one viewer). “OS> opaw -gui “ to start with a more complete and compact GUI “a la PowerPoint”. Why “open” ? Because using a maximum things from elsewhere (use human resources of the web). Follow the “software least action principle” : reach maximum functionalities by minimizing the size of home made code. Have a very modular architecture through the usage of pure abstract interfaces. This permits to integrate various technologies (various languages, interpreters, IO system, native GUIs ) in a very clean way (without the knotty design of some). That’s right that today the whole set of PAW commands (and options !) is not recover ; but, on various aspect, someone has already much more than in the past. We want also demonstrate to some, that we can offer a continuity to physicists at the same time that, behind the scene, software engineers has the freedom to move toward new technologies. OpenPAW could be seen as a PAW interactive front end to an AIDA implementation. Or AIDA could be seen as the C++ API to OpenPAW. Motivated from a brainstorming lunch at the Vancouver Geant4 workshop : “What is AIDA ? We want PAW !!!” Ok, then let us do what should have been done at CERN for long : migrate a well known and heavily used tool to new technologies. .Barrand, permanent debugger of CERN software at CNRS / IN2P3 / LAL “opaw -gui” over pawex10.kumac. A more complete GUI “a la PowerPoint”. Here on a Mac by using the native Cocoa (NextStep). Note that the GUI being described in XML, someone can easily customize everything ; in particular the menu bar. Pawex1.kumac with default simple GUI : OperatingSystem> opaw pawex1.kumac The viewer can refresh itself ! (Yeahhhh) OperatingSystem> opaw -gui -Xt pawex9.kumac. Xt/OpenMotif version of the GUI (Motif still faster than gtk and Qt on a Linux !!!) Someone can easily switch on the “Inventor viewer decoration” and manipulate a 3D (or even 2D) scene with the famous Inventor thumbwheels. Someone can move and resize “zones” (AIDA::IPlotterRegion) with the mouse and pick bins. OS> opaw pawex9.kumac. Contour done with some code borrowed from Microsoft CodeProject.

OpenPAW A reimplementation of PAW with OpenScientist tools. Commands : Today the C part of KUIP extracted from old

Embed Size (px)

Citation preview

Page 1: OpenPAW A reimplementation of PAW with OpenScientist tools.  Commands : Today the C part of KUIP extracted from old

OpenPAWA reimplementation of PAW with OpenScientist tools.

http://www.lal.in2p3.fr/OpenScientist

Commands :

• Today the C part of KUIP extracted from old CERNLIBS.

But a C++ rewriting of KUIP would be welcome (Any volunteer ? No one, as usual).

• pawcdf.cdf taken from old CERNLIBS, then SAME command syntax than PAW.

• Obviously not all commands and options yet implemented, but things are underway…

• pawex1.kumac up to pawex24.kumac already emulated with quite same rendering than PAW.

Graphic done with :

• OpenGL as a rendering layer (then very fast on most local

machines (especially on Macs)).

• Open Inventor as a scene manager. Coin3D implementation of SIM is used.

• HEPVis / SoAxis, SoPlotter nodekits to handle a “plotting” scene with axes.

• XY, Lego, function, contour plotting are here.

• Obviously with better rendering (especially 3D) than PAW.

• PS production done with gl2ps

(ok ok, big files, but WYSIWYG (especially with 3D)).

• Remote X11 ruled out : too slow (especially on crowded central systems).

USE YOUR LAPTOP.

GUI done with OnX, then :

• Native GUI (Cocoa, Windows, Qt, gtk, Motif) produced with OnX from an XML

description of the GUI. Then the best speed that we can get on a local desktop.

• GUI described in XML with interpreted callbacks :

<widget class=“PushButton”>

<activate exec=“kuip”> h/plot the_awful_10</activate>

</widget>

• “OperatingSystem> opaw “ to start with a PAW-like GUI (one prompt and one viewer).

• “OS> opaw -gui “ to start with a more complete and compact GUI “a la PowerPoint”.

Why “open” ?

• Because using a maximum things from elsewhere (use human resources of the web).

• Follow the “software least action principle” :

reach maximum functionalities by minimizing the size of home made code.

• Have a very modular architecture through the usage of pure abstract interfaces.

This permits to integrate various technologies (various languages, interpreters,

IO system, native GUIs ) in a very clean way (without the knotty design of some).

• That’s right that today the whole set of PAW commands (and options !) is not recover ; but, on various aspect, someone has already much more than in the past.

• We want also demonstrate to some, that we can offer a continuity to physicists at the same time that, behind the scene, software engineers has the freedom to move toward new technologies.

OpenPAW could be seen as a PAW interactive front end to an AIDA implementation.

Or AIDA could be seen as the C++ API to OpenPAW.

Motivated from a brainstorming lunch at the Vancouver Geant4 workshop : “What is AIDA ? We want PAW !!!”

Ok, then let us do what should have been done at CERN for long : migrate a well known and heavily used tool to new technologies.

G.Barrand, permanent debugger of CERN software at CNRS / IN2P3 / LAL

“opaw -gui” over pawex10.kumac.

A more complete GUI “a la PowerPoint”.

Here on a Mac by using the native Cocoa (NextStep).

Note that the GUI being described in XML, someone can easily customize everything ; in particular the menu bar.

Pawex1.kumac with default simple GUI :

OperatingSystem> opaw pawex1.kumac

The viewer can refresh itself ! (Yeahhhh)

OperatingSystem> opaw -gui -Xt pawex9.kumac.

Xt/OpenMotif version of the GUI (Motif still faster than gtk and Qt on a Linux !!!)

Someone can easily switch on the “Inventor viewer decoration” and manipulate a 3D (or even 2D) scene with the famous Inventor thumbwheels.

Someone can move and resize “zones” (AIDA::IPlotterRegion) with the mouse and pick bins.

OS> opaw pawex9.kumac.

Contour done with some code borrowed from Microsoft CodeProject.

Page 2: OpenPAW A reimplementation of PAW with OpenScientist tools.  Commands : Today the C part of KUIP extracted from old

OpenPAWA reimplementation of PAW with OpenScientist tools.

http://www.lal.in2p3.fr/OpenScientist

OS> opaw pawex16.kumac.

Creating tuple, reading data from a file, doing some projections.

Note that the NTUPLE/PRINT has same look and feel than PAW.

OS> opaw pawex11.kumac

PAW> function/fun1 100 htfun1.f 100 0 1

The htfun1.f file is “on the fly” compiled, put in a DLL and loaded

The same can be done with C and an “extern C” C++ function.

OS> opaw pawex6.kumac.

Fitting over a vector. Fitter is the SEAL / C++ Minuit.

OS> opaw pawe3.kumac

Manipulation of vectors

G.Barrand, permanent debugger of CERN software at CNRS / IN2P3 / LAL

Vector handling and SIGMA done with :

• Lib::Vector template class. A multidimensional vector template over std::vector (then fast).

• SIGMA command done with the little Lib::Processor algebra interpreter. Done with lex and yacc and aware of the Lib::Vector. Something like V1 *V2 loops directly within std::vectors. Fast.

COMIS replaced by “on the fly compilation and loading” of FORTRAN, C, C++.

• Full language available at full speed.

• Avoid the burden of interpreters, but Python, CINT could be plugged in too.

The painfully question of the IO :

• In batch, use the AIDA::ITRee of OpenScientist to put AIDA/Lab objects in a file at ROOT format

by using the light Rio package.

• Someone can also use various AIDA implementations to produce AIDA xml files with histograms and tuples.

• From the “opaw” program :

• opaw> h/file 2 my_file.root

• opaw> h/plot 10

• opaw> close 2

• Note that OpenPAW can read ROOT3 files containing TH* and simple TTree containing real numbers.

(This probably does not work anymore on ROOT4 files, since the tribe passes its time to change basic things).

(What is a file at the ROOT format ?)

(When are we going to have an open source appealing IO system and OO database ?) (In ten years, when I shall finally have time to write RioGrande ?).

• OpenPAW can read ascii hippodraw tuple files.

• If the “Zebra” driver is reconstructed in OpenScientist/Lab,someone can read hbook files. But it needs to link against the old CERNLIB. (Any volunteer to write a Zebra reader in C++? No one, as usual)

The AIDA-3.2.1 implementation is the OpenScientist-13.0 C++ one with :

• histogram done with HCL. HCL is 20 % faster than the ROOT TH*

(because inner std::vector<double> is faster than the reinvented TArrayD).

• fitting done with the SEAL / C++ Minuit.

• tuple done with the column wise Lab::Tuple done with buckets of std::vectors.

OS> opaw pawex8.kumac

OS> opaw pawex24.kumac

OS> opaw pawex8.kumac

SIGMA manipulation of vectors