GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » CBM » CBMROOT » General » Release DEC08
Release DEC08 [message #7590] Mon, 01 December 2008 16:11 Go to next message
Volker Friese is currently offline  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 Go to previous messageGo to next message
Volker Friese is currently offline  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 Go to previous messageGo to next message
Volker Friese is currently offline  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

Release DEC08: MUCH [message #7617 is a reply to message #7590] Wed, 10 December 2008 20:12 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *gsi.de
According to the discussion in the CBM Software Meeting, 4 December 2008, the MUCh software in DEC08 will equal that of APR08, with the following exceptions:

  • The following classes were updated w.r.t LIT tracking and will be taken from trunk:
    • CbmMuchHit
    • CbmMuchMatchTracks
    • CbmMuchTrack
    • CbmMuchTrackFinder
    • CbmMuchTrackFinderideal
    • CbmMuchTrackMatch
  • The digitisation parameters for the standard and the compact geometry will be taken from A. Kiseleva, see discussion in MUCH forum
  • A new version of CbmMuchSegmentation, worked on by D. Dutta, is being tested by A. Kiseleva and might enter the release.

Release branch DEC08 created [message #7620 is a reply to message #7590] Wed, 10 December 2008 23:05 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *gsi.de
The release branch DEC08 was created. You can check it out by

svn co https://subversion.gsi.de/fairroot/cbmroot/release/DEC08


The release corresponds to trunk (and fairbase) revision 4139. An exception is the much directory (see posting above).

Please test and report.
icon8.gif  First bug: compilation error in MUCH (E. Litvinenko) [message #7621 is a reply to message #7590] Thu, 11 December 2008 17:51 Go to previous messageGo to next message
Volker Friese is currently offline  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

icon14.gif  CbmMuchHit backdated [message #7622 is a reply to message #7621] Thu, 11 December 2008 17:53 Go to previous messageGo to next message
Volker Friese is currently offline  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

Reconstruction macro: no STS tracks found (A. Maevskaya) [message #7623 is a reply to message #7590] Thu, 11 December 2008 18:00 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *dip.t-dialin.net
Dear Volker,

i installed your branch this morning and tryed to run macro/run/run_sim.C
and run_reco.C . run_sim.C worked as always, but run_reco did not find any
track!

Log file is in attachment....

Best regards
Alla
  • Attachment: reco.log
    (Size: 13.88KB, Downloaded 419 times)
Re: Reconstruction macro: no STS tracks found (A. Maevskaya) [message #7624 is a reply to message #7623] Thu, 11 December 2008 18:02 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *dip.t-dialin.net
Hmmm...thanks for the notice; I will have a look.

Since everything except much is taken from trunk: I wonder why it worked in the trunk version. Did you check?
Re: Release DEC08 [message #7625 is a reply to message #7590] Fri, 12 December 2008 08:18 Go to previous messageGo to next message
Florian Uhlig is currently offline  Florian Uhlig
Messages: 424
Registered: May 2007
first-grade participant
From: *gsi.de
Hello Volker

In the run.C macro there wer still old geometries which results in a crash of the macro. I corrected this and now it works.
But i realized thet we have a problem with the "new" magnet geometrie and the sts_allstrips_full geometrie. Using this two
together results in illegal overlaps of parts of the last STS station and the magnet.
Since we normaly only check the standars setup, every user who uses differnt setups should check the geometry for overlaps.

Ciao

Florian
STS geometries [message #7626 is a reply to message #7625] Fri, 12 December 2008 13:40 Go to previous messageGo to next message
Volker Friese is currently offline  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 Go to previous messageGo to next message
Volker Friese is currently offline  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 Confused (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

icon14.gif  ...fixed [message #7634 is a reply to message #7627] Tue, 16 December 2008 12:14 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *gsi.de
The problem with CbmRootManager was fixed. The revision of the externals for release DEC08 was reset to 4163. Things should work now properly. I tested run_sim.C and run_reco.C and saw nothing unusual.

B.t.w.: The reason why the TofHitProducer worked was that it used the method CbmRootmanager::ActivateBranch instead of CbmRootManager::GetObject.
ECAL directory updated [message #7646 is a reply to message #7620] Thu, 18 December 2008 12:55 Go to previous messageGo to next message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *gsi.de
The ecal directory in the release branch was updated to the trunk revision 4169 in order to take into account last-minute changes by Mikhail Prokudin which are necessary for the production to come. This concerns the changesets 4156, 4157, 4159, 4160, and 4169.

[Updated on: Thu, 18 December 2008 12:56]

Report message to a moderator

Release DEC08: Wiki page [message #8171 is a reply to message #7590] Thu, 02 April 2009 18:50 Go to previous message
Volker Friese is currently offline  Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM
first-grade participant
From: *gsi.de
Finally, I set up a Wiki page with instructions how to use and install the DEC08 release. Please have a look and update it w.r.t. the section "New features" and "Known bugs and deficiencies":

DEC08 release Wiki page
Previous Topic: Mass production DEC08 with full ECAL
Next Topic: New safety feature
Goto Forum:
  


Current Time: Sat Oct 05 17:48:26 CEST 2024

Total time taken to generate the page: 0.00836 seconds