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:
My impression was that people were happy to see these proposed recommendations and were open to the idea of having a shared convention between the LHC experiments.
I had comments from:
- Comment: problem not listed is that definitions of histograms between Rivet and HEPdata are not the same. Have identified several analyses where they diverge.
--> I answered that there is an ongoing effort to sync HEPdata/Rivet databases, and that in principle they should be the same!
- Question: what is the best format to use to save all the data. As we go we save more and more data, and the problems are how do we efficiently process etc eg format like Panda ? is there discussion in that directio?
--> I answered that there has not been too much discussion about the exact format, but that we are doing a lot of work on the "workflow" which is perhaps the key point/
- Comment: is there a push to preserve information for searches? how does this relate to RECAST?
--> I answered that there is an interplay between Rivet (with Smearing) and RECAST for searches: one is faster but can only handle selections defined on kinematic observables, the other is more heavy/slow but can handle in principle any selection. Work in ongoing in both cases.
- Comment: what is the status of the TH*DBootstrap code being made public?
--> I answered that there are some last items such as understanding who will maintain the code, and perhaps writing a short note, but that things are moving and I expect the code the be made public in the next months.
I had a follow up question from Steve Mrenna by email who asked when he could join our meetings and was interested to know if there was/is a case study we could put together of what the effect of using/not using correlation info has on e.g. PDF fitting. I think he will try to join today's meeting!
Since ALICE is now also producing jet measurements, maybe one could
involve them also in the discussion ?
Ideas for future studies20m
(Centre National de la Recherche Scientifique (FR))