contributions/atlas/atlas.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\begin{document}
+\title{The ATLAS Experiment at the INFN CNAF Tier 1}
+
+\author{A. De Salvo$^1$,  L. Rinaldi$^2$}
+
+\address{$^1$ INFN Sezione di Roma-1, Roma, IT} 
+\address{$^2$ Universit\`a di Bologna e INFN Sezione di Bologna, Bologna, IT}
+
+\ead{alessandro.desalvo@roma1.infn.it, lorenzo.rinaldi@bo.infn.it}
+
+\begin{abstract}
+The ATLAS experiment at LHC was fully operating in 2017. In this contribution we describe the ATLAS computing activities performed in the Italian sites of the Collaboration, and in particular the utilisation of the CNAF Tier 1.
+\end{abstract}
+
+\section{Introduction}
+
+   
+ATLAS \cite{ATLAS-det} is one of two general-purpose detectors at the Large Hadron Collider (LHC). It investigates a wide range of physics, from the search for the Higgs boson and standard model studies to extra dimensions and particles that could make up dark matter. Beams of particles from the LHC collide at the center of the ATLAS detector making collision debris in the form of new particles, which fly out from the collision point in all directions. Six different detecting subsystems arranged in layers around the collision point record the paths, momentum, and energy of the particles, allowing them to be individually identified. A huge magnet system bends the paths of charged particles so that their momenta can be measured. The interactions in the ATLAS detectors create an enormous flow of data. To digest the data, ATLAS uses an advanced trigger system to tell the detector which events to record and which to ignore. Complex data-acquisition and computing systems are then used to analyse the collision events recorded. At 46 m long, 25 m high and 25 m wide, the 7000-tons ATLAS detector is the largest volume particle detector ever built. It sits in a cavern 100 m below ground near the main CERN site, close to the village of Meyrin in Switzerland.
+More than 3000 scientists from 174 institutes in 38 countries work on the ATLAS experiment.
+ATLAS has been taking data from 2010 to 2012, at center of mass energies of 7 and 8 TeV, collecting about 5 and 20 fb$^{-1}$ of integrated luminosity, respectively. During the complete Run-2 phase (2015-2018) ATLAS collected and registered at the Tier 0 147 fb$^{-1}$ of integrated luminosity at center of mass energies of 13 TeV.
+The experiment has been designed to look for New Physics over a very large set of final states and signatures, and for precision measurements of known Standard Model (SM) processes. Its most notable result up to now has been the discovery of a new resonance at a mass of about 125 GeV \cite{ATLAS higgs}, followed by the measurement of its properties (mass, production cross sections in various channels and couplings). These measurements have confirmed the compatibility of the new resonance with the Higgs boson, foreseen by the SM but never observed before.
+
+
+
+\section{The ATLAS Computing System}
+
+ 
+ 
+ The ATLAS Computing System \cite{ATLAS-cm} is responsible for the provision of the software framework and services, the data management system, user-support services, and the world-wide data access and job-submission system. The development of detector-specific algorithmic code for simulation, calibration, alignment, trigger and reconstruction is under the responsibility of the detector projects, but the Software and Computing Project plans and coordinates these activities across detector boundaries. In particular, a significant effort has been made to ensure that relevant parts of the “offline” framework and event-reconstruction code can be used in the High Level Trigger. Similarly, close cooperation with Physics Coordination and the Combined Performance groups ensures the smooth development of global event-reconstruction code and of software tools for physics analysis.
+
+\subsection{The ATLAS Computing Model}
+The ATLAS Computing Model embraces the Grid paradigm and a high degree of decentralisation and sharing of computing resources. The required level of computing resources means that off-site facilities are vital to the operation of ATLAS in a way that was not the case for previous CERN-based experiments. The primary event processing occurs at CERN in a Tier 0 Facility. The RAW data is archived at CERN and copied (along with the primary processed data) to the Tier 1 facilities around the world. These facilities archive the raw data, provide the reprocessing capacity, provide access to the various processed versions, and allow scheduled analysis of the processed data by physics analysis groups. Derived datasets produced by the physics groups are copied to the Tier 2 facilities for further analysis. The Tier 2 facilities also provide the simulation capacity for the experiment, with the simulated data housed at Tier 1 centers. In addition, Tier 2 centers provide analysis facilities, and some provide the capacity to produce calibrations based on processing raw data. A CERN Analysis Facility provides an additional analysis capacity, with an important role in the calibration and algorithmic development work. ATLAS has adopted an object-oriented approach to software, based primarily on the C++ programming language, but with some components implemented using FORTRAN and Java. A component-based model has been adopted, whereby applications are built up from collections of plug-compatible components based on a variety of configuration files. This capability is supported by a common framework that provides common data-processing support. This approach results in great flexibility in meeting both the basic processing needs of the experiment, but also for responding to changing requirements throughout its lifetime. The heavy use of abstract interfaces allows for different implementations to be provided, supporting different persistency technologies, or optimized for the offline or high-level trigger environments.
+The Athena framework is an enhanced version of the Gaudi framework that was originally developed by the LHCb experiment, but is now a common ATLAS-LHCb project. Major
+design principles are the clear separation of data and algorithms, and between transient (in-memory) and persistent (in-file) data. All levels of processing of ATLAS data, from high-level trigger to event simulation, reconstruction and analysis, take place within the Athena framework; in this way it is easier for code developers and users to test and run algorithmic code, with the assurance that all geometry and conditions data will be the same for all types of applications ( simulation, reconstruction, analysis, visualization).
+One of the principal challenges for ATLAS computing is to develop and operate a data storage and management infrastructure able to meet the demands of a yearly data volume of O(10PB) utilized by data processing and analysis activities spread around the world.  The ATLAS Computing Model establishes the environment and operational requirements that ATLAS data-handling systems must support and provides the primary guidance for the development of the data management systems.
+The ATLAS Databases and Data Management Project (DB Project) leads and coordinates ATLAS activities in these areas, with a scope encompassing technical data bases (detector production, installation and survey data), detector geometry, online/TDAQ databases, conditions databases (online and offline), event data, offline processing configuration and bookkeeping, distributed data management, and distributed database and data management services. The project is responsible for ensuring the coherent development, integration and operational capability of the distributed database and data management software and infrastructure for ATLAS across these areas.
+The ATLAS Computing Model defines the distribution of raw and processed data to Tier 1 and Tier 2 centers, so as to be able to exploit fully the computing resources that are made available to the Collaboration. Additional computing resources are available for data processing and analysis at Tier 3 centers and other computing facilities to which ATLAS may have access. A complex set of tools and distributed services, enabling the automatic distribution and processing of the large amounts of data, has been developed and deployed by ATLAS in cooperation with the LHC Computing Grid (LCG) Project and with the middleware providers of the three large Grid infrastructures we use: EGI, OSG and NorduGrid. The tools are designed in a flexible way, in order to have the possibility to extend them to use other types of Grid middleware in the future.
+The main computing operations that ATLAS have to run comprise the preparation, distribution and validation of ATLAS software, and the computing and data management operations run centrally on Tier 0, Tier 1 sites and Tier 2 sites. The ATLAS Virtual Organization allows production and analysis users to run jobs and access data at remote sites using the ATLAS-developed Grid tools.
+The Computing Model, together with the knowledge of the resources needed to store and process each ATLAS event, gives rise to estimates of required resources that can be used to design and set up the various facilities. It is not assumed that all Tier 1 sites or Tier 2 sites are of the same size; however, in order to ensure a smooth operation of the Computing Model, all Tier 1 centers usually have broadly similar proportions of disk, tape and CPU, and similarly for the Tier 2 sites.
+The organization of the ATLAS Software and Computing Project reflects all areas of activity within the project itself. Strong high-level links are established with other parts of the ATLAS organization, such as the TDAQ Project and Physics Coordination, through cross-representation in the respective steering boards. The Computing Management
+Board, and in particular the Planning Officer, acts to make sure that software and computing developments take place coherently across sub-systems and that the project as a whole meets its milestones. The International Computing Board assures the information flow between the ATLAS Software and Computing Project and the national resources and their Funding Agencies.
+
+
+
+\section{The role of the Italian Computing facilities in the global ATLAS Computing}
+
+Italy provides Tier 1, Tier 2 and Tier 3 facilities to the ATLAS collaboration. The Tier 1, located at CNAF, Bologna, is the main center, also referred as “regional” center. The Tier 2 centers are distributed in different areas of Italy, namely in Frascati, Napoli, Milano and Roma. All 4 Tier 2 sites are considered as Direct Tier 2 (T2D), meaning that they have an higher importance with respect to normal Tier 2s and can have primary data too. They are also considered satellites of the Tier 1, also identified as nucleus. The total of the Tier 2 sites corresponds to more than the total ATLAS size at the Tier 1, for what concerns disk and CPUs; tape is not available in the Tier 2 sites. A third category of sites is the so-called Tier 3 centers. Those are smaller centers, scattered in different places in Italy, that nevertheless contributes in a consistent way to the overall computing power, in terms of disk and CPUs. The overall size of the Tier 3 sites corresponds roughly to the size of a Tier 2 site. The Tier 1 and Tier 2 sites have pledged resources, while the Tier 3 sites do not have any pledge resource available.
+In terms of pledged resources, Italy contributes to the ATLAS computing as 9\% of both CPU and disk for the Tier 1. The share of the Tier 2 facilities corresponds to 7\% of disk and 9\% of CPU of the whole ATLAS computing infrastructure. The Italian Tier 1, together with the other Italian centers, provides both resources and expertise to the ATLAS computing community, and manages the so-called Italian Cloud of computing. Since 2015 the Italian Cloud does not only include Italian sites, but also Tier 3 sites of other countries, namely South Africa and Greece.
+The computing resources, in terms of disk, tape and CPU, available in the Tier 1 at CNAF have been very important for all kind of activities, including event generation, simulation, reconstruction, reprocessing and analysis, for both MonteCarlo and real data. Its major contribution has been the data reprocessing, since this is a very I/O and memory intense operation, normally executed only in Tier 1 centers. In this sense CNAF has played a fundamental role for the fine measurement of the Higgs [3] properties in 2018 and other analysis. The Italian centers, including CNAF, have been very active not only in the operation side, but contributed a lot in various aspect of the Computing of the ATLAS experiment, in particular for what concerns the network, the storage systems, the storage federations and the monitoring tools. The Tier 1 at CNAF has been very important for the ATLAS community in 2018, for some specific activities:
+
+\begin{itemize}
+\item improvements on the WebDAV/HTTPS access for StoRM, in order to be used as main renaming method for the ATLAS files in StoRM and for http federation purposes;
+\item improvements of the dynamic model of the multi-core resources operated via the LSF resource management system and simplification of the PanDA queues, using the Harvester service to mediate the control and information flow between PanDA and the resources.
+\item network troubleshooting via the Perfsonar-PS network monitoring system, used for the LHCONE overlay network, together with the other Tier 1 and Tier 2 sites;
+\item planning, readiness testing and implementation of the HTCondor batch system for the farming resources management.
+\end{itemize}
+
+\section{Main achievements of ATLAS Computing centers in Italy}
+
+The Italian Tier 2 Federation runs all the ATLAS computing activities in the Italian cloud supporting the operations at CNAF, the Italian Tier 1 center, and the Milano, Napoli, Roma1 and Frascati Tier 2 sites. This insures an optimized use of the resources and a fair and efficient data access.  The computing activities of the ATLAS collaboration have been constantly carried out over the whole 2018, in order to analyse the data of the Run-2 and produce the Monte Carlo data needed for the 2018 run.
+ 
+The LHC data taking started in April 2018 and, until the end of the operation in December 2018, all the Italian sites, the CNAF Tier 1 and the four Tier 2 sites, have been involved in all the computing operations of the collaboration: data reconstruction, Monte Carlo simulation, user and group analysis and data transfer among all the sites. Besides these activities, the Italian centers have contributed to the upgrade of the Computing Model both from the testing side and the development of specific working groups. ATLAS collected and registered at the Tier 0 ~60.6 fb$^{-1}$ and ~25 PB of raw and derived data, while the cumulative data volume distributed in all the data centers in the grid was of the order of ~80 PB. The data has been replicated with an efficiency of 100\% and an average throughput of the order of ~13 GB/s during the data taking period, with peaks above 25 GB/s. For just Italy, the average throughput was of the order of 800 MB/s with peaks above 2GB/s. The data replication speed from Tier 0 to the Tier 2 sites has been quite fast with a transfer time lower than 4 hours. The average number of simultaneous jobs running on the grid has been of about 110k for production (simulation and reconstruction) and data analysis, with peaks over 150k, with an average CPU efficiency up to more than 80\%. The use of the grid for analysis has been stable on ~26k simultaneous jobs, with peaks around the conferences’ periods to over 40k, showing the reliability and effectiveness of the use of grid tools for data analysis.
+ 
+The Italian sites contributed to the development of the Xrootd and http/webdav federation. In the latter case the access to the storage resources is managed using the http/webdav protocol, in collaboration with the CERN DPM team, the Belle2 experiment, the Canadian Corporate Cloud ant the RAL (UK) site. The purpose is to build a reliable storage federation, alternative to the Xrootd one, to access physics data both on the grid and on cloud storage infrastructures (like Amazon S3, MicroSoft Azure, etc). The Italian community is particularly involved in this project and the first results have been presented to the WLCG collaboration.
+ 
+The Italian community also contributes to develop new tools for distributed data analysis and management. Another topic of interest is the usage of new computing technologies: in this field the Italian community contributed to the development and testing of muon tracking algorithms in the ATLAS High Level Trigger, using GPGPU. Other topics in which the Italian community is involved are the Machine Learning/Deep Learning for both analysis and Operational Intelligence and their applications to the experiment software and infrastructure, by using accelerators like GPGPU and FPGAs.
+ 
+The contribution of the Italian sites to the computing activities in terms of processed jobs and data recorded has been of about 9\%, corresponding to the order of the resource pledged to the collaboration, with very good performance in term of availability, reliability and efficiency. All the sites are always in the top positions in the ranking of the collaboration sites.
+ 
+Besides the Tier 1 and Tier 2 sites, in 2018 also the Tier 3 sites gave a significant contribution to the Italian physicists community for the data analysis. The Tier 3 centers are local farms dedicated to the interactive data analysis, the last step of the analysis workflow, and to the grid analysis over small data sample. Several italian groups set up a farm for such a purpose in their universities and, after a testing and validation process performed by the distributed computing team of the collaboration, all have been recognized as official Tier 3s of the collaboration.
+
+
+
+\section{Impact of CNAF flooding incident on ATLAS computing activities}
+
+
+
+The ATLAS Computing Model was designed to have a sufficient redundancy of the available resources in order to tackle emergency situations like the flooding occurred on November 9th 2017 at CNAF.  Thanks to the huge effort of the whole community of the CNAF,  the operativity of the data center restarted gradually from the second half of February 2018. A continuous interaction between ATLAS distributed computing community and CNAF people was needed to bring the computing operation fully back to normality. The deep collaboration was very successful and after one month the site was almost fully operational and the ATLAS data management and processing activities were running smoothly again. Eventually, the overall impact of the incident was limited enough, mainly thanks to the relatively quick recovery of the CNAF data center and to the robustness of the computing model.
+
+
+
+
+
+\section*{References}
+\begin{thebibliography}{9}
+
+\bibitem{ATLAS-det} The ATLAS Computing Technical Design Report ATLAS-TDR-017;
+CERN-LHCC-2005-022, June 2005
+
+\bibitem{ATLAS higgs} Observation of a new particle in the search for the Standard Model Higgs boson with the ATLAS detector at the LHC, the ATLAS Collaboration, Physics Letters B, Volume 716, Issue 1, 17 September 2012, Pages 1–29
+
+\bibitem{ATLAS-cm} The evolution of the ATLAS computing model; R W L Jones and D Barberis 2010 J. Phys.: Conf. Ser. 219 072037 doi:10.1088/1742-6596/219/7/072037
+
+
+
+
+
+
+\end{thebibliography}
+
+\end{document}
+
+
+
+
+
+

contributions/audit/Audit-2018.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\bibliographystyle{iopart-num}
+
+\begin{document}
+\title{Internal Auditing INFN for GDPR compliance}
+\author{V.~Ciaschini, P.~Belluomo}
+\address{INFN CNAF, Viale Berti Pichat 6/2, 40127, Bologna, Italy}
+\address{INFN sezione di Catania, Via Santa Sofia 64, 95123, Catania, Italy}
+
+\begin{abstract}
+With the General Data Protection Regulation (GDPR) coming into
+force, INFN had to decide how to implement its principles and
+requirements.  To monitor their application and in general INFN's
+compliance with GDPR, INFN created a new group, called ``Compliance
+Auditing,'' whose job is to be internal auditors for all structures.
+This article describes the startup activity for the group.
+\end{abstract}
+
+\section{Compliance Auditing Group}
+\subsection{GDPR Introduction}
+The GDPR, or EU Regulation 2016/679, is an European statute which aims
+to regulate collection and use of personal data.  This law introduces
+several innovation when compared to the previous law dealing with data
+protection.
+
+The GDPR predicates its data management phylosophy on a few high level
+principles, namely \emph{lawfulness}, \emph{fairness},
+\emph{transparency}, \emph{purpose limitation}, \emph{data
+  minimisation}, \emph{accuracy}, \emph{storage limitation},
+\emph{integrity and confidentiality} and finally
+\emph{accountability}, which are clearly delineated in the second
+chapter, with the rest of the law further characterizing and
+contestualizing them.
+
+Before delving any further, it is important to correctly define these principles:
+
+\begin{itemize}
+\item Lawfulness means that at any moment in time there must be a
+  valid legal justification for the treatment of personal data.
+  This can be an existing law that specifically allows a treatment,
+  or one from a set of reasons explicitly listed in the GDPR
+  itself.  If none of those applies, lawfulness may be granted by an
+  explicit permission for the owner of the data, permission that is
+  only valid for the specific treatment for which it was obtained.
+  Any further usage of the data requires a new explicit permission.
+
+\item Fairness and transparency mean that any usage of data must be
+  known the the owner, and such usage must be ``fair.''
+
+\item Purpose limitation means that data collected for a specific
+  purpose \emph{cannot} be used for any other purpose without an
+  explicit authorization.
+
+\item Data minimization means that only the data that is relevant for
+  the purpose for which it is collected must be collected and kept.
+
+\item Accuracy means that the data should be accurate and, if
+  necessary, kept up-to-date.  Data that is inaccurate should be
+  delated or corrected.
+
+\item Storage limitation means that data should not be kept in a form
+  that permits personal identification for longer than is required by
+  the purpose for which it was collected.
+
+\item Integrity and confidentiality means that all collected data must
+  be kept secret for all the time they are kept, and that they should
+  be preserved in a form that would preserve them from corruption.
+  Furthermore, measures must be taken to preempt disclosure, even just
+  accidental or as a consequence of a crime, to unauthorized persons.
+
+\item Accountability means that the entity or entities that decide
+  for what purpose data is collected and how it is processed is
+  responsible for, and must be able to demonstrate compliance with
+  GDPR.
+\end{itemize}
+
+The GDPR does not describe how, exactly, these principles should be
+implemented in practice, leaving instead full freedom on deciding how
+to satisfy them to the entities that are accountable for respecting
+it.
+
+It is therefore clear the disruptive effect of the regulation when
+compared to the existing Italian Privacy Law, (NNN) which instead
+clearly described a set of rules that \emph{had} to be respected.
+This means that the organization needs to implement a set of
+regulations and instruments to organize people with responsibilites
+and skills to handle, manage and check treatment of personal data.
+
+One organizational measure is actually mandated by GDPR, and it is a
+position of Data Protection Officer (DPO), which is an organization's
+representative managing dealings with external entities pertaining to
+personal data issues.  The DPO also has a consultative and reference
+role for the organization and all users when dealing with privacy
+issues.
+
+
+
+GDPR conformancye implementatio rests on five concepts that build and
+depend on each other like a wheel, as can be seen from the following
+figure:
+
+\includegraphics[width=.9\linewidth]{image.png}
+
+\subsubsection{Organization and Roles}
+Starting from the appointing of a DPO, the organizational model must
+be formally defined and organized in all its components, defining with
+precision roles and responsibilities for members of the organization
+in regard to direction and management of all privacy-related issues.
+
+\subsubsection{People, Culture and Skills}
+The organization designs and spreads the culture of data protection
+and security policies through training and other sensibilization
+activities.
+
+\subsubsection{Processes and Rules}
+Starting from a culture of security and data protection, Processes and
+rules are designed and implemented to ensure privacy by design, data
+portability, data breach management, data treatment register and
+others whose existence is mandated by GDPR.
+
+\subsubsection{Technologies and Tools}
+Technologies and Tools to implement the processes and rules defined in
+the previous point, e.g.: antivirus, firewalls, encipherment
+algorithms, identity management, etc... are chosen and put in
+production.
+
+\subsubsection{Control System}
+A monitoring system must be created to invigilate on the compliance of
+the organization to laws (e.g.: GDPR) and internal
+processes/regulamentation.  A key tool of this monitoring is the
+realization of audits, internal or external.
+
+
+\subsection{Rationale for creation}
+In the context of the required vigilance was a fundamental process for
+GDPR compliance, a group of people was formed in INFN, called
+``Compliance Auditing INFN'' whose duty is the verification of
+compliance with both external (e.g. GDPR) and internal (e.g. Norme per
+l'uso delle risorse informatiche) norms of the actual behaviour of the
+different INFN structures.
+
+Proposed in the first half of 2018, the group is staffed by Patrizia
+Belluomo (Lead Auditor, INFN Catania) and Vincenzo Ciaschini (Auditor,
+INFN CNAF) who have experience in auditing due to having ISO 27001
+certifications.
+
+\subsection{Startup Activity}
+
+\subsubsection{Operative Plan}
+The first activity undertaken by the group was a collection, followed
+by the study of all the norms applicable to INFN's implementation of
+GDPR, like the text of the normative itself, other applicable Italian
+legislation, the documents describing INFN's implementation, and
+several INFN regulations that, while not specifically talking about
+GDPR, still governed issues that were related to it, e.g data
+retention policies.
+
+Preparation for the audits entailed several months of study of the
+norms applicable to INFN's implementation, like the GDPR itself, other
+applicable Italian legislation, the documents describing INFN's
+implementation, and several INFN regulations that, while not
+specifically talking about GDPR, still governed issues that were
+related to it, e.g data retention policies.  From this, we
+extrapolated a set of indication ``possible requests index'' that we
+shared with all of the INFN structures that would receive an audit.
+
+Another fundamental step that in this case preceded the foundation of
+the group was the compilation by each INFN structure of a file
+(Minimal Measure Implementation) describing the implementation of a
+minimal set of security controls which were to be collected on an
+official CCR repository along with the corollary information that each
+section deemed necessary.
+
+We identified four main points that we had to evaluate:
+
+\begin{description}
+  \item[Data Discovery and Risk Assessment] Identify the personal data
+    kept by the structure and where it was stored or used.
+  \item[Protection] How the data is protected.
+  \item[Vigilance] How possible threats are discovered and how to
+    evaluate the extent of a security violation.
+  \item[Response] Incident Response Preparation and actions to
+    mitigate impact and reduce future risk.
+\end{description}
+
+
+\subsubsection{Official Documents Preparation}
+We decided to implement the audit according to the well known
+priciples in ISO 19011 standard.  To adapt that to INFN's
+specificities, we created a set of documents and procedures that would
+ensure uniformity of judgement and that would make results directly
+comparable among successive audits.
+
+We also setup a document repository, which would contain both the
+official documentation and the results of all audits of all structures
+that would be performed.  It is inside INFN's official document
+repository, Alfresco.
+
+\subsubsection{Audit Planning}
+According to the formal procedure, Audit Plans for INFN structures
+were formalized and scheduled, and we started contacting the various
+parts of INFN to share it.  The plan was to complete all audits in the
+first half of 2019, starting from January. Budgetary reasons forbade
+phisically traveling to al the cities that housed INFN, so most of
+the audits were planned to be done in telepresence, with only the 5
+that housed the most delicate data.
+
+
+\subsubsection{Structure Feedback}
+Finally, we defined a procedure to control the actions to undertake
+during the audit and how to receive feedback from INFN structures.
+
+\section{Conclusion}
+With all these work done, we were ready to start, and began
+in earnest January 9, 2019 with our first Audit, but that would be out
+of scope for 2018's Annual Report.
+\end{document}

contributions/borexino/Borexino_CNAFreport2018.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\begin{document}
+\title{The Borexino experiment at the INFN- CNAF}
+
+\author{Alessandra Carlotta Re$^1$\\ \small{on behalf of the BOREXINO collaboration}}
+\address{$^1$ Universit\`{a} degli Studi di Milano e INFN Sezione di Milano, Milano, IT}
+\ead{alessandra.re@mi.infn.it}
+
+\begin{abstract}  %OK
+Almost all the energy from the Sun is produced through sequences of nuclear reactions that convert hydrogen into helium. Five of these 
+processes emit neutrinos and represent a unique probe of the Sun's internal working.
+Borexino is a large volume liquid scintillator experiment designed for low energy neutrino detection, installed at the National 
+Laboratory of Gran Sasso (Assergi, Italy) and operating since May 2007. 
+Given the tiny cross-section of neutrino interactions with electrons ($\sigma ~ \approx 10^{-44}\,-\,10^{-45}~\mathrm{cm}^2$, for the
+solar neutrino energy range), the Borexino expected rates are very small. Despite that, the exceptional levels of radiopurity made possible 
+for Borexino to accomplish not only its primary goal but also to produce many other interesting results both within and beyond the Standard 
+Model of particle physics, helping a better understanding of the neutrino's features
+\end{abstract}
+ 
+\section{The Borexino experiment} %OK
+The Borexino experiment is located deep underground (3,800 meter water equivalent) in the Hall C of the National Laboratory of Gran Sasso (Assergi, Italy), and measures
+solar neutrinos via their interactions with a target of 278 ton organic liquid scintillator. The ultrapure liquid scintillator is contained inside a very thin transparent nylon vessel of 8.5 m diameter. 
+
+Solar neutrinos are detected by measuring the energy and position of electrons scattered by the neutrino-electron elastic interactions. 
+The scintillator promptly converts the kinetic energy of the electrons by emitting photons, which are then detected and converted into electronic signals by 2212 photomultipliers (PMT) mounted on a concentric 13.7 m diameter stainless steel sphere.
+
+The Borexino detector was designed exploiting the principle of graded shielding: an onion-like structure allows to shield from external radiations and from radiations produced in the external layers. The requirements on material radiopurity increase when moving to the innermost region of the detector.
+
+Starting from 2007 and through years, the Borexino \cite{ref:BxLong} experiment has been measuring the fluxes of low-energy neutrinos (neutrinos with energy $<3$ MeV), most notably those emitted in nuclear fusion reactions and $\beta$ decays along the pp-chain in the Sun. 
+ 
+
+\section{The Borexino recent results} %OK
+On January 2018, the Borexino collaboration released a detailed paper \cite{ref:BxMC} about the Monte Carlo (MC) simulation of its detector and the agreement of the MC output
+with the detector's acquired data. The simulation accounts for absorption, reemission, and scattering of the optical photons, tracking them until they either are absorbed or reach the photocathode of one of the photomultiplier tubes. These simulations were used and still are used, to study and reproduce the energy response of the detector, its uniformity within the fiducial scintillator volume relevant to neutrino physics, and the time distribution of detected photons to better than 1\% between 100 keV and several MeV. This work has been foundamental to all the Borexino analysis so far done.
+
+On October 2018, the collaboration published on Nature \cite{ref:BxNuSol} the latest solar neutrino result concerning a comprehensive measurement of all fluxes of the pp-chain solar neutrinos. This work is a milestone for solar neutrino physics since it provides the first, complete study of the solar pp-chain and of its different terminations in a single detector and with a uniform data analysis procedure. This study confirmed the nuclear origin of the solar power and provided the most complete real-time insight into the core of our Sun so far.
+
+The Borexino analysis is now focused on the possibility to measure the interaction rates of the rare CNO solar neutrinos.
+
+
+\section{The Borexino computing at CNAF} %OK
+The INFN-CNAF currently hosts the whole Borexino data statistics and the users' area for physics studies. 
+
+The Borexino data are classified into three types: 
+\begin{itemize}
+\item {\bf raw data~} Raw data are compressed binary files with a typical size of about 600 Mb corresponding to a data taking time of $\sim$6h. 
+\item {\bf ROOT files~~~~} ROOT files are files containing the Borexino reconstructed events, each organized in a {\tt ROOT TTree}: their typical dimension is  $\sim$1Gb. 
+\item {\bf DSTs~~~~~~~} DST files contain only a selection of events for the high level analyses.
+\end{itemize}
+ 
+Borexino standard data taking requires a disk space increase of about 10 Tb/year while a complete Monte Carlo simulation of both neutrino signals and backgrounds requires about 8 Tb/DAQ year.
+
+The CNAF TAPE area also hosts a full backup of the Borexino rawdata.
+
+Our dedicated front-end machine ({\tt ui-borexino.cr.cnaf.infn.it}) and pledged CPU resources (about 1500 HS06) are used by the Borexino collaboration for ROOT files production, Monte Carlo simulations, interactive and batch analysis jobs. 
+Moreover, few times a year, an extraordinary peak usage (up to 3000 HS06 at least) is needed in order to perform a full reprocessing of the whole data statistics with updated versions of the reconstruction code and/or a massive Monte Carlo generation.
+
+\section{Conclusions} %OK
+Borexino has been, so far, the only experiment able to perform a real-time spectroscopy of neutrinos from almost all the nuclear reactions happening in the Sun. Near future goals are mainly focused around improving its current limit of the CNO neutrino flux and possibly measure it. While the amount of CPUs resources needed is expected to remain quite stable, during next years the Borexino collaboration will increase its disk space requests so to successfully complete its challenging and very rich physics program.
+
+\section*{References}
+\begin{thebibliography}{9}
+\bibitem{ref:BxLong}  Bellini~G. {\it et al.} 2014~{\it Phys. Rev. D} {\bf 89} 112007.
+\bibitem{ref:BxMC}    Agostini~M. {\it et al.} 2018~{\it Astropart. Phys.} {\bf 97} 136.
+\bibitem{ref:BxNuSol} Agostini~M. {\it et al.} 2018~{\it Nature} {\bf 562} 505.
+\end{thebibliography}
+\end{document}
+

contributions/chnet/dhlab.tex

+\documentclass[a4paper]{jpconf}
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{graphicx}
+\usepackage{url}
+
+\begin{document}
+
+\title{DHLab: a digital library for the INFN Cultural Heritage Network}
+
+\author{F. Proietti$^1$, L. dell'Agnello$^1$, F. Giacomini$^1$}
+\address{$^1$ INFN-CNAF, Bologna, IT}
+\ead{fabio.proietti@cnaf.infn.it}
+
+\begin{abstract}
+
+  DHLab, as part of the Cultural Heritage Network (CHNet) promoted by
+  INFN, is a cloud-based environment to process, visualise and analyse
+  data acquired from members of the network and that will be provided
+  to technical and non-technical users. DHLab is under development and
+  currently its main features are a cloud service to upload and manage
+  the data, a form to assign metadata to uploaded datasets and a
+  service used to analyze data obtained from XRF measurements.
+
+\end{abstract}
+
+\section{Introduction}
+
+CHNet\footnote{http://chnet.infn.it/} is a network composed by several 
+INFN teams who devote their expertise in physics research to the study 
+and diagnostics of Cultural Heritage. By using their existing instruments, 
+developed for Nuclear Physics, or even by building new ones,
+INFN laboratories started to address the needs of archaeologists,
+historians, art historians, restorers and conservators. This unified
+knowledge can provide useful indications about the correct procedures
+to be applied for restoration or conservation, could be important to
+date or verify, for example, the authenticity of an artwork or study
+the provenance of raw material in order to retrace ancient trade
+routes. In this context the purpose of the DHLab is to host all the
+data acquired by the CHNet laboratories, together with the
+descriptions and annotations added by humanists.
+
+\section{Architecture}
+
+The infrastructure system, shown in figure~\ref{fig:architecture},
+follows a cloud-based model and can be divided in multiple modular
+frontends, providing the interface towards the clients, and a
+monolithic backend service.
+
+\begin{figure}[ht]
+  \begin{center}
+    \includegraphics[scale=.4]{ArchDiagram.png}
+    \caption{\label{fig:architecture}High level overview of DHLab
+      architecture}
+  \end{center}
+\end{figure}
+
+The frontend includes three main blocks: a cloud service, a metadata
+form and an application service. Of these, the metadata form, used to
+fill details about a work or an analysis (see
+section~\ref{sec:metadata-form}), is usable also while being offline;
+the requirement addresses the use case of an operator who, while
+disconnected from the network, needs to fill the metadata saving them
+as a file on the local machine. The same requirement may be at least
+partly satisfied also for the application services.
+
+On the backend side, which is only partially implemented and not yet
+even fully designed, we currently expect to have a listener, to
+dispatch client requests, two data stores, one for user profiles and
+the other for actual datasets, and a set of auxiliary services, for
+example to automate the filling of the metadata form and to
+standardize some of its fields (see again
+section~\ref{sec:metadata-form}).
+
+The entire system is hosted at the CNAF data center.
+
+\section{Technologies and protocols}
+
+As stated above, the design of the system is not yet complete and we
+are still investigating different options to address the challenges we
+face.
+
+Open aspects concern:
+
+\begin{itemize}
+  
+\item the data model, which must accomodate both datasets (possibly
+  composed of multiple files), the corresponding metadata and a
+  mechanism to link them together;
+
+\item the authentication and authorization model, which should use as
+  much as possible standard web technologies and have flexible
+  mechanisms to authenticate users coming from different institutions,
+  leveraging their own Identity Providers;
+  
+\item how to access the available storage from a client, both to
+  upload datasets and their metadata and subsequently access them.
+  
+\end{itemize}
+  
+The experimentation makes use of an installation of
+NextCloud~\cite{ref:nextcloud}, an open-source suite of client-server
+software for creating and using file hosting services, with
+functionality often extended through the use of plugins.
+
+Authentication is based on OpenID Connect~\cite{ref:oidc} and makes
+use of the INDIGO-IAM~\cite{ref:iam} service, an Identity and Access
+Management product developed within the EU-funded
+INDIGO-DataCloud~\cite{ref:indigo} project. INDIGO-IAM offers a
+service to manage identities, user enrollment, group membership,
+attributes and policies to access distributed resources and services
+in a homogeneous and interoperable way; hence it represents a perfect
+match to manage users, groups and resources of the CHNet
+organization. In particular INDIGO-IAM delegates the authentication of
+a user to their home institution identity provider under a trust
+agreement.
+
+NextCloud offers also the possibility to access data via the WebDAV
+protocol, allowing users to mount the remote storage on their local
+machine and see it as if it were a local disk. This feature becomes
+useful when interaction through a web browser is not the most
+effective tool, for example for batch or bulk operations.
+
+\section{Metadata Form}
+\label{sec:metadata-form}
+
+The Metadata form is a web application whose purpose is to associate
+metadata with art works, measurement campaigns and analysis
+results. The application, written in Typescript~\cite{ref:typescript}
+and based on the Angular 2 framework~\cite{ref:angular2}, is under
+development; the main deployment option foresees its integration into
+the cloud platform, but the combination with
+Electron~\cite{ref:electron} makes a desktop application a viable
+alternative.
+
+As shown in figure~\ref{fig:metadataSchema}, to fill the metadata form
+a user can follow two paths: they can create a \textit{campaign} and
+associate it with multiple \textit{sessions} and \textit{analyses} or
+they can store information about a single \textit{analysis}. In
+particular, each \textit{analysis} can be associated with one or more
+\textit{datasets}, the studied \textit{object} (i.e.,~an art work) and
+all the information about its \textit{type}, \textit{author},
+\textit{holder}, \textit{owner}, etc. In addition, users can provide
+information about the analysis type, the operator who performed the
+analysis, the devices, components and software used to scan, create or
+read the resulting dataset. When completed, the resulting form,
+translated into a JSON file, can be saved locally or uploaded to the
+remote storage.
+
+\begin{figure}[ht]
+  \begin{center}
+    \includegraphics[scale=.4]{metadataSchema.png}
+  \end{center}
+  \caption{\label{fig:metadataSchema}Schema of the sections included
+    in the metadata description.}
+\end{figure}
+
+\section{Application services}
+
+DHLab is also designed to provide visualization and analysis services
+for some of the stored datasets. Currently a proof-of-concept
+application is available, to visualize and perform some analysis of
+images obtained from XRF scans~\cite{ref:xrf}.
+
+\section{Conclusions}
+
+DHLab is a project born from the need to group, share, catalogue and
+reuse data that comes from measurements and analyses of cultural
+heritage works. It aims at being flexible and usable by persons
+covering different roles: physicists, computer scientists, cultural
+heritage operators. The system is designed and deployed around a core
+Cloud-based infrastructure, but some of its parts must be functioning
+in offline situations.
+
+A web application for filling a form with metadata to be associated to
+collected datasets according to an agreed-upon schema is being
+developed.
+
+Other web applications are foreseen for the visualization and analysis
+of the stored datasets, starting from those coming from XRF,
+radiocarbon and thermoluminescence analysis.
+
+\section*{References}
+
+\begin{thebibliography}{9}
+\bibitem{ref:nextcloud} NextCloud \url{https://nextcloud.com/}
+  
+\bibitem{ref:oidc} OpenId Connect \url{https://openid.net/connect}
+  
+\bibitem{ref:iam} A Ceccanti, E Vianello, M Caberletti. (2018,
+  May). INDIGO Identity and Access Management
+  (IAM). Zenodo. \url{http://doi.org/10.5281/zenodo.1874790}
+
+\bibitem{ref:indigo} The INDIGO-DataCloud project
+  \url{https://www.indigo-datacloud.eu/}
+
+\bibitem{ref:typescript} Typescript language 
+  \url{https://www.typescriptlang.org/}
+
+\bibitem{ref:angular2} Angular 2 framework
+  \url{https://angular.io/}
+
+\bibitem{ref:electron} Electron
+  \url{https://electronjs.org/}
+    
+\bibitem{ref:xrf} Cappelli L, Giacomini F, Taccetti F, Castelli L,
+  dell'Agnello L. 2016. A web application to analyse XRF scanning data. INFN-CNAF
+Annual Report. \url{https://www.cnaf.infn.it/annual-report}
+
+\end{thebibliography}
+
+\end{document}

contributions/cms/report-cms-feb-2019.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\begin{document}
+\title{The CMS Experiment at the INFN CNAF Tier 1}
+
+\author{Giuseppe Bagliesi$^1$}
+
+\address{$^1$ INFN Sezione di Pisa, Pisa, IT}
+
+\ead{giuseppe.bagliesi@cern.ch}
+
+\begin{abstract}
+A brief description of the CMS Computing operations during LHC RunII and their recent developments is given. The CMS utilization at Tier 1 CNAF is described
+\end{abstract}
+
+\section{Introduction}
+The CMS Experiment \cite{CMS-descr} at CERN collects and analyses data from the pp collisions in the LHC Collider.
+The first physics Run, at center of mass energy of 7-8 TeV, started in late March 2010, and ended in February 2013; more than 25~fb$^{-1}$ of collisions were collected during the Run. RunII, at 13 TeV, started in 2015, and finished at the end of 2018.
+
+During the first two years of RunII, LHC has been able to largely exceed its design parameters: already in 2016 instantaneous luminosity reached $1.5\times 10^{34}\mathrm{cm^{-2}s^{-1}}$, 50\% more than the planned “high luminosity” LHC phase. The most astonishing achievement, still, is a huge improvement on the fraction of time LHC can serve physics collisions, increased from ~35\% of RunI to more than 80\% in some months on 2016.
+The most visible effect, computing wise, is a large increase of data to be stored, processed and analysed offline, with 2016 allowing for the collection of more than 40 fb$^{-1}$ of physics data.
+
+In 2017 CMS recorded more than 46 fb$^{-1}$ of pp collisions, in addition to the data collected during 2016. These data were collected under considerably higher than expected pileup conditions forcing CMS to request a lumi-levelling to PU~55 for the first hours of the LHC fill; this has challenged both the computing system and CMS analysts with more complex events to process with respect to the modelling. From the computing operations side, higher pileup meant larger events and more time to process events than anticipated in the 2017 planning. As these data taking conditions affected only the second part of the year, the average 2017 pileup was in line with that used during the CMS resource planning.
+
+2018 was another excellent year for LHC operations and luminosity delivered to the experiments. CMS recorded 64 fb$^{-1}$ of pp collisions during 2018, in addition to the 84 fb$^{-1}$ collected during 2016 and 2017. This brings the total luminosity delivered in RunII to more than 150 fb$^{-1}$ , and the total RunI + RunII dataset to a total of about 180 fb$^{-1}$.
+
+
+
+\section{Run II computing operations}
+During Run~II, the computing 2004 model designed for Run~I has greatly evolved. The MONARC Hierarchical division of sites in Tier 0, Tier 1s and Tier 2s, is still present, but less relevant during operations. All simulation, analysis and processing workflows can now be executed at virtually any site, with a full transfer mesh allowing for point-to-point data movement, outside the rigid hierarchy.
+
+Remote access to data, using WAN-aware protocols like XrootD and data federations, are used more and more instead of planned data movement, allowing for an easier exploitation of CPU resources.
+Opportunistic computing is becoming a key component, with CMS having explored access to HPC systems, Commercial Clouds, and with the capability of running its workflows on virtually any (sizeable) resource we have access to.
+
+In 2018 CMS deployed Singularity \cite{singu} to all sites supporting the CMS VO.  Singularity is a container solution which allows CMS to select the OS on a per job basis and decouples the OS of worker nodes from that required by experiments. Sites can setup worker nodes with a Singularity supported OS and CMS will choose the appropriate OS image for each job.
+
+CMS deployed a new version of the prompt reconstruction software on July 2018, during LHC Machine Development 2. This software is adapted to detector upgrades and data taking conditions, and the production level of alignment and calibration algorithms is reached. Data collected before this point has now been reprocessed for a fully consistent data set for analysis, in time for the Moriond 2019 conference. Production and distributed analysis activities continued at a very high level throughout 2018. The MC17 campaign, to be used for Winter and Summer 18 conferences, continued throughout the year, with decreasing utilization of resources; overall, more than 15 billion of events were available by the Summer. The equivalent simulation campaign for 2018 data, MC18, started in October 2018 and is now almost completed.
+
+Developments to increase CMS throughput and disk usage efficiently continue. Of particular interest is the development of the NanoAOD data tier as a new alternative for analysis users.
+The NanoAOD size per event is approximately 1 kB,  30-50 times smaller than the MiniAOD data tier and relies on only simple data types rather than the hierarchical data format structure in the CMS MiniAOD (and AOD) data tier. NanoAOD samples for the 2016, 2017 and 2018 data and corresponding Monte Carlo simulation have been produced, and are being used in many analyses. NanoAOD is now automatically produced in all the central production campaigns, and fast reprocessing campaigns from MiniAOD to NanoAOD have been tested and are able to achieve more than 4B events per day using only a fraction of  CMS resources.
+
+
+\section{CMS WLCG Resources and expected increase}
+CMS Computing model has been used to request resources for 2018-19 RunII data taking and reprocessing, with total requests (Tier 0 + Tier 1s + Tier 2s) exceeding 2073 kHS06, 172 PB on disk, and 320 PB on tape.
+However the actual pledged resources have been substantially lower than the requests due to budget restrictions from the funding agencies. To reduce the impact of this issue, CMS was able to achieve and deploy several technological advancements, including reducing the needed amount of AOD(SIM) on disk and to reduce the amount of simulated raw events on tape. In addition, some computing resource providers were able to provide more than their pledged level of resources to CMS during 2018.
+Thanks to the optimizations and technological improvements described before it has been possible to tune accordingly the computing model of CMS. Year-by-year increases, which would have been large in presence of the reference computing model, have been reduced substantially.
+
+Italy contributes to CMS computing with 13\% of the Tier 1 and Tier 2 resources. The increase of CNAF pledges for 2019 have been reduced by a factor two with respect to the original request, due to INFN budget limitations, and the remaining increase has been postponed to 2021.
+The 2019 total pledges are therefore 78 kHS06 of CPU, 8020 TB of disk, and 26 PB for tape.
+
+CMS usage of CNAF is very intense and it represents one of the largest Tier 1 in CMS as number of processed hours, after the US Tier 1; the same holds for total number of processed jobs, as shown in Fig.~\ref{cms-jobs}.
+
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=0.8\textwidth,bb=0 0 900 900]{tier1-jobs-2018.pdf}
+\end{center}
+\caption{\label{cms-jobs}Jobs processed at CMS Tier 1 sites during 2018}
+\end{figure}
+
+
+
+\section{The CNAF flood incident}
+On November 9th 2017 a major incident happened when the CNAF computer center was flooded.
+This caused an interruption of all CNAF services and the damage of many  disk arrays and servers, as well as of the tape library. About 40 damaged tapes (out of a total of 150) belonged to CMS. They contained unique copy of MC and RECO data.  Six tapes contained a 2nd custodial copy of RAW data.
+A special recovery procedure was adopted by CNAF team through a specialized company and no data have been permanently lost.
+
+The impact of this incident for CMS, although serious, was mitigated  thanks to the intrinsic redundancy of our distributed computing model. Other Tier 1 sites increased temporary their share to compensate the CPU loss, deploying the 2018 pledges as soon as possible.
+A full recovery of CMS services of CNAF was achieved by beginning of March 2018.
+
+It is important to point out that, despite the incident affecting the first months of 2018, the integrated site readiness of CNAF in 2018 was very good and at the same level or better than the other CMS Tier 1 sites, see Fig.~\ref{tier1-cms-sr}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=0.8\textwidth,bb=0 0 900 900]{tier1-readiness-2018.pdf}
+\end{center}
+\caption{\label{tier1-cms-sr}Site readiness of CMS Tier 1s in 2018}
+\end{figure}
+
+
+\section{Conclusions}
+CNAF is an important asset for the CMS Collaboration, being the second Tier 1 in terms of resource utilization, pledges and availability.
+The unfortunate incident of the end of 2017 has been managed professionally and efficiently by the CNAF staff, guaranteeing the fastest possible recovery with minimal data losses at the beginning of 2018.
+
+
+\section*{References}
+\begin{thebibliography}{9}
+\bibitem{CMS-descr}CMS Collaboration, The CMS experiment at the CERN LHC, JINST 3 (2008) S08004,
+doi:10.1088/1748-0221/3/08/S08004.
+\bibitem{singu} http://singularity.lbl.gov/
+\end{thebibliography}
+
+\end{document}
+>>>>>>> df6666e07f77183d3b9b7271912d9bff64107129

contributions/cnprov/cnprov.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\usepackage{hyperref}
+\usepackage{eurosym}
+
+\begin{document}
+\title{CNAF Provisioning system: Puppet 5 upgrade}
+
+\author{
+  S. Bovina$^1$,
+  D. Michelotto$^1$,
+  E. Fattibene$^1$,
+  A. Falabella$^1$,
+  A. Chierici$^1$
+}
+
+\address{$^1$ INFN-CNAF, Bologna, IT}
+
+\ead{
+  stefano.bovina@cnaf.infn.it,
+  diego.michelotto@cnaf.infn.it,
+  enrico.fattibene@cnaf.infn.it,
+  antonio.falabella@cnaf.infn.it,
+  andrea.chierici@cnaf.infn.it
+}
+
+\begin{abstract}
+Since 2015 CNAF departments can take advantage of a common provisioning system based on Foreman/Puppet to install and configure heterogeneous sets of physical and virtual machines.
+During 2017 and 2018, the CNAF provisioning system, preciously based on Puppet~\cite{ref:puppet} version 3, has been upgraded, since that version has reached ``End-of-life'' at 31/12/2016. 
+Due to other higher priority tasks, the start of this activity was postponed to 2017. 
+In this report we are going to describe activities that have been carried on in order to finalize the migration from Puppet 3 to Puppet 5. 
+\end{abstract}
+
+\section{Provisioning at CNAF}
+The installation and configuration activity, in a big computing center like CNAF, must take into account the size of the resources 
+(roughly a thousand nodes to manage), the heterogeneity of the systems (virtual vs physical nodes, computing nodes and different type of servers) 
+and the different working group in charge for their management. 
+To meet this challenge CNAF implemented a unique solution, adopted by all the departments, 
+based on two well known open source technologies: Foreman~\cite{ref:foreman} for the initial installation, and Puppet for the configuration.
+\newline
+
+Due to the importance of this infrastructure, it is crucial to upgrade it trying to minimize the impact on production systems, so that 
+preventing service disruptions or broken configurations. 
+To achieve this, we have worked on the Puppet test suite based on RSpec~\cite{ref:rspec} and rspec-puppet~\cite{ref:rspec-puppet} tools.
+
+
+\section{Puppet 5 upgrade: finalization}
+Going from Puppet 3 to Puppet 5 implies a major software upgrade, with lots of configurations and functionality changes. 
+For this reason, the main activity in 2017 has been the setup of automated tests and the development of specific utilities for Puppet modules in order to prepare the migration.
+During 2017 we prepared and documented a detailed procedure for the upgrade of all resources administered by the different CNAF departments and several tests were performed 
+in order to minimize the risks of issues in production. 
+At the beginning of 2018 we started the upgrade of the production environment which consisted in the following steps:
+
+\begin{itemize}
+\item Upgrade Foreman to version 1.16.0 in order to support Puppet 5;
+\item Ensuring that every client configuration contains the ca\_server entry;
+\item Ensuring that every client is at version 3.8.7 in order to support Puppet 5;
+\item Deploy a Puppet 5 CA as replacement of the Puppet 3 CA;
+\item Deploy Puppet 5 workers (3x Puppetserver) in addition to the existing ones;
+\item Upgrade the server configuration entry (from Puppet 3 to 5) on every client while keeping client at version 3.8.7;
+\item Upgrade Puppet client to version 5;
+\item Remove old Puppet 3 infrastructure;
+\item Upgrade Puppetforge modules to a newer version (not Puppet 3 compatible).
+\end{itemize}
+
+By the end of 2018 all the ~1500 hosts administered through the CNAF provisioning system were made able to exploit the upgraded infrastructure.
+
+\section{Future works}
+Currently, we are finalizing the Puppetforge modules upgrade. Once all modules are updated, Foreman will be updated to the latest version and tests for Puppet 6 migration will begin immediately after.
+
+
+\section{References}
+\begin{thebibliography}{1}
+    \bibitem{ref:puppet} Puppet webpage: https://puppet.com/
+    \bibitem{ref:foreman} The Foreman webpage: https://theforeman.org/
+    \bibitem{ref:rspec} The RSpec webpage: http://rspec.info/
+    \bibitem{ref:rspec-puppet} The rspec-puppet webpage: http://rspec-puppet.com/
+\end{thebibliography}
+
+
+\end{document}
+

contributions/cnprov/cnprov.tex.bak

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\usepackage{hyperref}
+\usepackage{eurosym}
+
+\begin{document}
+\title{CNAF Provisioning system: Puppet 5 upgrade}
+
+\author{
+  Stefano Bovina$^1$,
+  Diego Michelotto$^1$,
+  Enrico Fattibene$^1$,
+  Antonio Falabella$^1$,
+  Andrea Chierici$^1$
+}
+
+\address{$^1$  INFN CNAF, Viale Berti Pichat 6/2, 40126, Bologna, Italy}
+
+\ead{
+  stefano.bovina@cnaf.infn.it,
+  diego.michelotto@cnaf.infn.it,
+  enrico.fattibene@cnaf.infn.it,
+  antonio.falabella@cnaf.infn.it,
+  andrea.chierici@cnaf.infn.it
+}
+
+\begin{abstract}
+Since 2015 CNAF departments can take advantage of a common provisioning system based on Foreman/Puppet to install and configure heterogeneous sets of physical and virtual machines.
+During 2017 and 2018, the CNAF provisioning system, priviously based on Puppet~\cite{ref:puppet} version 3, has been upgraded, since that version has reached "End-of-life" at 31/12/2016. 
+Due to other higher priority tasks, the start of this activity was postponed to 2017. 
+In this report we are going to describe activities that have been carried on in order to finalize the migration from Puppet 3 to Puppet 5. 
+\end{abstract}
+
+\section{Provisioning at CNAF}
+The installation and configuration activity, in a big computing centre like CNAF, must take into account the size of the resources 
+(roughly a thousand nodes to manage), the heterogeneity of the systems (virtual vs physical nodes, computing nodes and different type of servers) 
+and the different working group in charge for their management. 
+To meet this challenge CNAF implemented a unique solution, adopted by all the departments, 
+based on two well known open source technologies: Foreman~\cite{ref:foreman} for the initial installation, and Puppet for the configuration.
+\newline
+
+Due to the importance of this infrastructure, it is crucial to upgrade it trying to minimize the impact on production systems, so that 
+preventing service disruptions or broken configurations. 
+To achieve this, we have worked on the Puppet test suite based on RSpec~\cite{ref:rspec} and rspec-puppet~\cite{ref:rspec-puppet} tools.
+
+
+\section{Puppet 5 upgrade: finalization}
+Going from Puppet 3 to Puppet 5 implies a major software upgrade, with lots of configurations and functionality changes. 
+For this reason, the main activity in 2017 has been the setup of automated tests and the development of specific utilities for Puppet modules in order to prepare the migration.
+During 2017 we prepared and documented a detailed procedure for the upgrade of all resources administred by the different CNAF departments and several tests were performed 
+in order to minimize the risks of issues in production. 
+At the beginning of 2018 we started the upgrade of the production environment which consisted in the following steps:
+
+\begin{itemize}
+\item Upgrade Foreman to version 1.16.0 in order to support Puppet 5;
+\item Ensuring that every client configuration contains the ca\_server entry;
+\item Ensuring that every client is at version 3.8.7 in order to support Puppet 5;
+\item Deploy a Puppet 5 CA as replacement of the Puppet 3 CA;
+\item Deploy Puppet 5 workers (3x Puppetserver) in addition to the existing ones;
+\item Upgrade the server config entry (from Puppet 3 to 5) on every client while keeping client at version 3.8.7;
+\item Upgrade Puppet client to version 5;
+\item Remove old Puppet 3 infrastructure;
+\item Upgrade Puppetforge modules to a newer version (not Puppet 3 compatible).
+\end{itemize}
+
+By the end of 2018 all the ~1500 hosts administered through the CNAF provisioning system were made able to exploit the upgraded infrastructure.
+
+\section{Future works}
+Currently, we are finalizing the Puppetforge modules upgrade. Once all modules are updated, Foreman will be updated to the latest version and tests for Puppet 6 migration will begin immediately after.
+
+
+\section{References}
+\begin{thebibliography}{1}
+    \bibitem{ref:puppet} Puppet webpage: https://puppet.com/
+    \bibitem{ref:foreman} The Foreman webpage: https://theforeman.org/
+    \bibitem{ref:rspec} The RSpec webpage: http://rspec.info/
+    \bibitem{ref:rspec-puppet} The rspec-puppet webpage: http://rspec-puppet.com/
+\end{thebibliography}
+
+
+\end{document}
+

contributions/cta/CTA_annualreport_2018_v1.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{epsfig}
+%\usepackage{epstopdf}
+\usepackage{graphicx}
+\begin{document}
+\title{The Cherenkov Telescope Array}
+
+\author{L. Arrabito$^1$, C. Bigongiari$^2$, F. Di Pierro$^3$, P. Vallania$^{3,4}$}
+
+\address{$^1$ Laboratoire Univers et Particules de Montpellier et Universit\'e de Montpellier II, Montpellier, FR}
+\address{$^2$ INAF Osservatorio Astronomico di Roma, Monte Porzio Catone (RM), IT}
+\address{$^3$ INFN Sezione di Torino, Torino, IT}
+\address{$^4$ INAF Osservatorio Astrofisico di Torino, Torino, IT}
+
+\ead{arrabito@in2p3.fr, ciro.bigongiari@oa-roma.inaf.it, federico.dipierro@to.infn.it, piero.vallania@to.infn.it}
+
+
+\begin{abstract}
+
+The Cherenkov Telescope Array (CTA) is an ongoing worldwide project to build a new generation ground based observatory for Very High Energy (VHE) gamma-ray astronomy. 
+CTA will feature two arrays of Imaging Atmospheric Cherenkov Telescopes (IACTs), one in each Earth hemisphere, to ensure the full sky coverage and will be operated as an open observatory to maximize its scientific yield.  
+Each array will be composed of tens of IACTs of different sizes to achieve a ten-fold improvement in sensitivity, 
+with respect to current generation facilities, over an unprecedented energy range which extends from a few tens of GeV to a hundred of TeV. 
+Imaging Cherenkov telescopes have already discovered tens of VHE gamma-ray emitters providing plentiful of valuable data and clearly demonstrating the power of the imaging Cherenkov technique. 
+The much higher telescope multiplicity provided by CTA will drive to highly improved angular and energy resolution,  which will permit more accurate morphological and spectrographical studies of VHE gamma-ray sources. CTA project combines therefore guaranteed scientific return, in the form of high precision astrophysics, with considerable potential for major discoveries in astrophysics, cosmology and fundamental physics.
+
+\end{abstract}
+
+\section{Introduction}
+
+Since the discovery of the first VHE gamma-ray source, the Crab Nebula \cite{CrabDiscovery} by the Whipple collaboration in 1989, ground-based gamma-ray astronomy has undergone an impressive development which drove to the discovery of more than 190 gamma-ray sources in less than 30 years \cite{TevCat}. 
+Whenever a new generation of ground-based gamma-ray observatory came into play gamma-ray astronomy experienced a major step in the number of discovered sources as well as in the comprehension of the astrophysical phenomena involved in the emission of VHE gamma radiation.  
+Present generation facilities like H.E.S.S. \cite{HESS}, MAGIC \cite{MAGIC} and VERITAS \cite{VERITAS} already provided a deep insight into the non-thermal processes which are responsible of the high energy emission by many astrophysical sources, like Supernova Remnants, Pulsar Wind Nebulae, Micro-quasars and Active Galactic Nuclei, clearly demonstrating the huge physics potential of this field, which is not restricted to pure astrophysical observations, but allows significant contributions to particle physics and cosmology too, see \cite{DeNauroisMazin2015,LemoineGoumard2015} for recent reviews. The impressive physics achievements obtained with the present generation instruments as well as the technological developments regarding mirror production
+and new photon-detectors triggered many projects for a new-generation gamma-ray observatory by groups of astroparticle physicists around the world which later merged to form the CTA consortium \cite{CtaConsortium}. 
+CTA members are carrying on a worldwide effort to provide the scientific community with a state-of-the-art ground-based gamma-ray observatory, allowing exploration of cosmic radiation in the very high energy range with unprecedented accuracy and sensitivity. 
+
+
+\begin{figure}[ht]
+\includegraphics[width=\textwidth]{CTA_ProjectTimeline_Nov2018.eps}
+\caption{\label{CtaTimeline} CTA project time line.}
+\end{figure}
+
+
+VHE gamma-rays can be produced in the collision of highly relativistic particles with surrounding gas clouds or in their interaction with low energy photons or magnetic fields. Possible sources of such energetic particles include jets emerging from active galactic nuclei, remnants of supernova explosions, and the environment of rapidly spinning neutron stars. High-energy gamma-rays can also be produced in top-down scenarios by the decay of heavy particles such as hypothetical dark matter candidates or cosmic strings.
+The CTA observations will be used for detailed studies of above-mentioned astrophysical sources as well as for fundamental physics measurements, such as the indirect search of dark matter, searches for high energy violation of Lorentz invariance and searches for axion-like particles. 
+High-energy gamma-rays can be used moreover to trace the populations of high-energy particles, thus providing insightful information about the sources of cosmic rays. 
+Close cooperation with observatories of other wavelength ranges of the electromagnetic spectrum, and those using cosmic rays, neutrinos and gravitational waves are foreseen.
+
+To achieve a full sky-coverage the CTA observatory will consist of two arrays of IACTs, one in both Earth hemispheres. The northern array will be placed at the Observatorio del Roque de Los Muchachos on La Palma Island, Spain, while the southern array will be located in Chile at the ESO site close to the Cerro Paranal. 
+The two sites were selected after years of careful consideration of extensive studies of the environmental conditions, simulations of the science performance and assessments of construction and operation costs.
+Each array will be composed by IACTs of different sizes to achieve an overall ten-fold improvement in sensitivity with respect to current IACT arrays while extending the covered energy range from about 20 GeV to about 300 TeV. 
+The southern hemisphere array will feature telescopes of three different sizes to cover the full energy range for a detailed investigation of galactic sources, and in particular of the Galactic center, without neglecting observations of extragalactic objects. 
+The northern hemisphere array instead will consist of telescopes of two different sizes only covering the low energy end of the above-mentioned range (up to some tens of TeV) and will be dedicated mainly to northern extragalactic objects and cosmology studies.  
+
+The CTA observatory with its two arrays will be operated by one single consortium and a significant and increasing fraction of the observation time will be open to the general astrophysical community to maximize CTA scientific return. 
+ 
+The CTA project has entered the pre-construction phase. The first Large Size Telescope (LST) has been inaugurated in October 2018, accordingly to the schedule (see Fig. \ref{CtaTimeline}), in the La Palma CTA Northern Site. During 2019 the construction of 3 more LSTs will start. In December 2018 another telescope prototype, the Dual Mirror Medium Size Telescope has been also inaugurated at the Mount Whipple Observatory (Arizona, US). 
+Meanwhile detailed geophysical characterization of the southern site is ongoing and the agreement between the hosting country and the CTA Observatory has been signed. 
+First commissioning data from LST1 have started to be acquired at the end of 2018, in 2019 the first gamma-rays observations are expected.
+CTA Observatory is expected to become fully operational by 2025 but precursors mini-arrays are expected to operate already in 2020. 
+
+A detailed description of the project and its expected performance can be found in a dedicated volume of the Astroparticle Physics journal \cite{CtaApP}, while an update on the project status can be found in \cite{Ong2017}. 
+CTA is included in the 2008 roadmap of the European Strategy Forum on Research Infrastructures (ESFRI), 
+is one of the Magnificent Seven of the European strategy for astroparticle physics by ASPERA, 
+and highly ranked in the strategic plan for European astronomy of ASTRONET.
+
+
+
+\section{Computing Model}
+
+In the pre-construction phase the available computing resources are used mainly for the simulation of atmospheric showers and their interaction with the Cherenkov telescopes of the CTA arrays to evaluate the expected performance and optimize many construction parameters. 
+The simulation of the atmospheric shower development, performed with Corsika \cite{Corsika}, is followed by the simulation of the detector response with sim\_telarray \cite{SimTelarray}, a code developed within the CTA consortium.
+It is worthwhile to notice that thanks to the very high rejection of hadronic background achieved with the IACT technique, huge samples of simulated hadronic events are needed to achieve statistically significant estimates of the CTA performance. 
+About $10^{11}$ cosmic ray induced atmospheric showers for each site are needed to properly estimate the array sensitivity, energy and angular resolution requiring extensive computing needs in term of both disk space and CPU power. Given these large storage and computing requirements, the Grid approach was chosen to pursue this task and a Virtual Organization for CTA was created in 2008 and is presently supported by 20 EGI sites and one ARC site spread over 7 countries, with more than 3.6 PB of storage, about 7000 available cores on average and usage peaks as high as 12000 concurrent running jobs.
+
+The CTA production system currently in use \cite{Arrabito2015} is based on the DIRAC framework \cite{Dirac}, which has been originally developed to support the production activities of the LHCb (Large Hadron Collider Beauty) experiment and today is extensively used by several particle physics and biology communities. DIRAC offers powerful job submission functionalities and can interface with a palette of heterogeneous resources, such as grid sites, cloud sites, HPC centers, computer clusters and volunteer computing platforms. Moreover, DIRAC provides a layer for interfacing with different types of resources, like computing elements, catalogs or storage systems. 
+
+A massive production of simulated data has been carried on in 2018 to estimate the expected performance with improved telescopes' models and with different night-sky background levels. A simulation dedicated to the detailed comparison of different Small Size Telescope versions was also carried on. Simulated data have been analyzed with two different analysis chains to crosscheck the results and have been also used for the development of the new official CTA reconstruction and analysis pipeline. 
+
+\begin{figure}[ht]
+\includegraphics[width=0.8\textwidth]{cpu-days-used-2018-bysite.eps}
+\caption{\label{CPU} CPU power provided in 2018 by Grid sites in the CTA Virtual Organization.}
+\end{figure}
+
+About 2.7 million of GRID jobs have been executed in 2018 for such task corresponding to about 206.4 millions of HS06 hours of CPU power and 10 PB of data transferred. 
+CNAF contributed to this effort with about 16.8 millions of HS06 hours and 790 TB of disk space corresponding to 8\% of the overall CPU power used and the 17\% of the disk space resulting the second contributor in terms of storage and the fourth in terms of CPU time (see Fig. \ref{CPU}-\ref{Disk}).
+
+\begin{figure}[ht]
+\includegraphics[width=0.8\textwidth]{normalized-cpu-used-2018-bysite-cumulative.eps}
+\caption{\label{CPU-cumu} Cumulative normalized CPU used in 2018 by Grid sites in the CTA Virtual Organization.}
+\end{figure}
+
+\begin{figure}[ht]
+\includegraphics[width=0.8\textwidth]{transfered-data-2018-bysite.eps}
+\caption{\label{Disk} Total transferred data in 2018, for the Grid sites in the CTA Virtual Organization.}
+\end{figure}
+
+\clearpage
+
+\section*{References}
+\begin{thebibliography}{19}
+\bibitem{CrabDiscovery} Weekes T C {\it et al.} 1898 ``Observation of TeV gamma rays from the Crab nebula using the atmospheric Cerenkov imaging technique''
+{\it ApJ} {\bf 342} 379-95 
+
+\bibitem{TevCat} TevCat web page http://tevcat.uchicago.edu
+
+\bibitem{HESS} H.E.S.S. web page https://www.mpi-hd.mpg.de/hfm/HESS/
+
+\bibitem{MAGIC} MAGIC web page https://magic.mppmu.mpg.de
+
+\bibitem{VERITAS} VERITAS web page http://veritas.sao.arizona.edu
+
+\bibitem{DeNauroisMazin2015} de Naurois M and Mazin D ``Ground-based detectors in very-high-energy gamma-ray astronomy'' 
+Comptes Rendus - Physique {\bf 16}  Issue 6-7, 610-27
+
+\bibitem{LemoineGoumard2015} Lemoine-Goumard M 2015 ``Status of ground-based gamma-ray astronomy'' Conf. Proc of $34^{th}$ International Conference on C, 2015, The Hague, 
+PoS ICRC2015 (2016) 012
+
+\bibitem{CtaConsortium} CTA web page https://www.cta-observatory.org/about/cta-consortium/
+
+\bibitem{CtaApP} Hinton J, Sarkar S, Torres D and Knapp J 2013 ``Seeing the High-Energy Universe with the Cherenkov Telescope Array. The Science Explored with the CTA'' {\it Astropart. Phys.} {\bf 43}  1-356
+
+%\bibitem{Bigongiari2016} Bigongiari C 2016 ``The Cherenkov Telescope Array'' Proc. of Cosmic Ray International Seminar (CRIS2015), %2015, Gallipoli,
+% {\it Nucl. Part. Phys. Proc.} {\bf 279–281} 174-81
+
+\bibitem{Ong2017} Ong R A et al. 2017 ``Cherenkov Telescope Array: The Next Generation Gamma-Ray Observatory'' 
+Proc. of 35th Int. Cosmic Ray Conf. - ICRC2017, 10-20 July, 2017, Busan, Korea (arXiv:1709.05434v1)
+
+\bibitem{Corsika} Heck D, Knapp J, Capdevielle J N, Schatz G and Thouw T 1998 ``CORSIKA: a Monte Carlo code to simulate extensive air showers'' 
+Forschungszentrum Karlsruhe GmbH, Karlsruhe (Germany), Feb 1998, V + 90 p., TIB Hannover, D-30167 Hannover (Germany)
+
+\bibitem{SimTelarray} Bernlh{\"o}r K 2008 ``Simulation of imaging atmospheric Cherenkov telescopes with CORSIKA and sim\_telarray'' {\it Astropart. Phys} {\bf 30} 149-58 
+
+\bibitem{Arrabito2015} Arrabito L, Bregeon J, Haupt A, Graciani Diaz R, Stagni F and Tsaregorodtsev A 2015 ``Prototype of a production system for Cherenkov Telescope Array with DIRAC'' Proc. of $21^{st}$ Int. Conf.e on Computing in High Energy and Nuclear Physics (CHEP2015), 2015, Okinawa, 
+{\it J. Phys.: Conf. Series} {\bf 664} 032001
+
+\bibitem{Dirac} Tsaregorodtsev A {\it et al.} 2014 ``DIRAC Distributed Computing Services'' Proc. of $20^{st}$ Int. Conf.e on Computing in High Energy and Nuclear Physics (CHEP2013) 
+{\it J. Phys.: Conf. Series} {\bf 513} 032096 
+
+
+\end{thebibliography}
+
+\end{document}
+
+