Linear Collider Forum



Today's Messages (off)  | Unanswered Messages (on)

Forum: Marlin et al
 Topic: multiple LCCD callbacks to one processor
multiple LCCD callbacks to one processor [message #1766] Mon, 15 June 2009 02:47
blutz
Messages: 4
Registered: January 2009
Location: Hamburg
Dear ILCsoft-team,

working with LCCD I stumbled over following question:

What is the design-way of distinguishing the collections in the LCCD callbacks.

Most of the time the processor has to know not only that any condition has changed but also which.

In <lccd::IConditionsChangeListener>
void conditionsChanged (lcio::LCCollection *col)

is defined. I get a pointer to the collection that changed. But in <EVENT/LCCollection.h> there is no function defined that allows to query the name of the collection in the stream.

As long as I have collections of different types I could practically distinguish the collection via the
getTypeName()
function. For LCCD-Objects this will always be LCGenericObject. Which then leaves to look into the parameters for the actual type of the LCGenericObjects.

But all this will brake down, when one has two collections of the same type.

We have a way of redirecting the callback to specialised functions in CALICE, but I would prefer to get to the original information which collection this is.

Is there a way to retrieve the collection name, as it is in the LCIO-stream when one listens on the callback?

Cheers, Beni

[Updated on: Mon, 15 June 2009 02:50]

 Topic: Charge transfer coefficient calculations in the GEMProcessor
question.gif  Charge transfer coefficient calculations in the GEMProcessor [message #1746] Fri, 29 May 2009 06:16
bakul
Messages: 1
Registered: January 2009
Location: University of Siegen, Ger...
Hello,

I have a question about GEM simulation in MarlinTPC (GEMProcessor). Please, correct me if I am wrong, I am assuming that libgem.cc (MarlinTPC/trunk/digitisation/src/libgem.cc) does all the calculations of the charge transfer coefficients. The code for electron extraction efficiency calculation starts with the following ‘if’ condition (line 64):
if  ( ( field / holefield( gemvoltage, 0, 0 ) - PAR_y_eext ) <= pow( PAR_r_eext, (1/PAR_s_eext) ) )

Is that condition correct? Is it required to subtract the parameter ‘y’ from the field ratio before that comparison? According to the published papers from Martin Killenberg, et al., the condition should be: E_ext/E_hole <= r^1/s. If the value of ‘PAR_y_eext’ is zero, it doesn’t matter, but in case of some gas-mixtures, the parameter files (MarlinTPC/trunk/simulation/inputs/) have a non-zero values of this parameter. Wouldn’t that affect the results?
Another thing I don’t understand is the reason for setting the external fields to zero when computing the hole field. I notice, almost everywhere the function ‘holefield’ is called with the last two parameters as zero: holefield( gemvoltage, 0, 0 )
Why is it like that?

Thanks,
Bakul.


Bakul Gaur
University of Siegen
 Topic: Fitting and using histograms inside a processor
Fitting and using histograms inside a processor [message #1738] Fri, 08 May 2009 06:35
oschaefer
Messages: 23
Registered: September 2007
Location: University of Rostock / D...
Dear all,

I'm currently reviewing some of my processors and there's one where I calculate correction factors from my data.

The idea itself is quite simple: generate a histogram of charge for each channel, determine the mean value (or some other characteristic point in the charge distribution) for every channel and then calculate calibration factors for the conditions data that will adjust the channels characteristic points to a common one.

As my raw data so far was just integers I could do this "histogramming" in an IntVec. Also calculating the mean value is quite simple. If however I want to move to real histograms (say for floats and binning of my desire), maybe with fitting functionality or so, what is recommended there? AIDA, I think, is only for output purposes, isn't it?
 Topic: CEDViewer: HCalRingParameters Not Found.
CEDViewer: HCalRingParameters Not Found. [message #1638] Fri, 28 November 2008 10:57
fengy
Messages: 15
Registered: September 2008
Location: IU
About the CEDViewer:

If I enable the CEDViewer processor, Marlin will die after throwing an exception:

HcalRingParameters Not found.

It seems like CEDViewer requires a HcalRing subdetector.

Anyways I am using the default D09 detector model, and I am wondering if I need to manually add a HcalRing to make CEDViewer happy, and what format should the subdetector be?


Thanks,

Yu
 Topic: new ilcsoft release v01-05-02
new ilcsoft release v01-05-02 [message #1635] Fri, 28 November 2008 10:49
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new test release of ilcsoft has been tagged: v01-05-02.

It contains the latest versions of

MalinReco v00-13
PandoraPFA v03-00
StdConfig v01-00

that are needed to run full reconstruction on the ILD_00 that are currently under production.


knwon issues:
- LCFI flavour tag nets has not yet been updated to ILD_00
- no major testing of reconstruction yet...

-Frank.

 Topic: ilcsoft release v01-04
ilcsoft release v01-04 [message #1555] Fri, 25 July 2008 09:25
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Dear all,

a new version of ilcsoft v01-04 has been released. This version is foreseen to be used for reconstruction of the large Monte Carlo Data samples produced for the LOI.

It contains all the patches for release v01-03-06 and a few additional improvements.

Please use the following link to download the ilcinstall tool with the proper configuration files to install v01-04:
ilcinstall-v01-04

The file releases/release-v01-04-scratch.cfg can be used to install the complete release from scratch - w/o pointers to the afs reference installations at DESY.

These can be found as ususal for SL3/SL4 at:
/afs/desy.de/group/it/ilcsoft/v01-04/


Cheers, Frank.


 versions of packages in ilcsoft release v01-04:
 ===============================================
 
./lcio/v01-10-01
./CMakeModules/v01-07
./CLHEP/2.0.3.2
./gear/v00-09
./QT/4.2.2
./root/5.16.00
./CondDBMySQL/CondDBMySQL_ILC-0-5-10
./mysql/5.0.26
./cernlib/2006
./gsl/1.8
./java/1.6.0
./Marlin/v00-10-03
./StandardConfig/v00-06-00
./LCFIVertex/v00-02-07-dev
./MarlinReco/v00-10-04
./PandoraPFA/v02-03-00
./MarlinUtil/v00-11
./LCFI_SGVbasedNets/v00-01
./Mokka/mokka-06-06-p03
./SiliconDigi/v00-04-01
./MarlinTPC/v00-02-06
./RAIDA/v01-04-02
./CEDViewer/v00-06
./Overlay/v00-02
./Eutelescope/v00-00-06
./CED/v00-05
./lccd/v00-03-06
 Topic: Processor default return value
Processor default return value [message #1455] Fri, 25 April 2008 01:01
srichter
Messages: 10
Registered: January 2008
Dear Marlin users!

I use xml steerings and the <if condition> possibility. I have a processor which sets "1track(s)Found", "2track(s)Found" etc. to "true". But it is not that "1track(s)Found" is false if more than one track is found, it is just undefined.

My question is: Do undefined return values default to "false", so that I can use: <if condition="MyTrackFinder.!1track(s)Found"> ...?

Thanks in advance,

Sebastian Richter
 Topic: Gear SITModel error
Gear SITModel error [message #1453] Tue, 22 April 2008 03:36
benjaminrs
Messages: 16
Registered: October 2007
Location: Manchester
Hi all,

I am using the latest versions of all packages with the file:
http://www-flc.desy.de/simulation/databasesimulation/mcprod_ read_detail_php.php?detailrunID=M-6-5p2_uu_w11775_500_LDC01_ 05Sc_LCP_ep%2B0.0_em%2B0.0_Test_500

but then the following error occurs when trying to run Marlin:
<!-- Loading shared library : /afs/hep.man.ac.uk/g/ilc/SL4/Processors/marlinexample1/lib/libmymarlin.so -->
[ MESSAGE "Marlin"]  ---- instantiated  GEAR from file  /tmp/BenjaminTmp/M-6-5p2_uu_w11775_500_LDC01_05Sc_LCP_ep+0.0_em+0.0_Test_500_0001/GearOutput.xml
[ MESSAGE "Marlin"]  -----------------------------------------------------
[ MESSAGE "Marlin"]               GearMgr :
[ MESSAGE "Marlin"]  -----------------------------------------------------
[ MESSAGE "Marlin"]

.
.
.


[ MESSAGE "Marlin"]
[ MESSAGE "MyMaterialDB"]
[ MESSAGE "MyMaterialDB"] ---- MyMaterialDB -  parameters:
[ MESSAGE "MyMaterialDB"]       UseExtrapolations:  1
[ MESSAGE "MyMaterialDB"]       UseMaterials:  1
[ MESSAGE "MyMaterialDB"] -------------------------------------------------
 A runtime error has occured : gear::UnknownParameterException: SITModel
 the program will have to be terminated - sorry.


Does anyone have any ideas? I found a post on here from Fab:
http://forum.linearcollider.org/index.php?t=msg&th=503&a mp;rid=0&S=49be37b9370e2f4b5a5cc586e2c1a715#msg_1277
Where the same type of error was thrown up - but i am using the latest versions of gear/marlin et al.

Thanks,
Benjamin


  • Attachment: install.cfg
    (Size: 4.45KB, Downloaded 1446 times)
 Topic: new ilcsoft patch release v01-03-03
new ilcsoft patch release v01-03-03 [message #1424] Tue, 18 March 2008 03:03
aplin
Messages: 24
Registered: March 2004
Location: DESY, Hamburg


A new patch release for the ilcsoft tools v01-03-03 has been released.

It includes:

MarlinReco
-----------
| v00-05-03 |
-----------

bug fix release

* TrackDigi/TPCDigi/TPCDigiProcessor: (S.Aplin)
- fixed several memory leaks

* Tracking/SiliconTracking/include/MaterialDB (A.Raspereza)
- added support structures for SIT
- included treatment of the first layer of heavy-weight Si for FTD
detector


Mokka
-----------------------
| mokka-06-06-pre02 |
-----------------------

including the new HCAL and Silicon Drivers


See below for the tools and their versions.

Reference installations for SL3 and SL4 are at the usual place:

/afs/desy.de/group/it/ilcsoft/v01-03-03

Please use ilcinstall v01-03-03 to install the release at your institute.


Jan and Steve


CED/v00-03:
CEDViewer/v00-04:
CLHEP/2.0.3.1:
CMakeModules/v01-05:
CondDBMySQL/CondDBMySQL_ILC-0-5-10:
Eutelescope/v00-00-06:
LCFIVertex/v00-02-02:
Marlin/v00-09-10:
MarlinReco/v00-05-03:
MarlinUtil/v00-06:
Mokka/mokka-06-06-pre02:
Overlay/v00-02:
PandoraPFA/v02-00-01:
QT/4.2.2:
RAIDA/v01-03:
SiliconDigi/v00-04:
cernlib/2006:
gear/v00-08:
gsl/1.8:
java/1.6.0:
lccd/v00-03-06:
lcio/v01-09:
mysql/5.0.26:
root/5.16.00:
 Topic: Time Pix Reader
Time Pix Reader [message #1401] Thu, 14 February 2008 05:16
simone
Messages: 6
Registered: September 2007
Location: Uni Bonn
Hi,

I wrote a processor that converts TimePix data to LCIO for which I used the StdHepReader as a template. I would like to run this proceesor in the same processor chain as all the reconstruction proecssors.
Problems occur, if I initialize a ConditionsMap in init() of one of the following processors, since the collection containing the conditionsdata is written after init() is called.

Does anybody have any suggestions on how to solve this problem?

The processor can be found at:
svn://pi.physik.uni-bonn.de/MarlinTPC/branches/simone/tools/ processors/src/TimePixReaderProcessor.cc
and
svn://pi.physik.uni-bonn.de/MarlinTPC/branches/simone/tools/ processors/include/TimePixReaderProcessor.h

Thank's
Simone
 Topic: Posting new Messages
idea.gif  Posting new Messages [message #1344] Thu, 17 January 2008 02:21
engels
Messages: 106
Registered: August 2006
A note to everybody posting new messages in this thread related to ilcinstall errors:

If possible please attach (or paste) a copy of the configuration file in the message and the output of 'lsb_release -a'.

This will make our lives much easier.

Thanks,
Jan

P.S. and please use the latest tagged version of ilcinstall (currently v01-03) available at:
http://www-zeuthen.desy.de/lc-cgi-bin/cvsweb.cgi/ilcinstall/ ?cvsroot=ilctools

[Updated on: Thu, 17 January 2008 05:37]

 Topic: no TPC hits
no TPC hits [message #1340] Fri, 11 January 2008 06:50
harderk
Messages: 42
Registered: March 2004
Location: RAL
Hi everyone,
This is just a warning for people who are still using events simulated with LDC01_02Sc (or any other model using Mokka TPC drivers tpc04 or tpc05). The TPCDigiProcessor in MarlinReco v00-05 is not compatible with these drivers and will discard *all* TPC SimTrackerHits. If you need to use this detector model, use a newer version of TPCDigiProcessor (TrackDigi/TPCDigi/include/TPCDigiProcessor.h from revision 1.11, TrackDigi/TPCDigi/src/TPCDigiProcessor.cc from revision 1.25) and add
<parameter name="RejectCellID0" type="int">0</parameter>
to your TPCDigiProcessor parameters. Make sure to use this parameter only for LDC01_02Sc-like events!
Cheers,
Kristian
 Topic: ilcsoft release v01-03
ilcsoft release v01-03 [message #1334] Fri, 21 December 2007 09:36
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new version of the ilcsoft tools v01-03 has been released.

See below for the tools and their versions.

A big thanks to everyone that contributed to this effort by developing, testing, debugging and providing feedback on the software.

Reference installations for SL3 and SL4 are at the usual place:

/afs/desy.de/group/it/ilcsoft/v01-03

Please use ilcinstall v01-03 to install the release at your institute.


Merry Christmas and Happy Hollidays,

Frank


CED/v00-03
CEDViewer/v00-04
CLHEP/2.0.3.1
CMakeModules/v01-05
CondDBMySQL/CondDBMySQL_ILC-0-5-10
Eutelescope/v00-00-06
LCFIVertex/v00-02-02
Marlin/v00-09-10
MarlinReco/v00-05
MarlinUtil/v00-05
Mokka/mokka-06-05-p02
Overlay/v00-02
PandoraPFA/v02-00
QT/4.2.2
RAIDA/v01-03
SiliconDigi/v00-04
cernlib/2006
gear/v00-08
gsl/1.8
java/1.5.0
lccd/v00-03-06
lcio/v01-09
mysql/5.0.26
root/5.16.00
 Topic: PandoraPFA: missing include directive
PandoraPFA: missing include directive [message #1231] Sun, 21 October 2007 12:15
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
Hi,

the current PandoraPFA HEAD fails to compile with
/opt/ilcsoft/PandoraPFA/HEAD/src/MyPFOAnalysis.cc: In member function ‘virtual void MyPFOAnalysis::end()’:
/opt/ilcsoft/PandoraPFA/HEAD/src/MyPFOAnalysis.cc:775: error: invalid use of undefined type ‘struct TFile’

due to a missing line
#include "TFile.h"

in file MyPFOAnalysis.cc

Cheers, Peter
 Topic: wrong geometry in MokkaCaloDigi?
wrong geometry in MokkaCaloDigi? [message #1226] Wed, 17 October 2007 05:46
harderk
Messages: 42
Registered: March 2004
Location: RAL
Hello everyone,
When investigating lots of MokkaCaloDigi warnings about z coordinate mismatches of simulated and digitized calorimeter hits, I found the following piece of code within MokkaCaloDigi.cc:


if(end_module_type == 1 ) {
_regularBarrelModuleLength = 2*tpc_ecal_hcalbarrel_halfz/5.-1.;
top_end_dim_z = 1180.0;
}
else {
// the 140 and the proportions comes from Tesla TDR
float total_z_size = 140 +
2 * tpc_ecal_hcalbarrel_halfz;
_regularBarrelModuleLength = total_z_size / 5. * 1080./1120.;
top_end_dim_z =
(total_z_size - 3 * _regularBarrelModuleLength)/2;
}

There are a lot of hardcoded dimensions in there that are almost certainly wrong for many detector models. I was trying to replace them with the actual dimensions as specified in the GEAR file (or even add parameters to the GEAR file if necessary), but I cannot quite figure out what the meaning of the numbers above is. Can anyone provide some clues?

- why are we subtracting a millimeter from the regularBarrelModuleLength in the case of end_module_type==1?

- what is the meaning of the 140, 1180, 1080 and 1120 in here?
 Topic: CalorimeterHit type conventions
CalorimeterHit type conventions [message #1176] Thu, 04 October 2007 13:20
samson
Messages: 13
Registered: March 2006
Location: DESY, Hamburg
Hi,
although this topic is not a Marlin specific thing, I choose to post this topic here, because I hope to find more people involved in actual reconstruction and analysis work than in the LCIO forum.

Although, I will only refer to calorimeter hits, this post could be of interest for tracking people too, since similar problems might appear with tracker hits as well.

Since I apply a clustering algorithm to the CALICE test beam data, I was confronted with the task to recalculate the energy of a cluster. With help of the clusters "getCalorimeterHits" method, I got a list (vector) of calorimeter hits, containing ECAL and HCAL hits, which had to be treated in a different way. Since the cell id of the hits is not well suited to distinguish between the calorimeter types, the calorimeter hits type should be the value which distinguishes between the calorimeter types of the hit.

Because up to now the type of a CalorimeterHit is not filled at all, I had a look at MarlinReco/MarlinUtil and found out, that there are at least two different conventions for the calorimeter hit type, and no processor fills the mapping between numerical hit type and a string into the collection header as requested/suggested(?) by the LCIO documentation.

Because I would like to have an implementation of the calorimeter hit types in the CALICE software, witch is compatible with the conventions for calorimeter hits in "big" detectors, I would like to make the following proposal. This proposal is intended as well for prototype as for "full detector" calorimeter hits.


1) The numerical type of an calorimeter hit is "1000*<calorimeter component type> + <calorimeter component specific type>"
2) The list of numerical values for the <calorimeter component type> is
"1" for ECAL (barrel)
"2" for HCAL (barrel)
"3" for TAILCATCHER (barrel)
"11" for ECALENDCAP
"12" for HCALEDNCAP
"13" for TAILCATCHERENDCAP
"14" for BEAMCAL
"15" for LUMICAL
3) The <calorimeter component specific type> is different for each actual implementation of the calorimeter component but the scheme "10*[cell granularity in cm] + [sampling fraction index starting with 1 from the direction of the IP to the outside]"

4) The vector of numerical calorimeter hit types used in a collection is stored as collection parameter with the name "CalorimeterHitTypeValues". The corresponding vector with the stings describing the calorimeter hit type, is stored in the collection parameter "CalorimeterHitTypeNames". The strings are composed in the following way: [calorimeter component name, see list above]_[component specific string]. e.g. "HCAL_3CM_SAMPLING1".



Remarks and remaining questions
1) This conventions leaves room for 32 different calorimeter components. The splitting of the calorimeter component and the component specific type takes into account, that some users are only interested in the "calorimeter type" and others are interested in the "cell type".
2) There should be some header file (and namespace) where string constants for the literal calorimeter component types are defined. In which software package should this be?
3)Is it really necessary to store a "map" between the numerical an literal/human readable calorimeter hit types in each collection?

I would like to get some feedback on this proposal. Whether you like it or not. What to you like or dislike, and if you would implement or use a hit type with a convention like this.

Cheers, Jörgen.


 Topic: Stylesheet for Marlin XML Steering Files
Stylesheet for Marlin XML Steering Files [message #1153] Thu, 27 September 2007 12:14
vogel
Messages: 83
Registered: March 2005
Location: DESY, Hamburg, Germany
The stylesheet has been moved to http://ilcsoft.desy.de/marlin/marlin.xsl
The usage notes have been moved to http://www-flc.desy.de/ldcoptimization/software.php

Adrian

[Updated on: Fri, 27 June 2008 12:08]

 Topic: deleting histograms in RAIDA
deleting histograms in RAIDA [message #1136] Mon, 24 September 2007 07:54
simone
Messages: 6
Registered: September 2007
Location: Uni Bonn
Dear all,

I am using the root implementation of the marlin::AIDAProcessor.
During my analysis I create histograms that I don't want to save to the .root file.
Is there a proper way to delete them?
delete histoname; does not work!

Thanx for your help

Simone
 Topic: release v00-09-09
release v00-09-09 [message #1103] Thu, 13 September 2007 02:06
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new Marlin release is available it provides some bug fixes and some new features:
 -----------
| v00-09-09 |
 -----------
    - introduced EventModifier interface for modifying the LCIO input (e.g. for overlay)

    - printParameters() now on MESSAGE level - or templated: printParameters<DEBUG>() ;

    - bug fixes
	 gui: bug fixed in changing the gear file
         gui: bug fix with defining MARLIN_NO_DLL (Adrian Vogel)
         fixed documentation for streamlog
         for streamlog in templates (gcc3.2) use  streamlog_out_T( DEBUG ) 
         fixed verbosity level SILENT
         ...

   - made compatible with CLHEP versions >=1.9.3.0/2.0.3.0 (Martin Killenberg)


Frank
 Topic: advanced Marlin steering file xml capabilities?
advanced Marlin steering file xml capabilities? [message #1091] Tue, 11 September 2007 03:20
harderk
Messages: 42
Registered: March 2004
Location: RAL
Hello everyone,
With increasingly complex Marlin processor configurations I am running into bookkeeping difficulties that would easily be alleviated if Marlin had one or both of the following features
in its xml code:
- the ability to include xml files
(to include identical configurations for some processors
into different Marlin steering files)
- the ability to use symbolic constants
(to allow to take input lcio files and gear file from
same directory without having to change that directory
name in several places when using a different sample)
I didn't find anything like this in the documentation, so I guess neither is implemented, right?
Kristian
 Topic: Potential bug in ClusterCheater module of release 00-09-06
Potential bug in ClusterCheater module of release 00-09-06 [message #1005] Mon, 20 August 2007 15:10
hooberman
Messages: 13
Registered: March 2007
I have found a possible bug in both of the ClusterCheater modules (ClusterCheater and ClusterCheater5_3) included in release 00-09-06. Using ClusterCheater, I find that x,y,z,itheta, and iphi for each cluster is set to zero. For ClusterCheater5_3, I find too many clusters which when using Wolf to make ReconstructedParticles gives more RecoParticles than MCParticles. I copied the ClusterCheater module from a previous release and using that I find the problems go away. It is possible this problem has already been fixed but I thought I should bring it to someone's attention although it is possible I am doing something wrong myself.
 Topic: Prob: getting CalHits along trackPath (from track extrapolation)
icon7.gif  Prob: getting CalHits along trackPath (from track extrapolation) [message #1003] Tue, 14 August 2007 02:40
gpaylaga
Messages: 7
Registered: June 2007
Location: Philippines

my job is to extrapolate the track onto the CAL, and get the CALhits along the extrapolated track (trackpath in the CAL region).
The algo looks like this:

float phi0, z0, d0, omega, tanlambda;

phi0 = track->getPhi();
d0 = track->getD0();
omega = track->getOmega();
z0 = track->getZ0();
tanlambda = track->track->getTanLambda();

TrackerHitVec hitvec = track->track->getTrackerHits();

int nhits = (int)hitvec.size();

float * xh = new float[nhits];
float * yh = new float[nhits];
float * zh = new float[nhits];
float * ah = new float[nhits];
for (int i=0; i<nhits; ++i) {
ah[i] = 0;
xh[i] = float(hitvec[i]->getPosition()[0]);
yh[i] = float(hitvec[i]->getPosition()[1]);
zh[i] = float(hitvec[i]->getPosition()[2]);
}

ClusterShapes * shapes = new ClusterShapes(nhits, ah, xh, yh, zh);

float par[5];
float dpar[5];
float chi2;
float distmax;
int direction = (int)( (omega)/fabs(omega) );

// use canonical parametirisation (3)
shapes->FitHelix( 500, 0, 3, par, dpar, chi2, distmax, direction );
float z0_1 = (float) par[0];
float phi0_1 = (float) par[1];
float omega_1 = (float) par[2];
float d0_1 = (float) par[3];
float tanL_1 = (float) par[4];

HelixClass helix;
helix.Initialize_Canonical(phi0_1, d0_1, z0_1, omega_1, tanL_1, _bField);

for (int iHit = 0; iHit < int(caloHits.size()); iHit++){

CaloHit *ich = caloHits[iHit];
float Dist[3];
float xPoint[3];
xPoint[0] = (float)ich->hit->getPosition()[0];
xPoint[1] = (float)ich->hit->getPosition()[1];
xPoint[2] = (float)ich->hit->getPosition()[2];
helix.getDistanceToPoint(xPoint,Dist);

if ( fabs(Dist[2]) <= 10 ) { //mm
// count them as part of the trackpath (called cores)
}


My question is that, is it okay to do this?
I found this code somewhat "working".
But, sometimes when the track is very curvey, the trackpath deviates from its cluster of CALhits, so i can't get the exact "cores".


 Topic: Documenting Packages together with Marlin
Documenting Packages together with Marlin [message #980] Mon, 30 July 2007 05:26
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hello,

I found that the $(MARLINWORKDIR)/packages directory is included as input for doxygen when generating the documentation for Marlin. This makes the class list very overcrowded if you compile all the ilcsoft packages together with Marlin. I think one should keep the Marlin core documentation separate from the packages, because in most cases I don't need the documentation of other packages but I want to look up the interface and syntax of the Marlin classes themselves.
The developers of the packages should be encouraged to have a doc directory with a Doxyfile, so the user can find the package documentation at $(MARLINWORKDIR)/packages/MYPACKAGE/doc. Making this documentation could even be build into the common build process.

Greetings

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
 Topic: new ilcsoft release v01-01
new ilcsoft release v01-01 [message #966] Mon, 16 July 2007 06:35
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Dear all,

a new release of the ilcsoft tools v01-01 is available.
All tools now fully support building with CMake which will be the new default build process from now on. For the time being the old make files and build procedures will still work.

A number of new features are introduced in the various tools as well - for details please go to the corresponding page at http://ilcsoft.desy.de.

The following version have been added to this release:

  • CED v00-03
  • CEDViewer v00-03
  • LCFIVertex v00-01-01
  • Marlin v00-09-08
  • MarlinReco v00-04
  • MarlinUtil v00-04
  • PandoraPFA v01-01-01
  • RAIDA v01-03
  • SiliconDigi v00-03
  • gear v00-06
  • lccd v00-03-06
  • lcio v01-08-03



You can find reference installations for SL3 and SL4 at

/afs/desy.de/group/it/ilcsoft/v01-01

(using cmake, shared libraries and Marlin plugins).

Or use the ilcinstall tool v01-01 to install all or part of the software:
http://ilcsoft.desy.de/portal/software_packages/ilcinstall/i ndex_eng.html


For a general introduction into the CMake build process for ilctoos see: How_to_use_CMake_for_the_ILC_Software.pdf


-Frank.

[Updated on: Mon, 16 July 2007 06:42]

 Topic: RAIDA messing up directories
RAIDA messing up directories [message #925] Wed, 20 June 2007 07:01
antonio.bulgheroni
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,
this is to advice a possible bug in RAIDA when using ICloud within a Marlin processor.

In my Marlin processor, within the init() phase I'm creating a ICloud2D object into a subfolder in the following way:

AIDA::ICloud2D * hitCloudLocal = AIDAProcessor::histogramFactory(this)->createCloud2D( (basePath + tempHistoName).c_str() );


if you look at basePath + tempHistoName, this looks like "plane0/myCloud". The cloud is created with no automatic conversion because I would like to convert it to an histogram only at the end, when the cloud contains all the entries.

in the end() I have something like:

hitCloudLocal->convertToHistogram();


If I do this, in my ROOT output file I will found the cloud not in the processor folder but in the top one. I have tried to move the conversion also within the processEvent() during the last call but no luck.

Instead if I remove the conversion line, everything works fine apart from the fact that instead of the histogram I have the corresponding ROOT tree.

What I'm doing wrong?

I'm using
ROOT 5.15/08
RAIDA v1-02

Thanks for helping

Antonio
 Topic: Coordinate system in gear::PadRowLayout2D
Coordinate system in gear::PadRowLayout2D [message #923] Fri, 15 June 2007 06:50
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
Hi,

I am trying to write common TPC reconstruction code for both rectangular and disk layout of the readout pads. In doing so I realized that the coordinate conventions in gear::PadRowLayout2D is unfortunate. If I ask e. g. for the position of a pad center, I get

getPadCenter(padid)[0] = x coordinate (cartesian) or r coordinate (polar)

getPadCenter(padid)[1] = y coordinate (cartesian) or phi coordinate (polar)

If I ask for getPadCenter(padid)[0] in a cartesian system, I get x which typically denotes the coordinate along the row. In case of polar coordinates I get r which is typically the coordinate orthogonal to the rows. This convention unnecessarily blows up the reconstruction code. If one would use

getPadCenter(padid)[0] = x (cartesian), phi (polar)

getPadCenter(padid)[1] = y (cartesian), r (polar)

much of the code could stay the same.

Is it possible to change this convention in GEAR?

Cheers, Peter
 Topic: Logging Messages and Logarithms
Logging Messages and Logarithms [message #909] Mon, 11 June 2007 10:47
vogel
Messages: 83
Registered: March 2005
Location: DESY, Hamburg, Germany
Hi everybody,

I just encountered a kind of collision between the new method "std::stringstream& marlin::Processor::log()" which is used internally to provide the logging stream and the standard math function "double std::log(double)" which calculates logarithms.

If you simply call something like "y = log(x)" (together with "include <cmath>" and "using namespace std" or with "include <math.h>") from your Marlin processor, the compiler will complain:

error: no matching function for call to `myProcessor::log(double&)'
note: candidates are: std::stringstream& marlin::Processor::log()

The problem is that a function called "log" exists in the current class scope (inherited from the base class), but it has the wrong signature. Still the compiler does not continue to look for further possible matches in other scopes.

The solution is to provide the namespace explicitly and call "std::log" from your processor. Note that you have to include <cmath> instead of <math.h> in order to have math functions in that namespace.

Cheers,
Adrian

[Updated on: Wed, 13 June 2007 14:13]

 Topic: comment on TPCDigiProcessor
comment on TPCDigiProcessor [message #904] Fri, 08 June 2007 05:34
allister
Messages: 11
Registered: June 2006
Location: LLR, Ecole Polytechnique
Hi,

I notice that TPCDigiProcessor requires the following parameters from the GEAR file:
tpcRPhiResConst
tpcRPhiResDiff
tpcZRes
tpcPixZ
and a hardcoded value of the TPC pad width (2.2 mm)

As far as I understood, these values are not automatically generated in the GEAR files created by Mokka. I wonder if it would be better to modify TPCDigiProcessor so that the following are TPCDigiProcessor parameters:
tpcRPhiResConst (default = ?)
tpcRPhiResDiff (default = ?)
tpcZRes (default = ?)
tpcPixZ (default = ?)
tpcPadWidth (default = 2.0 mm for LDC01_01Sc(?), not 2.2 mm)

Cheers,
Allister Levi Sanchez (LLR, Ecole Polytechnique)
 Topic: ilcinstall: new repository (how to download)
icon4.gif  ilcinstall: new repository (how to download) [message #865] Tue, 22 May 2007 09:27
engels
Messages: 106
Registered: August 2006
The ilcinstall script was moved to a new location!!
(it is no longer available at the marlin repository!!)

new download location:

URL:
http://www-zeuthen.desy.de/lc-cgi-bin/cvsweb.cgi/ilcinstall/ ?cvsroot=ilctools


CVS (ccvssh):
export CVSROOT=:ext:anonymous@cvssrv.ifh.de:/ilctools
export CVS_RSH=ccvssh
cvs co ilcinstall


Sorry for the inconvenience!

Jan
 Topic: A bug found in (ClusterShapes) MarlinUtil
A bug found in (ClusterShapes) MarlinUtil [message #847] Mon, 14 May 2007 01:41
hengneli
Messages: 5
Registered: October 2006
Location: LAL/Orsay

Hi All,

MarlinUtil v00-03.
ClusterShapes.cc (v1.13) after a update of its FitHelix() function from float* to double* :
##########################
2007-04-27 15:56 owendt

* include/ClusterShapes.h, src/ClusterShapes.cc: updated helix fit
##########################

The codes became to:
##########################
int ClusterShapes::FitHelix(int max_iter, int status_out, int parametrisation,float* parameter, float* dparameter, float& chi2,float& distmax, int direction) {
return FitHelix(max_iter,status_out,parametrisation,(double*)(param eter),(double*)(dparameter),(double&)chi2,(double&)d istmax,direction);
}
int ClusterShapes::FitHelix(int max_iter, int status_out, int parametrisation,double* parameter, double* dparameter, double& chi2,double& distmax, int direction) {

... ... ...
... ... ...

}
##########################

When function DoFitting() in MarlinTrackFit class (line 93 of MarlinTrackFit.cc (v1.2)) refers to it using its float* format, it returns the double* format pointers which makes the fitted helix parameters to be absolutely wrong.


This is found when I was using FullLDCTracking Processor in the New version of MarlinReco (v00-03), where the output LDCTracks Collection in LCIO file with wrong curvature (Omega).


Some fix suggestions:

1. Change the float* one of FitHelix function in ClusterShapes.cc to be : (which is tested to be fine)

###########################
int ClusterShapes::FitHelix(int max_iter, int status_out, int parametrisation,float* parameter, float* dparameter, float& chi2,float& distmax, int direction) {


//return FitHelix(max_iter,status_out,parametrisation,(double*)(param eter),(double*)(dparameter),(double&)chi2,(double&)d istmax,direction);
// Modified by Hengne Li @ LAL

double parameterdb[5];
double dparameterdb[5];
double chi2db;
double distmaxdb;
for ( int i=0; i<5; i++ ){
parameterdb[i] = double(parameter[i]);
dparameterdb[i] = double(dparameter[i]);
}
chi2db = double(chi2);
distmaxdb = double(distmax);

int returnvalue = FitHelix(max_iter,status_out,parametrisation,parameterdb,dpa rameterdb,chi2db,distmaxdb,direction);

for ( int i=0; i<5; i++ ){
parameter[i] = float(parameterdb[i]);
dparameter[i] = float(dparameterdb[i]);
}
chi2 = float(chi2db);
distmax = float(distmaxdb);

return returnvalue ;


}
###########################

2. Modified MarlinTrackFit.cc to use the double* format of FitHelix() function.




Cheers,

Hengne



#######################
Hengne LI
Groupe ILC, LAL
BP 34, Bat 208
Universite Paris SUD
91898 Orsay, France
Tel: +33 1 64 46 8541
#######################
 Topic: Spread LCCollections over multiple files?
Spread LCCollections over multiple files? [message #798] Mon, 23 April 2007 04:05
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
Hi,

is it somehow possible to spread different LCCollections over multiple files?

Peter
 Topic: GEAR v00-04 released
GEAR v00-04 released [message #759] Fri, 09 March 2007 01:51
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of GEAR is available. It includes parameters for the LumiCal (Lcal) and has a new class for Vector3D.
See http://ilcsoft.desy.de/gear
 Topic: Marlin v09-06 class reference documents
Marlin v09-06 class reference documents [message #720] Mon, 19 February 2007 01:08
hengneli
Messages: 5
Registered: October 2006
Location: LAL/Orsay

Hi All,

I generated a Marlin v09-06 class reference document (html format) through doxygen, including full references (.h .cc) to classes of MarlinReco v00-02, MarlinUtil v00-02, and PandoraPFA.

It is quite convenient to look up the classes usage through the documents rather than read the codes directly.

Wish it helps,


Hengne

[Updated on: Mon, 19 February 2007 01:33]


#######################
Hengne LI
Groupe ILC, LAL
BP 34, Bat 208
Universite Paris SUD
91898 Orsay, France
Tel: +33 1 64 46 8541
#######################
 Topic: GEAR v00-03 released
GEAR v00-03 released [message #607] Tue, 05 September 2006 03:07
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of GEAR is available. The main new features are a description of the Vertex detector and an implementation of the material point and distance properties.

See: http://www-flc.desy.de/ilcsoft/ilcsoftware/Gear/psc_project_ view

Forum: Mokka
 Topic: mokka db server down?
mokka db server down? [message #2303] Mon, 17 February 2014 21:47
jeans
Messages: 22
Registered: November 2012
The default Mokka db server seems to be down?


"Connecting to the database "models03"
Unable connect to database "models03": Failed to connect to database. Error: Can't connect to MySQL server on 'pollin1.in2p3.fr' (111)

==========> MOKKA ABORTING <============
Database connection failed"


The machine pollin1 seems to be alive: it responds to a ping.


Regards,
Daniel.

[Updated on: Mon, 17 February 2014 21:48]

 Topic: Mokka Simulation Times
Mokka Simulation Times [message #2218] Fri, 24 February 2012 04:29
tonyprice1877
Messages: 16
Registered: September 2010
Location: Birmingham
Hi All,

Me again! (sorry) I now have Mokka 07-07-p05 built and am trying to run some simulations using ILD_O1_v01 on events in a stdhep file

I have copied StandardConfig to a test directory and am trying to run the steer file to simulation the 3 events. Mokka is running but taking ~20 minutes per event! Is this correct or am I doing something wrong? I'm sure I have heard ~1 minute per event so maybe something is wrong with my setup? Can anybody suggest some tests that will allow me to find my problem?

Thanks again,

Tony
 Topic: Mokka Geometry Database Cross-Reference
Mokka Geometry Database Cross-Reference [message #2017] Mon, 07 June 2010 18:57
vogel
Messages: 83
Registered: March 2005
Location: DESY, Hamburg, Germany
Hi all,

after the Mokka Detector Model Database Browser has been a major hit across the globe, there is now another nifty tool that will make handling Mokka geometries even more fun: the Mokka Geometry Database Cross-Reference. It shows you which building blocks are defined in the Mokka geometry database and how they are linked and related to each other – making it easier to decide which pieces you’ll want to use for your simulations, or which you might include in your own future detector geometries.

Enjoy (or complain),
Adrian
 Topic: Migration of CVS Repository of Mokka
Migration of CVS Repository of Mokka [message #1890] Wed, 25 November 2009 07:04
musat
Messages: 57
Registered: February 2004
Dear friends,

The old cvs repository of Mokka was migrated from
' pollin1.in2p3.fr ' to ' llrforge.in2p3.fr '
(pollin1 will be stopped).

The old Mokka releases can be downloaded from the new
cvs repository, via the (readonly) account ' anoncvs '.

You have to set CVSROOT to

:pserver:anoncvs@llrforge.in2p3.fr:/home/cvs/Ilc

(the passwd is unchanged).

Best regards,
Gabriel
 Topic: Simulator status of particles in MC collection
Simulator status of particles in MC collection [message #1884] Thu, 08 October 2009 02:54
cbartels
Messages: 1
Registered: October 2009
Location: DESY
I've been checking the dumpevent printout of the MCParticle collections for some .slcio of the 2008 DESY mass production,
and i'm confused about the "v: vertex is not endpoint of parent" bit. It seems that when the bit is set, the vertex actually IS the endpoint of the parent, and vice versa. An example is below.
Maybe there is a bug in dumpevent or Mokka?

I used the afs binaries in:
/afs/desy.de/group/it/ilcsoft/v01-06/Marlin/v00-10-04/

Greets,
Christoph


In this printout the particle with index 5 has the endpoint of the parent 4 as vertex, although the v-bit is set.

collection name : MCParticlesSkimmed
parameters:

--------------- print out of MCParticle collection ---------------

flag: 0x0
simulator status bits: [sbvtcls] s: created in simulation b: backscatter v: vertex is not endpoint of parent t: decayed in tracker c: decayed in calorim
eter l: has left detector s: stopped


[ id ]index| PDG | px, py, pz | energy |gen|[simstat]| vertex x, y , z | endpoint x, y , z | mass | ch
arge | [parents] - [daughters] |

[0000661c] 0| 22| 2.88e-06,-5.29e-06, 1.12e-02| 1.12e-02| 1 |[ l ]| 0.00e+00, 0.00e+00, 0.00e+00| 3.59e+00,-6.59e+00, 1.40e+04| 0.00e+00| 0.0
0e+00| [] - []
[0000661d] 1| 22|-1.15e-08,-2.40e-09,-4.80e-07| 4.80e-07| 1 |[ c s]| 0.00e+00, 0.00e+00, 0.00e+00|-5.99e+01,-1.25e+01,-2.51e+03| 0.00e+00| 0.0
0e+00| [] - []
[0000661e] 2| 12|-1.85e+02,-5.99e+01, 9.84e+01| 2.18e+02| 1 |[ l ]| 0.00e+00, 0.00e+00, 0.00e+00|-7.50e+03,-2.43e+03, 4.00e+03| 0.00e+00| 0.0
0e+00| [] - []
[0000661f] 3| -12| 1.80e+02, 4.74e+01,-8.15e+00| 1.86e+02| 1 |[ l ]| 0.00e+00, 0.00e+00, 0.00e+00| 7.50e+03, 1.98e+03,-3.39e+02| 0.00e+00| 0.0
0e+00| [] - []
[00006620] 4| 22| 4.63e+00, 1.25e+01,-9.30e+01| 9.40e+01| 1 |[ t s]| 0.00e+00, 0.00e+00, 0.00e+00| 1.54e+01, 4.15e+01,-3.09e+02| 0.00e+00| 0.0
0e+00| [] - [5,14]
[00006621] 5| -11| 3.15e+00, 8.48e+00,-6.32e+01| 6.38e+01| 0 |[s v c s]| 1.54e+01, 4.15e+01,-3.09e+02| 1.29e+02, 3.35e+02,-2.49e+03| 5.11e-04| 1.0
0e+00| [4] - [6]
[00006622] 6| 22| 2.42e-01, 5.81e-01,-4.31e+00| 4.36e+00| 0 |[s c s]| 1.29e+02, 3.30e+02,-2.47e+03| 1.29e+02, 3.31e+02,-2.48e+03| 0.00e+00| 0.0
0e+00| [5] - [7]

[Updated on: Thu, 08 October 2009 02:59]

 Topic: New SVN Mokka repository
New SVN Mokka repository [message #1853] Thu, 03 September 2009 06:39
musat
Messages: 57
Registered: February 2004
Dear Friends,

A new subversion repository for Mokka is available from LLR at:

http://llrforge.in2p3.fr/svn/Mokka

The first tag committed to it is 'mokka-07-00'.

There is a default readonly access with no passwd.

For Mokka developers we created write access accounts
that have the same account names and passwords that
they had on the old CVS repository.

There is a 'trunk' sub-directory containing the develompent
tree, a 'tags' sub-directory and a 'branches' one.

For example:

- the first tag can be checked out with the command

svn co http://llrforge.in2p3.fr/svn/Mokka/tags/mokka-07-00


- the 'trunk' can be checked out with the command

svn co http://llrforge.in2p3.fr/svn/Mokka/trunk Mokka

A ViewVC access is also available:

http://llrforge.in2p3.fr/viewvc/Mokka/

The old CVS repository is still available in readonly mode.
The new developments will be committed to the new SVN.

Many thanks to David Chamont, the administrator of the LLR software repositories
for all his help!

Best regards,
Paulo and Gabriel
Pages (7): [ «    1  2  3  4  5  6  7    »]


Current Time: Mon Oct 21 05:10:24 Pacific Daylight Time 2019
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software