GSI Forum: General » CBMROOT Release AUG07

Home » CBM » CBMROOT » General » CBMROOT Release AUG07

Show: Today's Messages :: Polls :: Message Navigator

CBMROOT Release AUG07 [message #5035]

Wed, 12 September 2007 19:05

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *gsi.de

This topic is devoted to the release AUG07 of cbmroot. Please report any problems during installation and running, as well as wishes for improvements.

The release corresponds to the SVN revision 1394 with minor fixes. For more information, see the release's Wiki page http://cbm-wiki.gsi.de/cgi-bin/view/CbmRoot/CbmrootReleaseAug07.

[Updated on: Thu, 10 January 2008 22:15]

Report message to a moderator

Correction: Still "old" TOF hit producer in the release [message #5048 is a reply to message #5035]

Mon, 17 September 2007 16:24

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *gsi.de

Contrary to the announcement, the new TOF hit producer is not yet in the repository, thus it is not part of the AUG07 release. See Diego's mail below.

Sorry for the misunderstanding.

Dear Volker,

I have to apologize because the latest version of the HitProducer is
not yet in subversion. There are three reasons for it, while the main
one is my lack of time in the last months, in view of our incoming
HADES-RPC commisioning (strictly speaking, 'half commisioning'):

1) I wanted to implement before-hand your classes for providing
random access to my CBMTofPoint. The previous version of the HitProducer
(done in 'my way') I could have been included in subversion, but I do
not expect any significative change for most of the simulations
currently ongoing, and I did not have the time to optimize the cuts for
secondary production. Only simulations that strongly rely on the shape
of the Tof response could suffer (prominently, fluctuation studies, I
think). Moreover, the secondary production is highly dependent on the
detector structure and chosen energy cuts and engines... that are by no
means optimized taking this very effect into account, so first results
could also be highly misleading.

2) Even if it is hard to believe, the new TofHitProducer provides
just the structure for properly dealing with secondaries. The second
part of the algorithm (as mentioned above) is related to the production
of secondaries themselves. Of those, according to the current studies we
did, delta-ray production and hadronic interactions are the dominant
(and probably the only relevant) secondary processes. Optimization of
the corresponding cuts/engines must be done.

3) I could not compare my results with FOPI data yet, due to some
problems they had up to now.

D. Gonzalez-Diaz

Report message to a moderator

MC data production report [message #5059 is a reply to message #5035]

Wed, 19 September 2007 12:32

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *dip.t-dialin.net

Short report on MC data production with AUG07:

CBMROOT release AUG07 under Debian3.1
Setup: Standard geometry with RICH and fast ECAL (run macro attached)
Input: UrQMD, central Au+Au, 25 AGeV
Jobs: 200 with 500 events each

Finshed successfully: 125 (62.5 %)
Terminated with floating point exception: 64 (32 %)
Terminated with hardware problems: 11 (5.5%)

The FPE problem as discussed in this forum is unfortunately still present.

Hardware problems were:

4 Jobs entered the status UNKNWN (lxb113)
3 Jobs did not terminate at all (lxb038)
4 Jobs terminated due to lack of disc space on the local /tmp (lxb031)

Attachment: run_sim.C
(Size: 7.15KB, Downloaded 294 times)

[Updated on: Wed, 19 September 2007 12:35]

Report message to a moderator

MC data productions [message #5064 is a reply to message #5035]

Sun, 23 September 2007 22:36

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *dip.t-dialin.net

Three batches of MC data with cbmroot release AUG07 were produced.

1. Debian3.1, cbmroot built with cmake
Location: /d/cbm04/mc/AUG07/urqmd/auau/25gev/centr
127 files, 500 events/file, 63,500 events

2. Debian3.1, abmroot built with autotools
Location: /d/cbm04/mc/AUG07_auto/urqmd/auau/25gev/centr
134 files, 500 events/file, 67,000 events

3. Debian64, cbmroot built with cmake
Location: /d/cbm04/mc/AUG07_d64/urqmd/auau/25gev/centr
200 files, 500 events/file, 100,000 events

Please check and compare the files. While we do not expect changes between autotools and cmake, we have to verify that the results obtained on a 64 bit architecture are consistent with those on the standard Linux. One difference is already obvious: The output file size under Debian3.1 is 1.1 GB, while under Debian64 it is only 788 MB.

Thre reason why the productions with Debian3.1 are incomplete is the FPE problem in GEANT3 as discussed in another topic of this forum.

[Updated on: Mon, 01 October 2007 15:26]

Report message to a moderator

Re: MC data productions [message #5134 is a reply to message #5064]

Mon, 01 October 2007 17:13

Claudia Höhne
Messages: 16
Registered: May 2004
Location: GSI, Darmstadt

occasional visitor

From: *gsi.de

Dear colleagues,

first results of a test of the AUG07 MC data production concerning RICH, see also http://cbm-wiki.gsi.de/cgi-bin/view/CbmRoot/CbmSoft071004:

* RICH data in AUG07 MC data production

o data from MC production "AUG07" (Debian3.1, cbmroot built with cmake) and "AUG07_auto" (Debian3.1, cbmroot built with autotools) look normal, see result of test macro CbmRichTestSim:
+ urqmd.auau.25gev.centr_1000ev_AUG07.ps
+ urqmd.auau.25gev.centr_1000ev_AUG07_auto.ps

o data from MC production "AUG07_d64" (Debian64, cbmroot built with cmake) look strange, something is going wrong with the Cherenkov photons:
+ urqmd.auau.25gev.centr_1000ev_AUG07_d64.ps
+ their number per electron is reduced by a factor 5-6
+ rings are not well projected onto the photodetector plane but points scatter wildly

Best regards,
Claudia

Attachment: urqmd.auau.25gev.centr_1000ev_AUG07.ps
(Size: 962.43KB, Downloaded 314 times)
Attachment: urqmd.auau.25gev.centr_1000ev_AUG07_auto.ps
(Size: 962.44KB, Downloaded 292 times)
Attachment: urqmd.auau.25gev.centr_1000ev_AUG07_d64.ps
(Size: 761.84KB, Downloaded 295 times)

Report message to a moderator

Re: MC data productions [message #5155 is a reply to message #5064]

Wed, 03 October 2007 12:31

Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI

continuous participant

From: *gsi.de

I checked the STS and MVD and no difference is seen between AUG07 and AUG07_auto
at all. AUG07_d64 shows slightly smaller number of points (less than 0.5% difference),
but reconstruction works very good for all the three productions.

I have however loaded the files to root and simply did cbmsim->Print().

Part of the printout for AUG07:

*....................................................................... .....*
*Br 33 :STSPoint : cbmroot.STS.STSPoint_ *
*Entries : 500 : Total Size= 244881 bytes One basket in memory *
*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
*....................................................................... .....*

and for AUG07_d64:

*....................................................................... .....*
*Br 33 :STSPoint : cbmroot.STS.STSPoint_ *
*Entries : 500 : Total Size= 244881 bytes One basket in memory *
*Baskets : 0 : Basket Size= 32000 bytes Compression= 1.00 *
*....................................................................... .....*

No difference whatsoever is seen for all of the detectors, EXCEPT............

........

........

........

........

(is it next page yet?)

........

........

........

........

R I C H, where all branches differ significantly,

and for example show for AUG07:

*....................................................................... .....*
*Br 54 :RichPoint.fUniqueID : fUniqueID[cbmroot.Rich.RichPoint_] *
*Entries : 500 : Total Size= 31814552 bytes File Size = 202784 *
*Baskets : 500 : Basket Size= 32000 bytes Compression= 156.83 *
*....................................................................... .....*

and for AUG07_d64:

*....................................................................... .....*
*Br 54 :RichPoint.fUniqueID : fUniqueID[cbmroot.Rich.RichPoint_] *
*Entries : 500 : Total Size= 7168952 bytes File Size = 67954 *
*Baskets : 277 : Basket Size= 32000 bytes Compression= 105.18 *
*....................................................................... .....*

I don't know what the difference might be, as I am not the expert.
All the branches however show dicrease of Total Size by about 70%.

Report message to a moderator

MC data production AUG07 [message #5252 is a reply to message #5035]

Thu, 18 October 2007 15:29

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *gsi.de

Production of MC data (UrQMD input) for AUG07 is now completed. For each of the three beam momenta 15 AGeV, 25 AGeV and 35 AGeV, 100,00 central Au+Au events and 200,000 minimum bias Au+Au events have been transported through the standard electron setup MVD + STS + RICH + TRD + TOF + ECAL (fastMC).

The production has been done with Debian3.1 (Sarge) on 32 bit.

In addition, 10,000 central Au+Au events at 25 AGeV have been transported with the full ECAL MC.

Please find more details on the data production in the Wiki pages for the standard simulation and the simulation with full ECAL .

[Updated on: Thu, 18 October 2007 15:32]

Report message to a moderator

Re: MC data productions [message #5304 is a reply to message #5134]

Wed, 24 October 2007 12:00

Florian Uhlig
Messages: 424
Registered: May 2007

first-grade participant

From: *gsi.de

I looked into the problem with the cherenkov photons on 64bit machines.
As reported in the Software Meeting on 18.10.07 with the newest version of TGeant3 the problem disappeared and the control spectra look normal (see test.mc.RichTestSim.newgeant3.ps)

Checking the changes in the Geant3 code between the two versions there was only no change in the code which could explain the difference between the two Geant3 versions, but there was also a
change in the Makefile for x86_64. In the new Makefile there is a new compiler option "-fno-f2c".

Compiling the old Geant3 code with this additional option also for the old code the Rich control spectra look normal (see test.mc.RichTestSim.oldgeant3.newflag.ps)

According to the information of the g77 manpage normally all code generated by g77 is compatible with code generated with f2c. using "-fno-f2c" the generated code is not compatible with code generated by f2c but uses the GNU calling conventions instead.
This mainly effects the return values

>>The f2c calling conventions require functions that return
>>type "REAL(KIND=1)" to actually return the C type "double",
>>and functions that return type "COMPLEX" to return the
>>values via an extra argument in the calling sequence that
>>points to where to store the return value.

>>Under the GNU calling conventions, such functions simply
>>return their results as they would in GNU C---"REAL(KIND=1)"
>>functions return the C type "float", and "COMPLEX" functions
>>return the GNU C type "complex" (or its "struct" equivalent).

>>Caution: If -fno-f2c is used when compiling any source file
>>used in a program, it must be used when compiling all
>>Fortran source files used in that program.

Since TGeant3 is mostly an interface from C++ to the old fortran routines this differences can explain the observed effect. Why this effect is only seen with cherenkov photons i don't know.

As a summary i would say the problem is solved and partly understood.

On /misc/cbmsoft/Debian64/new i will use the old Geant3 version with the new compiler flag, to have consistent versions of the different libraries on 32 and 64bit.

Attachment: test.mc.RichTestSim.oldgeant3.newflag.ps
(Size: 888.23KB, Downloaded 312 times)
Attachment: test.mc.RichTestSim.newgeant3.ps
(Size: 809.37KB, Downloaded 331 times)

Report message to a moderator

Bug fix [message #5354 is a reply to message #5252]

Fri, 02 November 2007 15:58

Volker Friese
Messages: 365
Registered: April 2004
Location: GSI CBM

first-grade participant

From: *gsi.de

There was an inconsistency in the simulation macro used for the MC production, which E. Litvinenko discovered. The magnetic field map FieldMuonMagnet was used, but for the magnet geometry, magnet_active.geo was loaded.

The bug was fixed; now magnet_muon.geo is used in run_sim.C. The production of all data sets was redone. If you already used the data before October 27 for analysis, it would be better to rerun.

Report message to a moderator

Previous Topic:	New release of external packages
Next Topic:	New External packages

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Thu Apr 18 21:04:46 CEST 2024

Total time taken to generate the page: 0.00831 seconds