Home » PANDA » PandaRoot » Meetings » Pandaroot meeting, Tuesday 13th of January, 10:00, EVO
| Pandaroot meeting, Tuesday 13th of January, 10:00, EVO [message #7664] |
Sun, 11 January 2009 15:59  |
Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Dear all,
Next Tuesday will have our regular PandaRoot meeting @ 10:00, EVO (e.g. usual place and time)...
Tentative agenda points
1) General announcements
- Dashboard
2) Code rearrangement
- reducing code dependencies -> when?
- renaming class names CBM to Fair
3) Code optimization
- strategy?
4) Physics Performance Studies with PandaRoot (Bertram)
- what is needed?
- how to proceed?
- etc...
5) A.O.B.
- items for next meetings
Hear you then,
Johan!
[Updated on: Mon, 12 January 2009 21:34] Report message to a moderator |
|
|
|
|
|
|
|
| Re: minutes [message #7690 is a reply to message #7689] |
Fri, 16 January 2009 12:30  |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Hi,
few comments from my side, considering that during the last meeting I was flying and I could not attend.
| Bertram Kopf wrote on Fri, 16 January 2009 12:05 |
- schema migration: It is correct that root provides a tool for schema migration by just increasing the "ClassDef" number. This only works as long as you remove members which are not used anymore in the newer releases. But in case where you add members which afterwards will be used, the application will crash even by increasing the ClassDef number.
|
I am not so sure about this. I remember, from my HAES experience, that I was able to read old files with new code versions, even if new data members were added and without crashes. Of course, when there are big changes in the compiler or in ROOT then it is not always possible to recover the files, but this does not depend directly from us and it should appear very seldomly.
I will try to do some checks.
| Quote: |
-common interface to event generators: I took a look to the documentation of UniGen (http://wiki.gsi.de/cgi-bin/view/Personalpages/UnitedGenerators). As far as I can see there it's just a package which allows "to convert output of various event generators to a generic root format". If this is correct, this has nothing to do with a common interface. The idea is to setup, configure and run the various generators in the "same" way!
|
I agree with Bertram, Unigen is a common converter and not a common interface.
But I think we have already a common interface inside our code, which is CbmPrimaryGenerator. We give all our interfaces (dericed from CbmGenerator) to the primary generators, thus in theory everything is already inside.
Maybe we could also give it some filter criteria, so that we have a selection at this level. I suppose it is just a matter of writing few lines of code, such as a PndPrimarySelector class, and then we have also the event filter.
Of course opinions and comments are welcome.
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Nov 30 21:08:09 CET 2024
Total time taken to generate the page: 0.00572 seconds
|
GSI Forum
Search
Help
Members
Login
Home
