451 views
--- type: slide slideOptions: transition: slide --- # Topics for the HSF Julia-for-HEP mini workshop of Sep. 2021. --- ## Review of the list of required features (1/3) <style> ol { text-align: left} td { text-align: left} </style> List of features to be supported to be a replacement for Python in HEP applications. To be reviewed by each participant before the workshop. | Requirements | | ----------------------------------------- | | Reproducibility | | Interporability | | Easy to write code and learn the language | | High performance | --- ## Review of the list of required features (2/3) | Requirements (cont'd) | | -------------------------------------------------------- | | Batch computing | | Library to read ROOT files | | Supported on Linux, MacOS (and Windows?) | | Histogramming | | Fitting | --- ## Review of the list of required features (3/3) | Requirements (cont'd) | | -------------------------------------------------------- | | Plotting with publication quality | | Plot template to uniformize plots within a collaboration | | Notebook | --- ## ROOT I/O (1/2) ROOT file is widely used for HEP and support for reading ROOT file is essential 1. Which level of support and integration is desired: full-fledged ? Limited to a subset of class and TTree Branch type ? Read-only or Read and Write ? 2. Level of integration: mapping of C++ object to native Julia structure vs object proxy 3. What is provided by existing software, UnROOT.jl --- ## ROOT I/O (1/2) 4. DataFrame vs explicit event loop. 5. Maintenance of the code. Synchronisation with possible ROOT format evolution. ROOT 7 I/O plans? Is there a better approach than implementing ROOT file reading/writing for each language: we have currently code for java, python, Go, Julia, and Rust in addition to the mainstream C++ library. --- ## Interface with other language and libraries (1/3) 1. State of the art: direct interface and good integration for python and C. More sophisticaed for C++. 2. Needs for Cxx.jl: direct call of C++ from Julia w/o any c++ wrapper code. 3. Interface with ROOT libraries Wishes. Needs for a PyROOT equivalent? Level of integration, type mapping? --- ## Interface with other language and libraries (2/3) 4. Calling Julia from non-Julia frameworks a. ROOT case: potential and feasability of the support of functions written in Julia, e.g. to be passed to RDataFrame.Define(). b. Experiment framework case: potential and feasability of supporting user module written in Julia in a C++-based experiment software. --- ## Interface with other language and libraries (3/3) 5. Mixing C++ and Julia. In a perspective of the migration of a framework from C++ to Julia as main language, what are the perspective for adiabatic migrations, passing by a phase of mixed languages. --- ## One-language-for-all Performance: different tests of running speed were performed and show similar performance to C++. Ease of code writing. This includes subjectivity. How should we compare it with Python? --- ## Distributed computing 1. Running julia code on a cluster 2. Julia on the grid --- ## Julia for simulation and reconstruction _<div style="font-size:14px;">This part will be covered depending on the availability and interests of involved people.</div>_ 1. Potential of Julia for simulation toolkit (GEANT) 2. List of requirements for experiment simulation and reconstruction frameworks ? 3. Is Julia mechanism adapted to the size of experiment software? Can JIT compilation latency be a problem? 4. Julia for experiment trigger. --- ## Julia for Phenomenology and event generation _<div style="font-size:14px;">This part will be covered depending on the availability and interests of involved people.</div>_ 1. Event generators often combine several languages. What is the potential of the one-language-for-all of Julia? Can the Julia syntax for mathematical expression helps in the readability of the code ? 2. Symbolic calculation: symbolic calculation with Julia; interface of Julia and Mathematica; Mathematica vs Julia notebooks.