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:
EVO video-conference: community="WLCG", title="Generator Services project planning".
Phone Bridge ID number: 530749
Report and planning1h
Minutes (written by A. Ribon) of the LCG Generator Services
planning meeting on 28 November 2008.
People attending in room 32-1-A24:
- Paolo Bartalini (PB)
- Gabriele Cosmo (GCO)
- Gloria Corti (GC)
- Lev Dudko (LD)
- Slava Ilyin (SI)
- Osamu Jinnouchi (OJ)
- Mikhail Kirsanov (MK)
- Pere Mato (PM)
- Alberto Ribon (AR)
- Oleg Zenin (OZ)
People attending remotely via EVO or telephone:
- Andy Buckley (AB)
- David Grellscheid (DG)
- Judith Katzy (JK)
- Frank Krauss (FK)
- Peter Richardson (PR)
People who could not partecipate but sent comments via e-mail:
- Lars Sonnenschein (LS)
- Torbjorn Sjostrand (TS)
AR presented the status of the ongoing activities in the LCG Generator
Services subproject since the last planning meeting (23 May 2008),
and the plan of work for the next 6 months.
Comments to the slides
1) Comments to slide #8 ("Building generators with autotools")
a) TS (via e-mail) commented that we should keep in parallel,
for a while, the two building mechanisms for GENSER: the
current one, and new one based on autotools.
This will allow to properly test the new building system,
while ensuring a smooth and safe transition.
b) AR agreed and confirmed that this is exactly the way we
will migrate to the new building system.
2) Comments to slide #10 ("Inconsistencies of GENSER libraries")
a) AB and DG commented that if not a proper versioning of GENSER,
at least a better directory structure could already be an
improvement with respect to the current, flat structure.
b) AR agrees that there is certainly room for improvement on the
structure of GENSER, but it is not obvious how to do so in
practice if we want to stay with a simple structure, without
deleting old versions, and without using too much AFS disk
space, which amounts now to already 20 GB.
c) JK commented that keeping a simple structure in GENSER is
quite convenient for the experiments.
Decision : as far as ATLAS and LHCb use the same HepMC version
-------- we stay with the current structure of GENSER; else
we will evaluate what can be done.
3) Comments on slide #11 ("Progress report: Validation")
[ HepMC Analysis Tool has been discussed extensively due
to the fact that, when it has been presented at the
LCG Generator Services monthly meeting on November 5th,
EVO was not working properly and so people outside CERN
were not able to comment and ask questions.
What is reported here is only a short summary of what
has been discussed. ]
a) AB, DG, and FK said that Rivet can be used for regression testing
and this is the preferred choice for the MC codes represented
in MCnet (Ariadne, Herwig++, Pythia8, Sherpa).
If someone experiences some difficulties in using Rivet, the
authors should be contacted to get help and assistence.
b) AR and JK expect that HepMC Analysis Tool is simpler and
easier to use than Rivet for regression testing (i.e. for
comparing two generators), whereas Rivet power is justified
for data validation and tuning.
Decision : both approaches, Rivet and HepMC Analysis Tool should
-------- be evaluated for regression testing.
A meeting between all the interested parties (Rivet
authors and users; HepMC Analysis Tool authors;
GENSER developers) should be organized to discuss
4) Comments on slide #12 ("Progress report: HepMC")
a) AR proposed (see older version of the slides) to consider the
possibility of "urgent request for HepMC changes", namely
requests that are not bug-fixes and cannot wait the annual
meeting where we should discuss new HepMC releases.
b) FK commented that we should avoid any change of HepMC that
is not properly discussed and accepted by all users, given
its potential impacts in several areas.
All partecipants agreed.
c) PB, GC, and PM proposed to have the meeting to discuss new
HepMC releases every 6 months instead of once per year.
However, we should try anyhow to have only one major release
per year, with eventually a minor release after 6 months
only if needed.
It would be useful for the experiments, in order to better
plan their migration to a newer HepMC version, to have the
meeting on HepMC 2.05 sometimes in January (so early than
the original proposal for March).
Decision : in general, HepMC meetings should occurred every 6 months,
-------- with one major release per year, plus eventually
one minor release.
The HepMC 2.05 meeting will be held on Wednesday 28 January.
5) Comments on slide #15 ("Proposed plan")
a) DG (and LS via e-mail) asked which is the timetable for the
migration to SLC5.
b) PM answered that we have to be ready for SLC5 at the
beginning of 2009, although the actual date when the
migration will happen is not known now, and it will be
be decided by the experiments.