| Release DEC08 [message #7590] |
Mon, 01 December 2008 16:11  |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
We intend to release a version of CBMROOT with the tag DEC08. This topic is meant for the discussion of the preparations for this release. If you have some wishes to be implemented before the release, or noticed some deficiencies you consider necessary to be taken care of, please report here.
[Updated on: Wed, 10 December 2008 23:05] Report message to a moderator |
|
|
|
| Release DEC08: Geometries [message #7591 is a reply to message #7590] |
Mon, 01 December 2008 16:43  |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
For the release DEC08, it seems desirable to clean up the geometry directory and remove obsolete geometry files. I try to summarise the current situation, together with some proposals.
- MVD: There a two geometry versions, one with two stations (standard) and the other one with three stations. The material budget is 150 mum per station.
In the light of our nowadays knowledge on MAPS, I think a more realistic material budget should be used.
- STS: The current standard is 2 pixel + 6 strip stations, which is by now obsolete. The STS group decided to make the 8 strip version the new standard (former: sts_allstrips.geo). We will keep the old one as reference for the next release (sts_hybrid.geo). Both versions are available with additional material for readout and support. Since the implementation of this is rather tentative, and a better one will be available soon, we will leave the passive material still out for the standard geometry.
- RICH: The compact RICH version has been validated sufficiently to make it the new standard. The old one will be kept as reference (rich_large.geo). The files rich.geo, rich_He+CH4.geo, rich_L2900-N2-angleM0-angleD0.geo, rich_N2+CH4.geo, and rich_N2.geo are considered obsolete and will be removed.
- MUCH: No changes for the available two geometry versions (standard: full system, for charmonium; compact: without last absorber, for low-mass dimuons.)
- TRD: There are many geometry files in the repository. The TRD group is requested to identify the relevant ones and remove all others.
- TOF: The standard did not change (since two years, by the way.) There is an additonal file named tof_010906.geo. I shall ask the TOF group to qualify this geometry in a better way, or remove it.
- ECAL: The two file ecal_FullMC.gei and ECAL_FastMC.geo have also not changed ovet two years. Is the new geometry presented at the recent collaboration meeting mature enough to be put into the repository?
- PSD: There is no .geo file; the PSD geometry is created in the code.
- Magnet: The magnet_muon.geo has become the standard. This should be reflected in a new file name (magnet_standard.geo). All other magnet geometries are by now obsolete and should be removed.
- Pipe: Of the many geometry files in the repository, three should remain: pipe_rich_standard.geo (compatible with rich_standard), pipe_rich_large.geo (compatible with rich_large), and pipe_much.geo (compatible with MUCH). All other versions should disappear.
[*} Pipe shielding: The two versions corresponding to much_standard and much_compact will stay as they are.
- Target: We only have one target geometry (250 mum Au). Do we need a thinner one, too (25 mum)?
I would like to hear your opinions.
|
|
|
|
| Release DEC08: Standard geometry? [message #7593 is a reply to message #7590] |
Tue, 02 December 2008 09:51 |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
Peter Senger recently criticised the concept of a "standard" geometry. Thus, I would like to trigger a discussion whether you consider this concept useful. I see the following pros and cons:
+ The user knows which default geometry to take for each subsystem, without having to know the details. This is the prime motivation for having a standard geometry at all.
- A "standard" is not well defined - at least, we have different geometries in the electron and muon setups.
- The standard geometry may change from release to release (e.g. STS switches from "hybrid (pixel+strips) to "allstrips"), without that being transparent for the user, as the file name stays the same.
What is your opinion?
[Updated on: Tue, 02 December 2008 09:53] Report message to a moderator |
|
|
|
|
|
|
|
 First bug: compilation error in MUCH (E. Litvinenko) [message #7621 is a reply to message #7590] |
Thu, 11 December 2008 17:51 |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Volker,
The fresh "DEC08" download resulted in the following error during
compilation:
[[ 47%] Generating CbmMuchDict.cxx, CbmMuchDict.h
Error: cannot open file "CbmMuchGeoScheme.h"
/u/litvinen/DEC08/much/CbmMuchHit.h:22:
Warning: Error occurred during reading source files
Warning: Error occurred during dictionary source generation
!!!Removing /u/litvinen/DEC08/build/much/CbmMuchDict.cxx
/u/litvinen/DEC08/build/much/CbmMuchDict.h !!!
Error: /misc/cbmsoft/Debian3.1/jul08/fairsoft/tools/root/bin/rootcint:
error loading headers...
Probably, not all files were commited to svn after the latest changes.
Regards,
Elena Litvinenko
[Updated on: Thu, 11 December 2008 17:54] Report message to a moderator |
|
|
|
 CbmMuchHit backdated [message #7622 is a reply to message #7621] |
Thu, 11 December 2008 17:53 |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *dip.t-dialin.net
|
|
You are right. CbmMuchHit in trunk uses CbmMuchGeoScheme, which is not included in this release. So, the class was backdated to release APR08. Compilation should now work.
Sorry for not noticing this before.
[Updated on: Thu, 11 December 2008 17:55] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| STS geometries [message #7626 is a reply to message #7625] |
Fri, 12 December 2008 13:40 |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
In the release branch, there are up to now the old STS geometries "standard" and "allstrips". According to the decision of the STS group (see forum), the allstrips geometry should be the new standard. I changed that accordingly. The old standard (2 pixel + 6 strip stations) was renamed to "sts_hybrid.geo" and "sts_hybrid_full.geo", respectively.
This, of course, does not remove the problem with the overlap of magnet geometry and (now) sts_standard_full.geo, which we still have to resolve.
[Updated on: Fri, 12 December 2008 13:43] Report message to a moderator |
|
|
|
| Problem with CbmRootManager [message #7627 is a reply to message #7623] |
Fri, 12 December 2008 15:34 |
Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
|
first-grade participant |
From: *gsi.de
|
|
I tracked the problem described above to the CbmStsDigitise task. It seems not to see any CbmStsPoints, although the array STSPoints is there:
+ STSDigitize : 0.0001 s, points 0, failed 0, outside 0, multihits 0, digis 0
I notice that there was a change in CbmRootManager three days ago (one day before the release branch was created  (see SVN trac). So, I tried to use the version of CbmRootManager from APR08, and that works:
+ STSDigitize : 0.0733 s, points 6711, failed 0, outside 0, multihits 247, digis 13153
The change in CbmRootManager looks rather harmless; no idea why it screws up things.
The same thing seems to happen with MVD (CbmMvdHitProducer does not see MVDPoints), but, strangely enough, not to TOF (CbmTofHitProducer works in bose cases).
[Updated on: Fri, 12 December 2008 15:36] Report message to a moderator |
|
|
|
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
