| Forum: slic |
|---|
| Topic: lcdd 1.12 released |
|---|
|
| Topic: slic 2.1 released |
|---|
|
| Topic: slic 2.0 |
|---|
| slic 2.0 [message #636] |
Mon, 13 November 2006 12:31 |
jeremy
Messages: 46
Registered: 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 [message #348] |
Thu, 08 September 2005 07:10 |
karyotak
Messages: 2
Registered: 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
(Size: 29.18KB, Downloaded 2334 times)
|
|
|
| Topic: New SLIC and LCDD Releases |
|---|
|
| Forum: Full Simulations |
|---|
| Topic: Protoype Simulation - Cell Numbering and Coordinate Frames |
|---|
|
| Topic: Simulation Requirements Document |
|---|
| Simulation Requirements Document [message #99] |
Thu, 27 May 2004 08:31 |
dhiman
Messages: 2
Registered: 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
NIU/NICADD
[Updated on: Thu, 27 May 2004 08:54]
|
|
|
| Forum: Individual Particle Reconstruction |
|---|
| Topic: TrivialPFA.java not in examples |
|---|
| TrivialPFA.java not in examples [message #1507] |
Fri, 13 June 2008 14:57 |
manly
Messages: 21
Registered: 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 |
|---|
|
| Forum: org.lcsim |
|---|
| Topic: GeomConverter, 'conditions set not found: SamplingFractions/EcalEndcap' |
|---|
| GeomConverter, 'conditions set not found: SamplingFractions/EcalEndcap' [message #2268] |
Tue, 09 July 2013 15:44 |
aconway
Messages: 7
Registered: 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 [message #1837] |
Fri, 14 August 2009 17:04 |
jeremy
Messages: 46
Registered: 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 [message #1376] |
Fri, 01 February 2008 11:31 |
bjasper
Messages: 33
Registered: 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 |
|---|
|
| Topic: Acessing files created with sid01_polyhedra geometry |
|---|
| Acessing files created with sid01_polyhedra geometry [message #1106] |
Fri, 14 September 2007 15:08 |
wenzel
Messages: 25
Registered: 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
Exception in thread "main" java.lang.RuntimeException: Error reading detector co
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.lcsim.util.DriverAdapter.recordSupplied(DriverAdapter.ja va:70)
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.geometry.GeometryReader.read(GeometryReader.java:5 6)
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 |
|---|
|
| Topic: Driver for the trf track finder package |
|---|
| Driver for the trf track finder package [message #712] |
Mon, 12 February 2007 08:38 |
wenzel
Messages: 25
Registered: 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 [message #629] |
Mon, 23 October 2006 12:50 |
tonyj
Messages: 138
Registered: 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 [message #924] |
Wed, 20 June 2007 05:36 |
antonio.bulgheroni
Messages: 66
Registered: 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 [message #870] |
Wed, 23 May 2007 04:54 |
antonio.bulgheroni
Messages: 66
Registered: 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 |
|---|
|
| Topic: Important steps toward the EUDET telescope analysis |
|---|
| Important steps toward the EUDET telescope analysis [message #721] |
Mon, 19 February 2007 06:17 |
antonio.bulgheroni
Messages: 66
Registered: 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 [message #1885] |
Thu, 15 October 2009 08:05 |
bweinert
Messages: 16
Registered: 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 [message #1820] |
Tue, 28 July 2009 08:22 |
bweinert
Messages: 16
Registered: 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];
VirtPosList.add(VirtPos);
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])));
MatchedPosList.add(realPos);
foundHits.add(new BasicHep3Vector(realPos[0],
realPos[1], realPos[2]));
nhitsTotal++;
MatchedPosList.add(realPos);
}
} } }
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])));
MatchedPosList.add(realPos);
foundHits.add(new BasicHep3Vector(realPos[0],
realPos[1], realPos[2]));
nhitsTotal++;
MatchedPosList.add(realPos);
}
} }}
}
}
|
|
|
| Topic: Registering and using forum.linearcollider.org |
|---|
|
| Forum: Announcements |
|---|
| Topic: Transition from CVS to SVN |
|---|
| Transition from CVS to SVN [message #1821] |
Mon, 03 August 2009 05:04 |
engels
Messages: 106
Registered: 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 [message #667] |
Wed, 31 January 2007 09:42 |
tonyj
Messages: 138
Registered: 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 |
|---|
|
| Topic: LCIO v01-03 released |
|---|
|
| Topic: Announcing WIRED 4 Version 4.0.beta.1 |
|---|
| Announcing WIRED 4 Version 4.0.beta.1 [message #138] |
Thu, 09 September 2004 15:10 |
duns
Messages: 2
Registered: 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
modules, read data from:
- 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 |
|---|
|
| Topic: New URL |
|---|
| New URL [message #9] |
Thu, 22 January 2004 21:15 |
NormanGraf
Messages: 80
Registered: January 2004 |
|
|
|
|
We're now live at forum.linearcollider.org!
|
|
|
| Forum: LC-TPC |
|---|
| Topic: Ion Effects |
|---|
| Ion Effects [message #939] |
Thu, 28 June 2007 03:24 |
wiene
Messages: 23
Registered: 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
Adrian - TPC occupancies
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 [message #891] |
Thu, 31 May 2007 04:02 |
carwardine
Messages: 13
Registered: 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 [message #889] |
Thu, 31 May 2007 03:43 |
carwardine
Messages: 13
Registered: May 2007
Location: Argonne National Laborato... |
|
|
|
This topic is intended for discussions relating to using ATCA in physics applications.
Sub-topics might include:
- ATCA profiling ("prefered implementations")
- ATCA for instrumentation
- 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 [message #881] |
Thu, 31 May 2007 01:43 |
carwardine
Messages: 13
Registered: May 2007
Location: Argonne National Laborato... |
|
|
|
Please add to this list as you see fit...
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,…
|
|
|
| Forum: ILC Detector Roadmap |
|---|
| Topic: Instructions for registering and using forum.linearcollider.org |
|---|
|
| Topic: Two and only two EDRs? |
|---|
| Two and only two EDRs? [message #874] |
Thu, 24 May 2007 06:16 |
yhitoshi
Messages: 3
Registered: 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 [message #872] |
Thu, 24 May 2007 06:06 |
yhitoshi
Messages: 3
Registered: 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 |
|---|
|
| Forum: Beam Optics Design, Beam Collimation, Final Doublet. |
|---|
| Topic: Optics and lasers |
|---|
| Optics and lasers [message #664] |
Mon, 29 January 2007 19:06 |
lens33
Messages: 1
Registered: 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]
|
|
|
Members
Search
Help
Register
Login
Home
