1 / 12

Data Acquisition in the ITER Ion Source Experiment

Data Acquisition in the ITER Ion Source Experiment Adriano Luchetta , Gabriele Manduchi, Antonio Barbalace, Anton Soppelsa, Cesare Taliercio Consorzio RFX – Euratom-ENEA Association, Padova, Italy adriano.luchetta@igi.cnr.it. Summary Introduction Requirements Software frameworks

ovid
Download Presentation

Data Acquisition in the ITER Ion Source Experiment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Data Acquisition in the ITER Ion Source Experiment Adriano Luchetta, Gabriele Manduchi, Antonio Barbalace, Anton Soppelsa, Cesare Taliercio Consorzio RFX – Euratom-ENEA Association, Padova, Italy adriano.luchetta@igi.cnr.it • Summary • Introduction • Requirements • Software frameworks • EPICS/MDSplus integration • Real-time performance • Conclusions CAD view of SPIDER Vessel

  2. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Introduction (1) - Context • Tokamaks require additional heating to reach fusion-relevant parameters, as ohmic heating is limited by instability at a given toroidal magnetic field value. • Additional heating adds controllability: • Plasma rotation, current profile control • MHD instability control • Additional heating is provided by: • Radio Frequency coupled to plasma • (ion and electron cyclotron, lower hybrid) • Heating H0/D0 Neutral Beams (HNB) injected into plasma • neutral to reach plasma core without magnetic deflection • ITER will have #2 HNBs Injectors with option for 3. Fig.1. JET toroidal chamber.

  3. Introduction (2) - Neutral Beam Test Facility Table I. Main parameters of ITER HNB. • Required parameters for ITER HNBs are well beyond achievements in devices developed so far. • To develop full-size HNB and test it up tomaximum performance, ITER approved construction of ad-hoc Neutral Beam Test Facility • It is under construction in Padova, Italy, and will comprise 2 test-beds • Full-size Ion Source – op. 2013 • Called SPIDER • Full-size HNB • ITER CODAC compatible Fig.2. CAD view of ITER HNB. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal.

  4. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. 6m Water-cooled Beam-dump 4m Introduction (3) – Ion Source Experiment Fig.3. Operating principle of SPIDER. Fig.4. CAD view of SPIDER. Table II. Main parameters of SPIDER.

  5. Data Acquisition Requirements (1)SPIDER Diagnostics Table III. SPIDER DiagnosticsSystems. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal.

  6. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Data Acquisition Requirements (2) - Quantity Table IV. Channel number and estimateddata throughput. Table V. Estimated data amount.

  7. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Software Frameworks (1) • Control & data acquisition will be implemented by open source, collaborative software frameworks: • EPICS for control (ITER-driven) • MDSplus for data acquisition • MDSplus is a set of data management tools: • Data acquisition system (hardware configuration, data read-out) • Remote data access system • Data visualization and analysis system • data available via FORTRAN, C, C++, Java, idl, matlab, visual basic, labview, php, python • data available via a unified object model in python, java, c++, matlab • Data archival system based on a shared record store (pulse file) • Hierarchical; Simple API • Does not distinguish between classes of data (python-like)

  8. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Software Frameworks (2) - MDSplus • There have been over 8000 downloads of MDSplus installation kits • Sites using complete MDSplus system: • TCV (EPFL - Switzerland), RFX (Euratom/ENEA - Italy),  Heliac (ANU - Australia),MST (U. Wisconsin), HIT, TIP, TCS and ZAP (U. Washington), PISCES (UCSD), CHS (NIFS - Japan), LDX (MIT), HBT-IP and CTX (Columbia U.), Alcator C-Mod (MIT) • NSTX (PPPL) and  KSTAR (NFRI - S. Korea) use MDSplus and EPICS. • Sites using MDSplus remote data access: • JET, ASDEX-Upgrade, Tore Supra, DIIID • Physics codes • EFIT, TRANSP, GS2 • Integrated Tokamak Modeling Task (EFDA)  • ITPA collaborative data archives Fig.5. MDSplus sites.

  9. EPICS/MDSplus integration (1) • We want a high level of integration between EPICS and MDSplus. • New MDSplus-based EPICS Channel Archiver (JCA-based). See G. Manduchi Poster PCM-16 Table 6. Percentage of lost samples in EPICS Channel Archiver. Fig. 6. Remote data access time to EPICS and MDSplus archivers. 2.4 GHz quad-core Linux workstation 4 GB RAM and SATA disk controller 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal.

  10. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. EPICS/MDSplus integration (2)New EPICS Records MDSplus Pulse File • mdsputprovides direct storage of EPICS IOC data into MDSplus-based Channel Archiver. • mdsaction allows to command ‘Mdsplus actions’ by an EPICS IOC. • MDSplus actions execute operations. • INIT method: reads set-up information from pulsefile and configures hardware. • STORE method: reads samples from ADC and stores them into pulse file. • mdsevent implements reception of ‘MDSplus events’ (asynchronous communication). • MDSplus events can also carry data. • Channel Access Server for MDSPlus CAS Channel Archiver (CAC) Ch. Access mdsip (TCP) PV mdsput mdsevent (UDP) EPICS IOC MDSplus wave STORE INIT mdsaction ADC Fig. 7. EPICS and MDSplus data flow.

  11. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Reference application MARTe EPICS Real-time Performance (1) • Measurements on real-time (RT) performance of EPICS and the latency ‘fingerprint’ of Linux k.2.6 and RT patches (tollerable latency: a few hundreds ms). test 1 kHz Occurrence graph bin width 0.1 ms Fig. 9. Sample application. Performance See A. Barbalace Poster PFE-13 Reference application + EPICS X MARTe * MARTe See A.C. Neto Poster PFE-4 Latency (ms) NI6255 x86 Intel Core 2 Duo 2.66GHz 3MB cache and 3GB RAM Linux 2.6.29.6 rt-24 Fig. 8. Measured latency values.

  12. 17th Real-Time Conference, 25 May 2010, Lisboa, Portugal. Conclusions • Requirements of SPIDER data acquisition are not trivial due to the long duration of the SPIDER beam-on time, the large data amount and, finally, the real-time constraints. • System software architecture will rely on the integration of EPICS and MDSplus, for which specific tools have been implemented and profiled, such as the MDSplus Channel Archiver, interface EPICS records and, in progress, the MDSplus Channel Access Server. • The real-time characteristics of EPICS and Linux kernel 2.6 with real-time patches satisfy the real-time requirements of the SPIDER data acquisition and fast real-time control. Thank you for your attention.

More Related