In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
A.Gheata presented the status of the new Geometrical Modeler. N.Van
Eijndhoven asked what would be the choice to be made when the modeler
would be fully implemented. F.Carminati answered that we should
abandon all the other geometrical packages and use the new
one. F.Rademakers asked about the cumulative timescale of the project:
there was no precise estimation, but the main work should be done
before the end of the summer.
I.Hrivnacova gave a talk on the AliRoot - Fluka
integration. F.Carminati asked what should be done in order to use the
Geant4 geometry. One has to verify the changes in the geometry of some
detectors and merge them with the updated CVS version.
I. Gonzalez showed the results of the Geant4 hadronic tests. There was
a clear difference between the experimental and simulated
distributions. He was asked whether the discrepancy could partially be
explained with the normalization. The answer was negative.
Kalman filter parameterisation for TPC20m
A.Dainese presented his work on a Kalman track parametrization in
TPC. N.DiBari asked if the difference in the covariance matrix for
pions and kaons was important for the charm studies. No, because it
affects only the low momenta. K.Safarik asked about the efficiency
checks. There was a difference around dead regions in the TPC, which
were passive in the simulation and no first hit was available.
K.Safarik noted that one could play with the vertex constraint due to
the presence of bremsstrahlung.
Question by A. Morsch:
How you use the TGeant3 Geometry?
Answ: We need the GEANT3 geometry during the geometrical propagation of
the extracted TPC tracks in order to know if, at a given step, the
particle reach the TOF detector and, if yes, the identifier of current
volume (e.g. if it is a TOF sensitive volume or not et cetera).
This is the reason why the TOF reconstruction needs to create an instance
of the ALICE geometry (gAlice->Init() ). Considering also that geometry
has to be known only for TOF detector, usually, in the Config.C, only the frame
and the TOF detector are switched on.
Question by Ivana Hrivnacova:
Concerning this point, what are the GEANT functions are you using?
Answ: The GEANT function which we are using are:
Ivana:It would be usefull to put this method on a more basic level (e.g.
Answ: Yes, of course, I will send to You the code with some comment
explaining exactly our needs.
Question by D. Di Bari:
Concerning the probabilistic approach to particle identification, the
contour cuts you are using for PID will be replaced by the amplitude
Answ: Yes, of course, it is only the present status of the code. We will
move to probabilistic phylosophi for PID asap.
Question by A. Dainese:
Fabrizio, this slide is sayng that you can use different contour cuts for
Answ: Yes, in fact, I said that the AliTOFPID class has only (as data
member) the pointer to external file containing cuts.
A. Dainese: could you provide the std contour cuts in CVS?
Answ: Yes, of course, we will commit asap the std contour cuts used for
Pb-Pb and pp PID.
A. Dainese: But in any case, the AliTOFPID class uses the output of the
Answ: Yes Andrea, we can provide to You the reconstructed data. In any
case the code for the TOF reconstruction will be committed in few days.
Remark by K.Safarik:
Why You do not use Kalman tracking for the matching, the method for the
Kalman propagation till external detectors is already available?
Answ: This is a good new. If You provide this method, we can move to
Kalman quickly. Please, can we meet?
Remark by K.Safarik:
Concerning the event time zero determination, there is not longer need to
use a combinatorial algorithm (which is bad), you can use the time zero
calculated from all identified pions -> In this way, due to the high
statistics, you can get in principle a resolution
Answ: Yes, but I'd like to verify this formula. The current combinatorial
algorithm do not use PID (because it can be used also for PID). Please
remember that if You take all identified pions, You get also
identified pions -but matched with a wrong time, due to noise- and this
can to make worse Your resolution for the event time zero determination.
In any case I will try and I will let You know.
Question by P. Hristov:
Could You provide a set of test macros for TOF?
Answ: Yes Peter, I promise ;)
G.LoRe spoke about the status of V0 finding within the version 1 of
ITS tracking. Y.Foka asked about the differences between the current
approach and one presented by the Strasbourg group. The same
reconstruction was used, but HIJING generator was used instead of the
parametrization. M.Kowalski asked about the two possible solutions in
case of helix tracking. It might happened, but usually the second
solution is too far from the vertex and could be easily identified.
N.DiBari asked how the track weights were taken into account. They
were not, the mid-point was considered as vertex. The cut on the
distance was not momentum-dependent, so the multiple scattering was
not taken into account. M.Kowalski pointed to another consequence of
the multiple scattering; the distribution on Y-coordinate has
non-gaussian tails. A small discrepancy in the estimated number of K0
with the talk of Y.Belikov was due to the different
definitions. Y.Foka suggested to apply uniform definitions in order to
compare the results.
A.Pulvirenti presented a neural network approach to the tracking in
ITS. B.Nilsen proposed to reduce the size of the network by applying
it only within a segment. B.Batunia asked what was the source of
increased efficiency with respect to the previous results. The
improvement is due to the tracks without TPC prolongation.
A.Morsch showed the simulation status. B.Nilsen asked if the MUON
dipole field was included: yes, it was. There was also a question on
the pp charm tuning. It was done with PbPb events for the nucleon
parton structure functions.
F.Rademakers spoke about the framework status. J.Chudoba asked whether
Proof could be used both for interactive and batch jobs. It could be
used since the load is dynamic and the result will not depend on the
slowest node. P.Buncic described some possible problems in the
simulation related to the fact that our unit is one event.
K.Safarik gave a talk on the reconstruction. B.Nilsen asked about the
definition of a good track in ITS. The 6 points requirement is used in
order to compare with the old results, but it doesn't fully correspond
to the expected efficiency for a given signal. One has to study the
isolation cuts, etc. The reconstruction efficiency is important also
for event-by-event analysis and should be as good as possible.