Home » PANDA » PandaRoot » General » Closing SVN access on Wednesday 11 February 2009
| Closing SVN access on Wednesday 11 February 2009 [message #7851] |
Sat, 07 February 2009 08:44  |
Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear colleagues,
On Wednesday 11.02.09 we will close the read and write access to FairRoot/CbmRoot/PandaRoot repository, So that we can rename the base classes and update the Runime Data Base, this should take one or two days, during these two days:
1. All code in the SVN will be adapted to these changes
2. All ASCII Parameter will be also adapted
After these changes, we will lose the backward compatibility to the ROOT files already produce. However old files can still be used with the old releases!
Please synchronize your development code with the trunk before Wednesday. Otherwise you will have to merge the changes yourself!
Regards
Mohammad
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7881 is a reply to message #7851] |
Mon, 16 February 2009 13:11  |
Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
|
first-grade participant |
From: *gsi.de
|
|
Hallo,
The svn access is opened again, during the last few days we restructure many things beside of the naming changes, the most important changes are:
1. Rename the base classes, this has been also propagated to the user code
2. The mcstack directory have been renamed to pndbase
3. Data classess (hits, points, etc..) has been moved to pndbase except for emc, dch and tpc. these detectors have data classes that includes many files from the detectors classes, something which should be discussed if this is really necessary!
4. I comment out two classes in the dch, because one of them inherits from one of the STT classes! please correct this
5. Beam energy is now implemented in the FairRunSim, choosing an energy will automatically take the proper field map for the dipole etc.
6. New Field maps are in SVN, Dipole and Trans. are beam energy dependent, Solenoid not, there was a bug in the Solenoid maps (Solenoid1-4) it is corrected now! please test it and let me know! an example of how to use this and the beam energy is in macro/run/run_sim.C and macro/emc/sim_emc.C
6. Detector list is implemented in pndbase.
8. Stack filtering is changed in the PndStack, the user does not see the Bit array anymore, he just have to call:
PndStack* stack = (PndStack*) gMC->GetStack();
stack->AddPoint(DetectorId);
9. Stack filtering is set by default to 1, which means particles that do not hit any detector and do not have any daughter that hits any detector will not be saved.
to switch off this filtering call PndStack::SetMinPoints(0); in the g3/4Config.C
10. The Runtime data base has some major changes (From Ilse König). ROOT basic types and arrays are used not, fill/addBinary are replaced by fill/addObject, in the ASCII files, Int_t, Double_t ..etc are used instead of i,d ..etc. These changes are also propagated to the user code and parameters.
That was the most important changes, there was a lot of cleaning and removal of historical stuff also!
regards
Mohammad
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7895 is a reply to message #7881] |
Tue, 17 February 2009 14:00 |
Aleksandra Wronska
Messages: 38
Registered: May 2006
Location: Cracow
|
continuous participant |
From: *if.uj.edu.pl
|
|
Dear all,
as for Mohammad's point 4, indeed, one of my classes inherits from one of the stt classes, namely SttRecoHit. I want to use exactly the same code, so I saw no point doing copy&paste. Some time ago I suggested to create a bit more general class in another directory, e.g. in recotasks, such, that both stt and dch can make use of it without being dependent on each other. As this has never been done, either dch package must depend on stt or I duplicate the code of SttRecoHit and WirepointHitPolicy. I also find both solutions unsatisfactory. Any suggestions?
cheers,
ola
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7898 is a reply to message #7895] |
Tue, 17 February 2009 15:27 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Ola,
actually the easiest way to proceed is that you create your own PndDchRecoHit without inheriting from the PndSttRecoHit, by copying it and the WirepointHitPolicy files and adapting them to your detector. In fact in the PndSttRecoHit the calculation of the detector plane in PndSttRecoHit::detPlane(AbsRecoHit* hit, AbsTrackRep* rep) contains a check on the distance of the point of closest approach from the firing wire that you may not want to use:
// check vpf inside tube
if(distance>0.5) {
cout << "vpf outside the firing tube" << endl;
FitterException exc("distance vpf-wire > 0.5", __LINE__,__FILE__);
throw exc;
}
in order to throw away the extrapolated hits outside the tube!
In addition to this the WirepointHitPolicy is not general enough to be inserted in a directory such as recotask or better genfit, where the other reco hit policies are, because it is specific for our particular choice of plane...
So, in order to avoid any problems, in my opinion it is better to duplicate these two classes, even if they will be almost the same for STT and DCH.
Ciao,
Lia.
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7899 is a reply to message #7895] |
Tue, 17 February 2009 15:47 |
Bertram Kopf
Messages: 110
Registered: March 2006
|
continuous participant |
From: *ep1.ruhr-uni-bochum.de
|
|
Hi Ola and all others,
| Aleksandra Wronska wrote on Tue, 17 February 2009 14:00 |
as for Mohammad's point 4, indeed, one of my classes inherits from one of the stt classes, namely SttRecoHit. I want to use exactly the same code, so I saw no point doing copy&paste. Some time ago I suggested to create a bit more general class in another directory, e.g. in recotasks, such, that both stt and dch can make use of it without being dependent on each other. As this has never been done, either dch package must depend on stt or I duplicate the code of SttRecoHit and WirepointHitPolicy. I also find both solutions unsatisfactory. Any suggestions?
|
I fully agree with you: it would be good to have a more general (abstract) class for this purpose. And this is not only related to the Stt and Dch. I think that also some other classes of the remaining dectoctor parts need to make use of exactly the same code or of just a few modifications. Therefore it is the best solution to define such a general class in the sense that the relevant detector specific classes inherit from this general object. Another advantage of such a structure is that everything is defined only at "one" place which makes it easier to modify and to maintain the code. In my point of view it would make sense to discuss such a design issue within the tracking core group.
In this context I have another remark to Mohammad's point 3. I took a look into the pndbase directory and I am surprised that this base directory contains only detector specific data classes. I my point of view a base directory should only contain "base classes", i.e. abstract classes or classes without (more or less ) any dependencies, which can be used everywhere. An example would be a general RecoHit class as suggested by Ola. The dectector specific data classes should be defined in directories which are at least one layer below.
Best regards,
Bertram.
|
|
|
|
|
|
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7903 is a reply to message #7901] |
Tue, 17 February 2009 17:03 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi all,
the WirepointHitPolicy has never been put into genfit as a general class because as it is written it is not so general, in fact it works only with a particular plane orientation in space, i.e. (see also the attached slides from Cracow presentation by Susanna) the plane must have one axis along the wire...
If we assume that all wire detectors use this kind of plane, we can move the WirepointHitPolicy from the stt/sttreco directory to genfit.
Concerning the PndSttRecoHit, the main problem I see is that if we have this reco hit class in common with the dch our changes might affect the dch results (for example, in our last commit we changed the origin of the detector plane, and I' m not sure that this would not cause any problem for the dch...). Would it be so wrong to write two different recohits, which are not connected?
Regards,
Lia.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7908 is a reply to message #7905] |
Tue, 17 February 2009 18:31 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Bertram,
I attach here a scheme which explains from which classes the reco hit and hit policy classes inherit (this contains specific references to STT classes).
The abstract class for the reco hit already exists (AbsRecoHit) and then, for the different kinds of hits (i.e. 3D hits, for example for tpc, or planar hits, for example for mvd) the SpacepointHitPolicy and the PlanarHitPolicy specialized the generic hit to the desired type.
When we inserted the STT, we just added the WirepointHitPolicy in order to handle our particular hit, which is a 3D hit that can' t be described by x,y,z coordinates, but is better described by a wire and the distance from that wire.
So I don' t think we need one more level, but the generic class for the wire detector (to be moved to genfit) could be the WirepointHitPolicy (with the warning already mentioned about the plane orientation).
Regards,
Lia.
-
Attachment: scheme.jpg
(Size: 103.38KB, Downloaded 437 times)
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7916 is a reply to message #7911] |
Wed, 18 February 2009 16:37 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Bertram and hi all,
I tried moving the WirepointHitPolicy from stt/sttreco to genfit. By doing this, the policy class would be in common between the stt and the dch.
Concerning the reco hits, two separate reco hits, specific for stt and dch, should be implemented. I understand the point about avoiding code duplication, and I know that there could still be a "problem" about the two detPlane(AbsRecoHit* hit, AbsTrackRep* rep) functions. They will be similar, but actually they will not be exactly the same, because in stt we have the 0.5 cm check (not needed in dch) and the origin of the frame is placed in the center of the wire (I' m not sure about the dch choice).
In any case, I cannot imagine how to move this to the WirepointHitPolicy (and so in genfit) since as far as I know the genfit package should be independent from geane and in the detPlane(...) function we use it.
Moreover this function is explicitly implemented for GeaneTrackRep, because in the stt case we did not use LSLTrackRep, and this adds a dependence of genfit on the trackrep package...
Do you think this could be a solution?
Regards,
Lia.
|
|
|
|
| Re: Closing SVN access on Wednesday 11 February 2009 [message #7928 is a reply to message #7916] |
Thu, 19 February 2009 18:14 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi,
since it seems that no particular objection to the last proposed solution arised, I moved the WirepointHitPolicy to genfit, in order to make it usable also by dch detector without unwanted cross dependences.
I tested it with the stt and it works; please, Ola tell me if you find any problem with the dch.
Best regards,
Lia.
|
|
|
|
Goto Forum:
Current Time: Wed Dec 04 22:17:48 CET 2024
Total time taken to generate the page: 0.01033 seconds
|
GSI Forum
Search
Help
Members
Login
Home
