DIRAC Project provides a general-purpose framework for building distributed computing systems. It is used now in several HEP and astrophysics experiments as well as for user communities in other ...scientific domains. There is a large interest from smaller user communities to have a simple tool like DIRAC for accessing grid and other types of distributed computing resources. However, small experiments cannot afford to install and maintain dedicated services. Therefore, several grid infrastructure projects are providing DIRAC services for their respective user communities. These services are used for user tutorials as well as to help porting the applications to the grid for a practical day-to-day work. The services are giving access typically to several grid infrastructures as well as to standalone computing clusters accessible by the target user communities. In the paper we will present the experience of running DIRAC services provided by the France-Grilles NGI and other national grid infrastructure projects.
DIRAC Interware is an open-source development platform for the integration of heterogeneous computing and storage resources. The service based on this platform was deployed and configured in Joint ...Institute for Nuclear Research in 2016. Now it is actively used for MPD, Baikal-GVD, and BM@N experiments. In JINR we have five big computing resources with uniform access via the DIRAC service: Tier1, Tier2, Govorun supercomputer, cloud, and NICA cluster. In particular, the DIRAC service was used as a tool for the integration of cloud resources of JINR member states. The overall performance of the united system is at least three times more efficient compared to the use of any single computing resource. Of course, using the united system adds complexity for users and requires additional effort to reach high performance. But, for the last three years of active use of the DIRAC, the approaches were elaborated to simplify the use of the system. Right now there are many tools and components developed to allow the fast construction of new workflows. The total number of completed jobs exceeds 1 million, and the total amount of computing work is around 4.5 million HS06days.
The one of the main types of land degradation that cause the most damage to the state of soil cover is local waterlogging of soils. Only in Russia, about 9 million hectares are currently considered ...waterlogged, including 5 million hectares of agricultural land. On the lowland plains of the forest-steppe zone of the Central Black Earth Region of Russia, local over moistening of the soil cover creates significant difficulties in the use of arable land resources. Natural factors effects waterlogging are the amount of precipitation and the level of groundwater. The objects of research are virgin and arable soils with different hydromorphic conditions in the Central Russian Upland. The article presents results about humus content and reserves in Chernozems typical, Chernozems leached, Meadow-chernozemics soil, Chernozems-meadow soil and Chernozem wet-meadow soil. According to our investigations the most rich humus soils of the forest-steppe is semi-hydromorphic Meadow-chernozemics soils. Meadow-chernozemics leached and typical soils have an average thickness of the humus horizon of 88 and 85 cm and contain about 8.5 and 8.8% humus in the arable layer. Humus reserves in horizons A + AB is 623 and 629.5 t/ha and in a meter layer is 653.5 and 672.5 t/ha.
ILCDIRAC is a complete distributed computing solution for the Linear Collider community. It's an extension of the DIRAC system and now used by all detector concepts of the LC community. ILCDIRAC ...provides a unified interface to the distributed resources for the ILC Virtual Organization and provides common interfaces to all ILC applications via a simplified API. It supports the overlay of beam-induced backgrounds with minimal impact on the Storage Elements by properly scheduling the jobs attempting to access the files. ILCDIRAC has been successfully used for the CLIC Conceptual Design Report and the ILC SiD Detailed Baseline Design, and is now adopted by the LC community as the official Grid production tool. Members of the CALICE collaboration also use ILCDIRAC within their own Virtual Organization.
Pilots 2.0: DIRAC pilots for all the skies Stagni, F; Tsaregorodtsev, A; McNab, A ...
Journal of physics. Conference series,
12/2015, Letnik:
664, Številka:
6
Journal Article
Recenzirano
Odprti dostop
In the last few years, new types of computing infrastructures, such as IAAS (Infrastructure as a Service) and IAAC (Infrastructure as a Client), gained popularity. New resources may come as part of ...pledged resources, while others are opportunistic. Most of these new infrastructures are based on virtualization techniques. Meanwhile, some concepts, such as distributed queues, lost appeal, while still supporting a vast amount of resources. Virtual Organizations are therefore facing heterogeneity of the available resources and the use of an Interware software like DIRAC to hide the diversity of underlying resources has become essential. The DIRAC WMS is based on the concept of pilot jobs that was introduced back in 2004. A pilot is what creates the possibility to run jobs on a worker node. Within DIRAC, we developed a new generation of pilot jobs, that we dubbed Pilots 2.0. Pilots 2.0 are not tied to a specific infrastructure; rather they are generic, fully configurable and extendible pilots. A Pilot 2.0 can be sent, as a script to be run, or it can be fetched from a remote location. A pilot 2.0 can run on every computing resource, e.g.: on CREAM Computing elements, on DIRAC Computing elements, on Virtual Machines as part of the contextualization script, or IAAC resources, provided that these machines are properly configured, hiding all the details of the Worker Nodes (WNs) infrastructure. Pilots 2.0 can be generated server and client side. Pilots 2.0 are the "pilots to fly in all the skies", aiming at easy use of computing power, in whatever form it is presented. Another aim is the unification and simplification of the monitoring infrastructure for all kinds of computing resources, by using pilots as a network of distributed sensors coordinated by a central resource monitoring system. Pilots 2.0 have been developed using the command pattern. VOs using DIRAC can tune pilots 2.0 as they need, and extend or replace each and every pilot command in an easy way. In this paper we describe how Pilots 2.0 work with distributed and heterogeneous resources providing the necessary abstraction to deal with different kind of computing resources.
DIRAC in Large Particle Physics Experiments Stagni, F; Tsaregorodtsev, A; Arrabito, L ...
Journal of physics. Conference series,
10/2017, Letnik:
898, Številka:
9
Journal Article
Recenzirano
Odprti dostop
The DIRAC project is developing interware to build and operate distributed computing systems. It provides a development framework and a rich set of services for both Workload and Data Management ...tasks of large scientific communities. A number of High Energy Physics and Astrophysics collaborations have adopted DIRAC as the base for their computing models. DIRAC was initially developed for the LHCb experiment at LHC, CERN. Later, the Belle II, BES III and CTA experiments as well as the linear collider detector collaborations started using DIRAC for their computing systems. Some of the experiments built their DIRAC-based systems from scratch, others migrated from previous solutions, ad-hoc or based on different middlewares. Adaptation of DIRAC for a particular experiment was enabled through the creation of extensions to meet their specific requirements. Each experiment has a heterogeneous set of computing and storage resources at their disposal that were aggregated through DIRAC into a coherent pool. Users from different experiments can interact with the system in different ways depending on their specific tasks, expertise level and previous experience using command line tools, python APIs or Web Portals. In this contribution we will summarize the experience of using DIRAC in particle physics collaborations. The problems of migration to DIRAC from previous systems and their solutions will be presented. An overview of specific DIRAC extensions will be given. We hope that this review will be useful for experiments considering an update, or for those designing their computing models.
File replica and metadata catalogs are essential parts of any distributed data management system, which are largely determining its functionality and performance. A new File Catalog (DFC) was ...developed in the framework of the DIRAC Project that combines both replica and metadata catalog functionality. The DFC design is based on the practical experience with the data management system of the LHCb Collaboration. It is optimized for the most common patterns of the catalog usage in order to achieve maximum performance from the user perspective. The DFC supports bulk operations for replica queries and allows quick analysis of the storage usage globally and for each Storage Element separately. It supports flexible ACL rules with plug-ins for various policies that can be adopted by a particular community. The DFC catalog allows to store various types of metadata associated with files and directories and to perform efficient queries for the data based on complex metadata combinations. Definition of file ancestor-descendent relation chains is also possible. The DFC catalog is implemented in the general DIRAC distributed computing framework following the standard grid security architecture. In this paper we describe the design of the DFC and its implementation details. The performance measurements are compared with other grid file catalog implementations. The experience of the DFC Catalog usage in the CLIC detector project are discussed.
Background. Class IC antiarrhythmic drugs (IC-AADs) are recommended as first-line therapy in treatment of lone paroxysmal atrial fibrillation (AF) along with catheter ablation of pulmonary veins. ...Despite previous attempts to identify predictors of IC-AADs` efficacy, the choice between IC-AADs agents is still most often carried out using empirical approach.
Aim. To determine the predictors of IC-AADs ` efficacy in patients with paroxysmal AF in the absence of structural heart disease.
Materials and methods. Seventy four patients (22 men, 52 women, average age 65 57; 70 years) were treated with IC-AADs: 26 patients were prescribed lappaconitine hydrobromide (Al) (allapinin at a dosage of 75 mg/day or allaforte 50–100 mg/day), 25 patients were prescribed propafenone (P) 450–600 mg/day, 23 patients – diethylaminopropionylethoxycarbonylaminophenothiazine hydrochloride (ethacizine, E) 150 mg/day. The average frequency of AF paroxysms was 2 0.4; 6.25 per month. Patients were divided into 2 groups depending on the effect of AADs.
Results. Over a 12 months follow-up IC-AADs therapy was effective in 28 (37.8%) patients (Eff+ group), in the remaining 46 (62.2%) patients AF recurrences or side effects demanding AADs withdrawal were registered (Eff-group). A DC value greater or equal to 5 ms predicted the effectiveness of IC-AADs therapy with 79% sensitivity and 77% specificity (OR 12, 95% CI 3.07–49.5, p0.0001). In the Al group the deceleration capacity (DC) value greater or equal to 5.25 ms allowed predicting therapy effectiveness with 86% sensitivity and 100% specificity (OR 7, 95% CI 1.14; 43; p=0.002). In the E group, the DC index was characterized by high sensitivity (80%) and specificity (85%) for a threshold value of 5.9 ms. In case of DC above this value, the probability of E therapy efficacy increased by 22-times (OR 22, 95% CI 1.5; 314; p=0.009). In group P, the DC medians in the Eff+ and Eff- groups did not differ significantly (p=0.821). However, at low DC values (less than 4 ms) P turned out to be the most effective compared to other two IC-AADs: its effectiveness was 50%, which was significantly higher compared to E (0%) and Al (0%) (p=0.046).
Conclusion. Estimation of the DC level before starting IC-AADs can make it easier to choose a specific drug from this group and improve treatment results: at DC above 5.2 ms, it is advisable to use Al, at DC≥6 ms – Al or E, at DC less than 4 ms – P.
The Cherenkov Telescope Array (CTA), an array of many tens of Imaging Atmospheric Cherenkov Telescopes deployed on an unprecedented scale, is the next-generation instrument in the field of very high ...energy gamma-ray astronomy. An average data stream of about 0.9 GB/s for about 1300 hours of observation per year is expected, therefore resulting in 4 PB of raw data per year and a total of 27 PB/year, including archive and data processing. The start of CTA operation is foreseen in 2018 and it will last about 30 years. The installation of the first telescopes in the two selected locations (Paranal, Chile and La Palma, Spain) will start in 2017. In order to select the best site candidate to host CTA telescopes (in the Northern and in the Southern hemispheres), massive Monte Carlo simulations have been performed since 2012. Once the two sites have been selected, we have started new Monte Carlo simulations to determine the optimal array layout with respect to the obtained sensitivity. Taking into account that CTA may be finally composed of 7 different telescope types coming in 3 different sizes, many different combinations of telescope position and multiplicity as a function of the telescope type have been proposed. This last Monte Carlo campaign represented a huge computational effort, since several hundreds of telescope positions have been simulated, while for future instrument response function simulations, only the operating telescopes will be considered. In particular, during the last 18 months, about 2 PB of Monte Carlo data have been produced and processed with different analysis chains, with a corresponding overall CPU consumption of about 125 M HS06 hours. In these proceedings, we describe the employed computing model, based on the use of grid resources, as well as the production system setup, which relies on the DIRAC interware. Finally, we present the envisaged evolutions of the CTA production system for the off-line data processing during CTA operations and the instrument response function simulations.
PDF
