Linear Collider Forum

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

Forum: slic
Topic: lcdd 1.12 released
lcdd 1.12 released Tue, 19 December 2006 15:13
 jeremyMessages: 46Registered: March 2004 Location: SLAC
Hello.

I would like to announce the release of LCDD version 1.12, to coincide with the release of SLIC 2.1 .

You can find release notes at this URL.

http://www.lcsim.org/software/lcdd/lcdd_release_notes_1_12_0 .html

Jeremy McCormick, SLAC <jeremym@slac.stanford.edu>
Topic: slic 2.1 released
slic 2.1 released Tue, 19 December 2006 15:11
 jeremyMessages: 46Registered: March 2004 Location: SLAC
Hello.

I would like to announce the release of SLIC version 2.1 . The release notes can be found here.

http://www.lcsim.org/software/slic/slic_release_notes_2_1_0. html

You can find binaries for your platform at this URL.

http://www.lcsim.org/dist/slic/

I have currently posted only the Linux binaries. The Windows and OSX versions are in the works.

This release is fully compatible with Geant4 version 8.2, which was released on December 15, 2006.

[Updated on: Tue, 19 December 2006 15:14]

Jeremy McCormick, SLAC <jeremym@slac.stanford.edu>
Topic: slic 2.0
slic 2.0 Mon, 13 November 2006 12:31
 jeremyMessages: 46Registered: March 2004 Location: SLAC
Hello, SLIC users.

SLIC version 2.0 has been released, in the interests of consolidating a number of minor changes since around May 2006 into a single version.

I am planning to make more regular releases in the future and will be posting updates to the lcd-dev mailing list that point to forum postings.

I have attached the release notes to this posting, in HTML format.

Release notes are also available from the slic website.

http://www.lcsim.org/software/slic/release_notes_v2r0p7.html

Please let me know of any questions or concerns.

[Updated on: Mon, 13 November 2006 13:00]

Jeremy McCormick, SLAC <jeremym@slac.stanford.edu>
Topic: Range Cuts in SLIC
Range Cuts in SLIC Thu, 08 September 2005 07:10
 karyotakMessages: 2Registered: March 2005
Hi all,

I run SLIC and try to find out the range cuts for gammas
Running dumpRegion I find this:

Region DefaultRegionForTheWorld
Materials : Air Tungsten G10 Silicon Steel235 Iron PyrexGlass RPCGasDefault Polystyrene Beryllium Aluminum
Production cuts : gamma 1 mm e- 1 mm e+ 1 mm

Region TrackingRegion
Materials : Air CarbonFiber Rohacell31 Beryllium PolystyreneFoam Aluminum G10 Copper PEEK Epoxy Silicon Kapton Titanium
Production cuts : gamma 1 cm e- 1 cm e+ 1 cm

Does the first region correspond to the Silicon of the calorimeter ?? In this case isn't it too big ??

I can change it by /run/setCut or setCutForRegion. The attached plot shows the energy deposited by 1 GeV gammas at 90 degrees in the 30 layers of Si using cdcaug05 geometry. I think this behavior is well known.

Yannis

• Attachment: Eraw.png
Topic: New SLIC and LCDD Releases
New SLIC and LCDD Releases Wed, 07 September 2005 14:00
 jeremyMessages: 46Registered: March 2004 Location: SLAC
I have release two packages today.

SLIC Release v1r10p0

http://www.lcsim.org/software/slic/release_notes_v1r10p0.htm l

LCDD Release v1r8p0

http://www.lcsim.org/software/lcdd/release_notes_v1r8p0.html

Jeremy McCormick, SLAC <jeremym@slac.stanford.edu>
Forum: Full Simulations
Topic: Protoype Simulation - Cell Numbering and Coordinate Frames
Protoype Simulation - Cell Numbering and Coordinate Frames Thu, 15 July 2004 05:51
 musatMessages: 57Registered: February 2004
Hello,

People from LLR and DESY reached to a common point of view and wrote some suggestions concerning the coordinate system and the cell numbering. The document is

http://polype.in2p3.fr/geant4/tesla/www/mokka/ProtoDoc/Coord inatesAndNumbering.html

These suggestions were used in the new implementation of the Calice Ecal prototype at LLR, and are going to be used in the new Hcal implementation at DESY.

Cheers,

Gabriel MUSAT
Topic: Simulation Requirements Document
Simulation Requirements Document Thu, 27 May 2004 08:31
 dhimanMessages: 2Registered: May 2004 Location: Norhtern Illinois Univers...
Friends,
The Worldwide LC simulation working group is preparing a document that lists the requirements for a common detector simulation program. A preliminary draft of this document is ready for your viewing. Please see message (#98) posted today on the Common Simulation Framework forum.

On behalf of the Worldwide LC Simulation Working Group,
Dhiman Chakraborty

[Updated on: Thu, 27 May 2004 08:54]

Forum: Individual Particle Reconstruction
Topic: TrivialPFA.java not in examples
TrivialPFA.java not in examples Fri, 13 June 2008 14:57
 manlyMessages: 21Registered: May 2008 Location: University of Rochester
Hi All,

The documentation led me to think TrivialPFA is in the JAS examples page and it is not there.

I know this is silly, but how do I manage to download the code, such as uiowa PFA packages using CVS. I can't seem to find a place to download it.

Sigh.

Thanks for any help offered.

-Steve
Topic: Mailing list established for particle flow analyses
Mailing list established for particle flow analyses Thu, 13 October 2005 11:00
 NormanGrafMessages: 80Registered: January 2004
Dear Colleagues,
A mailing list has been established to foster communication between individuals and groups working on particle flow reconstruction.

The homepage for this mailing list is:

http://www.slac.stanford.edu/cgi-bin/lwgate/P-FLOW/

You can subscribe at:

http://www.slac.stanford.edu/cgi-bin/lwgate/P-FLOW/subscribe .html

You can unsubscribe at:

http://www.slac.stanford.edu/cgi-bin/lwgate/P-FLOW/unsubscri be.html

Archives are at:

http://www.slac.stanford.edu/cgi-bin/lwgate/P-FLOW/archives/

Norman Graf
Forum: org.lcsim
 aconwayMessages: 7Registered: July 2013 Location: FNAL
Hi,

I'm trying to use GeomConverter to create xml files for PandoraPFA for the mcdrcal01 detector and can't get it to work. The stacktrace looks something like the following.

[aconway@tp mcdrcal02]$java -jar ~/.m2/repository/org/lcsim/GeomConverter/2.8-SNAPSHOT/GeomConverter-2.8-SNAPSHOT-bin.jar -o pandora compact.xml mcdrcal01_pandora.xml EcalEndcap HcalEndcap MuonEndcap Exception in thread "main" java.lang.RuntimeException: org.lcsim.conditions.ConditionsManager$ConditionsSetNotFoundException: Conditions set not found: SamplingFractions/EcalEndcap
at org.lcsim.geometry.compact.converter.Main.main(Main.java:107)
Caused by: org.lcsim.conditions.ConditionsManager$ConditionsSetNotFoundException: Conditions set not found: SamplingFractions/EcalEndcap at org.lcsim.conditions.ConditionsManagerImplementation.getConditions(ConditionsManagerImplementation.java:141) at org.lcsim.geometry.util.SamplingFractionManager$SamplingFractionConverter.getData(SamplingFractionManager.java:112)
at org.lcsim.geometry.util.SamplingFractionManager$Sampling ... It seems clear I don't have the right files in the right places for GeomConverter to get the sampling fractions, but I don't really know what it needs. From what I've been able to dig up on the Internet, this simply isn't documented yet. I'll also mention that this command works when I use the sidloi3 detector. I attached the detector's .zip file. While not all the files in SamplingFractions have the right filenames, it seems to me EcalEndcap should at least work. Thanks, Alex Topic: lcsim release lcsim release Fri, 14 August 2009 17:04  jeremyMessages: 46Registered: March 2004 Location: SLAC Hello, lcsim users. I have made a release of lcsim today and its dependencies. The following versions were tagged and released today. lcsim - 1.11 lcsim-contrib - 1.1 GeomConverter - 1.8 lcsim-parent - 1.4 The jar files for these versions can be found on the lcsim site. http://www.lcsim.org/maven2/org/lcsim The websites for these projects are deployed to the software section. http://www.lcsim.org/software/lcsim/1.11 http://www.lcsim.org/software/GeomConverter http://www.lcsim.org/software/lcsim-contrib New development versions are as follows. lcsim - 1.12-SNAPSHOT GeomConverter - 1.9-SNAPSHOT lcsim-contrib - 1.2-SNAPSHOT We are depending on lcsim-parent 1.4 for the time being for all lcsim dependencies. It is considered stable. Please send any questions to jeremym@slac.stanford.edu. I will also post this message to the linear collider forum ---IMPORTANT NOTE--- In order to install this release from JAS3 as a plugin, please remove your existing lcsim plugin first. Go to View -> Plugin Manager -> Installed -> org.lcsim . Click on "org.lcsim" under user and then the "Remove selected plugins" button. Now restart JAS3, and install lcsim under Available -> hep -> linearcollider . This needs to be done due to an error I made in the release procedures. Apologies for that! --Jeremy McCormick, SLAC Jeremy McCormick, SLAC <jeremym@slac.stanford.edu> Topic: SUSY particles, charge NaN SUSY particles, charge NaN Fri, 01 February 2008 11:31  bjasperMessages: 33Registered: March 2007 Location: University of Regina I'm working with events containing SUSY particles. When I open up an slcio file (from SLIC) and look at an event in the event browser, all SUSY particles (in my case, staul+, staul-, neut10) have charge NaN. As a result, my analysis aborts when I try to run TopDriver (after having successfully run RecoDriver) in the org.lcsim.contrib.niu package. Is there some way to get around this? When I look at the default particle properties, it seems like the SUSY particles all have their charges defined... Topic: Memory problems building org.lcsim Memory problems building org.lcsim Tue, 16 October 2007 21:17  tonyjMessages: 138Registered: January 2004 I have found that to build recent versions of org.lcsim I need: export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=128m" before starting maven. Topic: Acessing files created with sid01_polyhedra geometry Acessing files created with sid01_polyhedra geometry Fri, 14 September 2007 15:08  wenzelMessages: 25Registered: February 2007 Location: Fermilab Hi I tried to access a file using the sid01_polyhedra geometry that I produced a week ago. After adding my module to cvs and doing a cvs update I am getting the following message: wenzel@nara:~/lcsim/lcsim/sandbox/HansWenzel/Tracking$ java MainLoop
ndition item 'compact.xml' for detector 'sid01_polyhedra'
at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorCondi
tionsConverter.java:31)
at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorCondi
tionsConverter.java:16)
at org.lcsim.conditions.CachedConditionsImplementation.getCache dData(Cac
hedConditionsImplementation.java:19)
at org.lcsim.util.event.BaseLCSimEvent.getDetector(BaseLCSimEve nt.java:6
3)
at org.freehep.record.loop.SequentialRecordLoopImpl.supplyRecor d(Sequent
ialRecordLoopImpl.java:564)
at org.freehep.record.loop.SequentialRecordLoopImpl.loop(Sequen tialRecor dLoopImpl.java:469)
at org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:158)
at org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:140)
at MainLoop.main(MainLoop.java:33)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Different ind ices for system field in same compact description!
at org.lcsim.detector.converter.compact.DetectorConverter.check IdDict(De tectorConverter.java:570)
at org.lcsim.detector.converter.compact.DetectorConverter.conve rtSubdete ctors(DetectorConverter.java:182)
at org.lcsim.detector.converter.compact.DetectorConverter.conve rt(Detect orConverter.java:93)
at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorCondi tionsConverter.java:25)
... 9 more
Caused by: java.lang.RuntimeException: Different indices for system field in sam e compact description!
at org.lcsim.detector.converter.compact.DetectorConverter.check IdDict(De tectorConverter.java:533)
... 13 more
wenzel@nara:~/lcsim/lcsim/sandbox/HansWenzel/Tracking$java MainLoop Exception in thread "main" java.lang.RuntimeException: Error reading detector condition item 'compact.xml' for detector 'sid01_polyhedra' at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorConditionsConverter.java:31) at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorConditionsConverter.java:16) at org.lcsim.conditions.CachedConditionsImplementation.getCache dData(CachedConditionsImplementation.java:19) at org.lcsim.util.event.BaseLCSimEvent.getDetector(BaseLCSimEve nt.java:63) at org.lcsim.util.DriverAdapter.recordSupplied(DriverAdapter.ja va:70) at org.freehep.record.loop.SequentialRecordLoopImpl.supplyRecor d(SequentialRecordLoopImpl.java:564) at org.freehep.record.loop.SequentialRecordLoopImpl.loop(Sequen tialRecordLoopImpl.java:469) at org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:158) at org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:140) at MainLoop.main(MainLoop.java:33) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Different indices for system field in same compact description! at org.lcsim.detector.converter.compact.DetectorConverter.check IdDict(DetectorConverter.java:570) at org.lcsim.detector.converter.compact.DetectorConverter.conve rtSubdetectors(DetectorConverter.java:182) at org.lcsim.detector.converter.compact.DetectorConverter.conve rt(DetectorConverter.java:93) at org.lcsim.geometry.GeometryReader.read(GeometryReader.java:5 6) at org.lcsim.util.loop.DetectorConditionsConverter.getData(Dete ctorConditionsConverter.java:25) ... 9 more Caused by: java.lang.RuntimeException: Different indices for system field in same compact description! at org.lcsim.detector.converter.compact.DetectorConverter.check IdDict(DetectorConverter.java:533) ... 13 more Topic: More org.lcsim FAQ's More org.lcsim FAQ's Fri, 25 May 2007 12:05  tonyjMessages: 138Registered: January 2004 I have been receiving a number of questions on Java and AIDA (mainly from Rob), so I have created new sections in the org.lcsim FAQ for Java and AIDA. You can already find several new entries there: http://confluence.slac.stanford.edu/x/xHE Tony Topic: Driver for the trf track finder package Driver for the trf track finder package Mon, 12 February 2007 08:38  wenzelMessages: 25Registered: February 2007 Location: Fermilab Hi is there a driver for the trf track finder. I couldn't find it. I was able to get the SOD package to work but would to work on more realistic tracking. thanks hans Topic: Change to org.lcsim.event.Track interface Change to org.lcsim.event.Track interface Mon, 23 October 2006 12:50  tonyjMessages: 138Registered: January 2004 As announced last week the org.lcsim Track interface has been updated to return a SymmeticMatrix class instead of double[][] as before. All known code which uses the Track interface has been updated, including most (but not all) of the code in the contrib area. If you have personal code which uses the error matrix from the track interface it may need to be updated. The documentation on the new SymmetricMatrix and other related classes can be found here: http://java.freehep.org/freehep-physics/apidocs/index.html We anticipate making more changes to the Track interface, which will be discussed at tomorrows meeting. If you want to avoid having to worru about this until the Track interface is stable again, you can use the tj061023 which was made before these changes: cd GeomConverter cvs update -r tj061023 cd .. cd lcsim cvs update -r tj061023 Tony Forum: EUDET Telescope Topic: TB1 data taking phase over TB1 data taking phase over Wed, 20 June 2007 05:36  antonio.bulgheroniMessages: 66Registered: January 2007 Location: INFN - Roma3 Dear all, this is to inform all of you that our first test beam is now over, at least for what data taking is concerning. We were able to run the brand new analysis software fully compliant with the ILC standard tools and we are now producing the first very fresh results. Few of them have been presented already this morning in DESY during the summary meeting (agenda & talk available at indico server). Now data are migrating to the GRID for storage and continue the analysis also from outside DESY. As soon as they will find their final location, I will post here a small how to access to them and a description of the dataset catalog. Thanks to everybody for the very fruitful collaboration and stay tuned to see more. Cheers, Antonio on behalf of the testbeam24 crew! ---- Antonio Topic: EORE file fix EORE file fix Wed, 23 May 2007 04:54  antonio.bulgheroniMessages: 66Registered: January 2007 Location: INFN - Roma3 Dear all, during the last meeting in Geneva we concluded that we need something like a BORE/EORE identification. In case the acquisition software was hanging we need to have a sort of "file fix" utility able to scan the LCIO file and eventually append an EORE in the end. I prepared this utility as a Marlin processor (see details below). Another important use of this utility is more related to the analysis itself (this is actually the reason why I prepared it ). The point is the following: since Marlin is "Modular" and we are preparing separate processors for each task, one can imagine to perform the analysis step by step keeping track of all the intermediate output files. Consequently every intermediate files should have the same structure (say with an EORE at the end). This is trivial whenever all records within the input file are processed, but if the user limits the number of record to something below the total number, then the output file won't have the EORE. In Marlin framework, a workaround can be easily applied implementing an EUTelOutputProcessor inheriting from the standard LCIOOutputProcessor. When the EUTelOutputProcessor::end() is called by the ProcessorMgr, a check on the type of the previous event is done. If this is an EORE then just close the file, if not append an EORE before closing. From an OO point of view, this just requires to re-implement the end() method keeping all the others as in LCIOOutputProcessor. It is very easy and I've done it already. From a technical point of view, there a small detail to be fixed in a the original LCIOOutputProcessor implementation. Since I want to derive EUTelOutputProcessor from LCIOOutputProcessor and not from Processor directly, I (think I) need to have also the LCIOOutputProcessor(const std::string& typeName) constructor as it is in the DataSourceProcessor. This modification along with another change to make the new messaging system working also with const method is included in the attached patch. Frank, can you comment on that? Do you think it is worth or we are moving in the wrong direction? Thanks, toto Topic: ilcinstall: configuration file for Eutelescope ilcinstall: configuration file for Eutelescope Mon, 14 May 2007 03:08  antonio.bulgheroniMessages: 66Registered: January 2007 Location: INFN - Roma3 Dear all, this is just to inform you that, thank to the new ilcinstall script, it is possible to install all the ILC software tools in a single process including additional Marlin packages as Eutelescope. In the attached file, the configuration script I used to install all the ILC software together with the Eutelescope package. Cheers, Antonio • Attachment: install.cfg (Size: 2.30KB, Downloaded 1749 times) Topic: Important steps toward the EUDET telescope analysis Important steps toward the EUDET telescope analysis Mon, 19 February 2007 06:17  antonio.bulgheroniMessages: 66Registered: January 2007 Location: INFN - Roma3 Dear All! This short post to announce that we are very close to the first release of the EUTelescope Marlin processors. The code comes with doxygen documentation, but since we still don't have a place to publish it, I will try to describe here what has been already implemented and what is still missing. For the time being I tried to avoid ROOT linkage and I'm using AIDA for histogramming. This is what we already have: • EUTelSucimaImagerReader. This is just a test to implement the on-line conversion of the standard SUCIMA DAQ format. Marlin reads an event in the SUCIMA DAQ format and converts it on the fly into a LCEvent. In principle we can implement a reader also for the IRES USB Imager board. • EUTelPedestalNoiseProcessor. This processor calculates the pedestal and the noise value of each pixel of each detector in the telescope. Few algorithm have been implemented and waiting to be fully debugged. The results of this processor are saved into a "Condition" file (it can also be a database entry, but not sure it is really needed). • EUTelCalibrateEventProcessor. This processor removes the pedestal from the current rawdata and eventually suppress the common mode. The output of this processor is a collection of TrackerData object, one per detector, with the data ready for the cluster search. • EUTelClusteringProcessor. This processor looks into each detector TrackerData for group of pixels passing the cluster selection cuts. The output of this processor is a collection of TrackerData containing only the clusters. What is missing: • EUTelAutoPedestalProcessor. This processor will be used with self-biased pixel detectors in which there is actually no need for a real pedestal calculation. The pedestal and noise values for each pixel can be initialize to a reasonable value and then, during the first N events updates to the correct value. • EUTelClusterMergingProcessor. This processor will calculate the distance between clusters belonging to the same detector. In the case the two clusters are touching each other, something should be done to separate them. Probably not really needed in a telescope setup where the number of clusters per plain should be sufficiently low. • EUTelDataQualityMonitor. This processor should take as input the clusters provided by the EUTelClusteringProcessor and fill in sets of histograms/profiles/distributions... to cross-check the data quality at the detector level. Typical examples are the SNR for each detector, the beam profile, the eta function... • All the remaining track finding / fitting stuff. • Interfacing to the geometry database. You can download the source code from here or via anonymous CVS. Once you have the source code, uncompress it into$(MARLIN)/packages and type make from the Marlin top folder.

Type make doc to produce the documentation.

To produce some example files browse to the \$(MARLIN)/packages/Eutelescope/test and read the README files.

Please give it a try and let me known what you think about. Your feedback is very well appreciated!

Best regards,

Antonio

Forum: General Questions
Topic: Detector Specifications
Detector Specifications Thu, 15 October 2009 08:05
 bweinertMessages: 16Registered: September 2008 Location: University of Rochester
Hi, I'm running into a problem with the layer thickness of the muon system. The program updates the number of layers, when I run SID01 vs SID02 events, but it doesn't seem to update the layer thickness. It leaves me with 11 layers of 20mm thickness, so the detector stops early. This problem only occurs for the virtual tracks, not the real tracks. I've been trying to track down where the code gets the layer thickness from and I haven't found an actual number yet. Is there anywhere that I should look? Thank you.

-Ben
Topic: sid01 vs sid02
sid01 vs sid02 Tue, 28 July 2009 08:22
 bweinertMessages: 16Registered: September 2008 Location: University of Rochester
Hi would there be any reason why using an sid02 event would change the results I'm getting for track matching. When I used the sid01file(mu_Theta4-176_1-50GeV-0-5000_SLIC-v2r3p10_geant4-v 9r0p1_LCPhys_sid01.slcio) I get real, virtual, and matched tracks that penetrate all the way to the edge of muon system. When I use the sid02 event
(mu_50.0GeV_Theta90_SLIC-v2r5p1_geant4-v9r1p2_LCPhys_sid02.s lcio) it only barely makes it to the muon detector for real, virtual, and matched hits. I've tried the same thing with higher energy sid02 events and I get the same result. Is there any reason why this might be the case? It looks like the problem is with the virtual track. I use TrackStepper from util/step to create the virtual tracks. Should I use something else now that I'm using sid02?

-Ben

I create the virtual tracks by using:
VirtPos[0] = rpVect[0];

VirtPos[1] = rpVect[1];

VirtPos[2] = rpVect[2];

I create the real hits by using (an example for the had calorimeter):
List<CalorimeterHit> hits = null;
try {
hits = event.get( CalorimeterHit.class, hcalHitmapName);
}
catch (Exception e) {}
if(hits==null) return;

for( int i = 0; i<hits.size(); ++i ) {
CalorimeterHit ihit = hits.get(i);
double[] Pos = ihit.getPosition();
matchHitsXYZ(ihit.getPosition());}

I match them by using:
protected void matchHitsXYZ(double [] realPos)
{

AIDA aida = AIDA.defaultInstance();
int nhitsTotal = 0;

// loop through virtual hits
for (double [] virtPos : VirtPosList) {

if(subdetName.equals(ecalSubdetName)) {
if (((realPos[0])-3)<=virtPos[0] && virtPos[0]<=((realPos[0])+3))
{

if(((realPos[1])-3)<=virtPos[1] && virtPos[1]<=((realPos[1])+3)){

if( ((realPos[2])-3)<=virtPos[2] && virtPos[2]<=((realPos[2])+3)){

aida.cloud2D("Y vs. X Matched").fill(realPos[0], realPos[1]);
aida.cloud1D("Rho
Matched" ).fill(Math.sqrt((realPos[0]*realPos[0])+(realPos[1]*realPos [1])+(realPos[2]*realPos[2])));
realPos[1], realPos[2]));

nhitsTotal++;
}
} } }
else if(subdetName.equals(hcalSubdetName)) {
if (((realPos[0])-10)<=virtPos[0] && virtPos[0]<=((realPos[0])+10))
{

if(((realPos[1])-10)<=virtPos[1] && virtPos[1]<=((realPos[1])+10)){

if( ((realPos[2])-10)<=virtPos[2] && virtPos[2]<=((realPos[2])+10)){
aida.cloud2D("Y vs. X Matched").fill(realPos[0], realPos[1]);
aida.cloud1D("Rho
Matched" ).fill(Math.sqrt((realPos[0]*realPos[0])+(realPos[1]*realPos [1])+(realPos[2]*realPos[2])));
realPos[1], realPos[2]));

nhitsTotal++;

}
} }}

}
}
Topic: Registering and using forum.linearcollider.org
Registering and using forum.linearcollider.org Sun, 27 May 2007 16:01
 tonyjMessages: 138Registered: January 2004
I have written up some additional instructions on how to register with and use the forum.linearcollider.org web site. You can find these instructions at:

http://confluence.slac.stanford.edu/x/d4Q

These instructions are meant to complement the help built-in to the forum web site.

Feedback and suggestions are welcome.

[Updated on: Wed, 06 June 2007 00:15]

Forum: Announcements
Topic: Transition from CVS to SVN
Transition from CVS to SVN Mon, 03 August 2009 05:04
 engelsMessages: 106Registered: August 2006
Dear ilcsoft developers,

An email was sent to the mailing list ilcsoft-dev@desy.de but it seems that many people are not registered in this mailing list, so here is a copy of the message:

Due to the LOI we were forced to delay the long announced migration of our cvs repository to the new subversion system (https://svnsrv.desy.de).

Now that the LOI is over and things have calmed down a bit, we would like to take the first week of August for doing the transition.

The cvs projects in question are:
gear, lccd, ilctools, marlin, marlinreco and eutelescope

Please try to commit local pending changes from any of this projects so they automatically get synchronized to svn.

You can find documentation about the new system on: https://svnsrv.desy.de

+ 2 useful liks to get started with svn:
CVS to SVN Crossover Guide
Version Control with Subversion

Cheers,
Jan
Topic: EUDET Telescope forum created
EUDET Telescope forum created Wed, 31 January 2007 09:42
 tonyjMessages: 138Registered: January 2004
A new "EUDET Telescope" forum has been created under the "Analysis and reconstruction" category. This will be used for discussions about EUDET pixel beam telescope -- mainly analysis software and DAQ issues.
Topic: Detector Simulation & Reconstruction workshop Jan. 9-11, 2006
Detector Simulation & Reconstruction workshop Jan. 9-11, 2006 Thu, 13 October 2005 10:55
 NormanGrafMessages: 80Registered: January 2004
The ALCPG Simulation and Reconstruction group will
hold a workshop hosted by the University of Colorado
in Boulder, January 9-11, 2006. Details will become
available at the following URL:

For the organizing committee,
Norman Graf
Topic: LCIO v01-03 released
LCIO v01-03 released Fri, 24 September 2004 10:14
 gaedeMessages: 233Registered: January 2004 Location: DESY, Hamburg
A new release of LCIO v01-03 is available.

Topic: Announcing WIRED 4 Version 4.0.beta.1
Announcing WIRED 4 Version 4.0.beta.1 Thu, 09 September 2004 15:10
 dunsMessages: 2Registered: January 2004
WIRED 4 (beta1)
===============

A first release (beta1) is available of WIRED 4.

WIRED 4 is a generic event display framework.

This release includes many features supported in WIRED 3
as well as several new features and improvements:

- easier interactivity when zooming, scaling or translating
- better user feedback while interacting with the plots
- improved picking mode
- drag and drop of datafiles
- improved output formats and copy-paste

WIRED 4 runs inside JAS 3 and can, with the help of other plugin

- HepRep1 and HepRep2 XML files
- BaBar's CORBA servers (HepRep1)
- GLAST's HepRep2 XML files and GAUDI CORBA servers
- LCIO data files
- Geant4 HepRep1 and HepRep2 output

WIRED 4's website is at:

http://wired4.freehep.org

A user manual, describing installation and usage, is available at:

http://wired4.freehep.org/manual/UserManual.html

If you already have JAS 3 installed, you can install WIRED 4 directly from the
plugin manager.

The 4.0 release is planned for the middle of october. This beta release is
meant for users to give us feedback.

A discussion forum for WIRED 4 exists at:

http://forum.freehep.org

and a bug database is available at:

http://bugs.freehep.org

--
The JAS 3 and WIRED 4 team
Mark Donszelmann, Tony Johnson, Max Turri and Victor Serbo

sent to:
- Geant4-visualization
- BaBar Graphics
- Linear Collider forum
- WIRED Announce forum

as:
Announcing WIRED 4 Version 4.0.beta.1
Topic: new URL for LCIO homepage
new URL for LCIO homepage Tue, 17 February 2004 06:57
 gaedeMessages: 233Registered: January 2004 Location: DESY, Hamburg
The LCIO homepage is now (also) visible under the new URL:

http://lcio.desy.de

Topic: New URL
New URL Thu, 22 January 2004 21:15
 NormanGrafMessages: 80Registered: January 2004
We're now live at forum.linearcollider.org!
Forum: LC-TPC
Topic: Ion Effects
Ion Effects Thu, 28 June 2007 03:24
 wieneMessages: 23Registered: June 2006 Location: University of Bonn
Below are Ron's minutes of the meeting on ion effects at DESY on June 2, 2007:

WP#30 Special discussion on ion effects
2 June 2007, 14:00-ca.17:00
Sem Room 1
DesyHH

Chair: Takeshi

Talks:
Ron - Boundary conditions, Beijing report
Astrid (presented by Martin) - Space charge
Akira - GEM gating
Vincent - Gas possibilites
Dean - Ideas on how to measure/correct for ions using photoelectrons
Everybody - Concluding discussion

All talks are avialable at the LCWS07 site:
http://ilcagenda.linearcollider.org/materialDisplay.py?sessi onId=144&materialId=1&confId=1296

Summary
--------------------

1. Ron reminded of the Snowmass 2005 and other work which is summarized in our Beijing TPC report (now published as LC Note LC-DET-2007-005 (see http://flcweb01.desy.de/lcnotes/).

-Space charge effects can be minimized by choosing a gas with large \omega\tau.

-The Star TPC review Oct.2006 estimates mean for us (large \omgea\tau) up to 200fC/cm3 in the volume would give rise to about 10cm drift-electron dispacement over the full drift, and this is the magnitude of the B-field effects we have to correct.

-Back-of-the-envolope and the Tesla TDR estimates give 0.5% occupancy for nominal backgrounds and about one fC/cm3 in the volume assuming 100e per occupied voxel. (Adrian at this meeting give more solid numbers based on simulation, and his numbers are lower as seen below).

-In the sheet, the density might be as large as 100 fC/cm3, but the sheet is thin next to the Gem/Micromegas plane so its effect should be small (must be simulated). In the volume, the sheets can be eliminated by gating between trains.

-The correction for space-charge and B-field (antiDID) of about 1 cm means measuring the effects to 2x10-5, the tools for doing this are known (see the Beijing report); this order of correction was achieved by the Aleph TPC.

-The distortion effects and thier correction can and must be studied further by simulation.

-When thinking of the solution to the space-charge issue, we should not compromise the point resolution or the dE/dx resolution.

2. Adrian's study of the backgrounds (based on Guinea Pig) and their effect on TPC occupancy have now advanced to a rather sophisticated level. He described in his talk the various background sources. The main result on occupancy is seen in slide 12, where it is seen that we would expect on average about 0.04% occupancy (the radial dependence is on slide 13) for the pad sizes we are now considering, which is an order of magnitude lower than the TDR days. That plot also demonstrates what we have said since the beginning (2001) that we should make the granularity as fine as possible to reduce the background occupancy as much as possible. Adrian's
slide 14 on the electron space charge for 100 BX must be multiplied by 150 since the ions take about one second to drift out (worst case) and itegrate over 15000 BX (near the anode); nevertheless, Adrian's values are an order of mignitude lower than above, point 1. Note that backgrounds from minijets and muons are not yet included in Adrian's simulations.

3. Astrid's thesis work was reported by Martin. She has developed a tool which can be used to study the ion-sheet effect. It is based on Heeds, Magboltz and Gem charge-transfer parameterization. It gives the charge density in the back-drifting ion sheet (slides 5, 6, 7). This can be used
for optimizing Gem settings and simulation distortion effects due to the sheets.

4. Akira, and CDC colleagues have studies many properties of gating using wires or Gems (the micromesh-gating was not reported on). The ExB effect for wire gating seems to deteriorate about 10% of the gap between the wires. For Gem, many ideas were looked into; no attempt will be made here to summarize all of the facits of the parameters simulated and/or measured; Akira's slides are the best summary of the understanding. The conclusion for the moment is that a Gem gate should have larger holes, thinner Gem, a low drift field and high (but not too high) transfer field: in that case the electron transmission up to 70% might be possible (is this enough?). The basic idea was to decide on a scheme using Gem gating and then to test it at using the MPTPC at Kek or, see Akria's final slide no. 21, at the 5T magnet at Desy.

5. Vincent gave a nice review of issues and numerical values for the electron and ion drift properties. Possible solutions involve exotic ideas (e.g. choosing a gas with fast ions or making a very short TPC) and less exotic possibilites (e.g. gating to avoid the sheets in the drift volume). He points out that the first thing to do is more simulation work in order to understand the magnitude of the effects. (One comment to his
"extra slide" No.16: the Star TPC has such a sheet, but a cylindrical one due to a mismatch between the wire grids on the inner and outer sectors. The correction for this distortion is rather well understood.)

6. Dean explained his proposal to study ion distortions at the LCTPC using the displacement of photoelectrons emitted by a pattern on the cathode illuminated by UV light. This interesting technique will be tested at LP1.

7. Discussion (Takeshi et al): no show-stoppers were identified
and simulations indicate that the effects may be smaller than originally estimated. We agreed that these studies must be continued so that we have a robust strategy for handling such corrections by the time the ILCTPC roles around.
Forum: Global Controls
Topic: General
General Thu, 31 May 2007 04:02
 carwardineMessages: 13Registered: May 2007 Location: Argonne National Laborato...
A place for posting discussion or questions not covered in other threads...
Topic: ATCA for physics applications
ATCA for physics applications Thu, 31 May 2007 03:43
 carwardineMessages: 13Registered: May 2007 Location: Argonne National Laborato...
This topic is intended for discussions relating to using ATCA in physics applications.

Sub-topics might include:
1. ATCA profiling ("prefered implementations")
2. ATCA for instrumentation
3. ATCA/Control system integration

Topic: Issues and unknowns that need to be resolved before completing the EDR
Issues and unknowns that need to be resolved before completing the EDR Thu, 31 May 2007 01:43
 carwardineMessages: 13Registered: May 2007 Location: Argonne National Laborato...

1. Control system scalability

2. How to make cost-conscious decisions on the control system design

3. How do we manage a global controls project? Controls, interfaces with technical systems, standardization,…

4. How do we make it possible for [algorithms, hardware, software components etc] to be tested & integrated at different facilities? Issues are: interfaces, portability, interoperability, standards,…

Topic: Instructions for registering and using forum.linearcollider.org
Instructions for registering and using forum.linearcollider.org Sun, 27 May 2007 16:04
 tonyjMessages: 138Registered: January 2004
I have written up some additional instructions on how to register with and use the forum.linearcollider.org web site. You can find these instructions at:

http://confluence.slac.stanford.edu/x/d4Q

These instructions are meant to complement the help built-in to the forum web site.

Feedback and suggestions are welcome.

[Updated on: Wed, 06 June 2007 00:16]

Topic: Two and only two EDRs?
Two and only two EDRs? Thu, 24 May 2007 06:16
 yhitoshiMessages: 3Registered: May 2007
Dear all,

There seem to be two arguments about the number of EDRs to write for 2010. One argues for two and only two EDRs, while the other allows more to come. Two and only two is simpler, and whoever is already one the two may feel more secure and also thus easier to get funding. On the other hand, it may discourage more people to join with possibly a better idea. The resources are limitted, but it may be possible that at some later time, a chunk of human and financial resources are released from other experiments that a group with enough capability to write an EDR may emerge. Thus, I believe that it is a bit premature to limit the number of EDR to two and only two from now to the realization of ILC. We can aim for two EDR for 2010 for now, but we can allow for more to come.

Best

- Hitoshi
Topic: Charater of Research Director
Charater of Research Director Thu, 24 May 2007 06:06
 yhitoshiMessages: 3Registered: May 2007
Dear all,

I would like to express my opinion about the character of the Research Director.
Since this is a single person who works nearly full time on this task, it may seem
that this peson will have a huge power to shape the organization the detector/physics community. To some extent, it may be true, but there are already 'horizontal' collaborations such as LCTPC, CALICE, SiLC etc., and it would not be a good idea to dismantle these organization. So there will be limit to how much the
R&D organization can be changed even though I think the horizontal efforts need to be reinforced rather than discouraged for the near future through the formation of proto-collaborations. Also, there are already concepts now, and then LOI and associated proto-collaborations, and Research Director should deal with them as they are. So, the role of Research Director is a highly-diplamatic facilitator, even through he/she can be a strong leader as such.

Best

- Hitoshi
Topic: document summarizing the preliminary views of the WWS co-chairs on a possible roadmap for detectors
document summarizing the preliminary views of the WWS co-chairs on a possible roadmap for detectors Tue, 22 May 2007 12:45
 jimbrauMessages: 1Registered: May 2007
No Message Body

Forum: Beam Optics Design, Beam Collimation, Final Doublet.
Topic: Optics and lasers
Optics and lasers Mon, 29 January 2007 19:06
 lens33Messages: 1Registered: January 2007
A really cool application of precision lens is lasers. www.dragonlasers.com is on of the cheapest quality online laser sellers.

I've bought one of their lasers so i know this for a fact. If you do buy one of their lasers, mention the name Matthew M. I'm trying to build up some credibility there.

[Updated on: Mon, 29 January 2007 19:07]

Pages (7): [ «    1  2  3  4  5  6  7    »]

Current Time: Wed Feb 26 20:48:55 Pacific Standard Time 2020
.:: Contact :: Home ::.