1. Antonio Laganà University of Perugia (UNIPG), IT
HIGH PERFORMANCE GRID COMPUTING FOR MOLECULAR AND MATERIALS SCIENCE AND TECHNOLOGY (CMMST)
Antonio Laganà University of Perugia (UNIPG), IT
E.Rossi, S. Evangelisti, A. Monari, S. Rampino, M. Verdicchio, C. Angeli, K. Baldridge, G.L. Bendazzoli, S. Borini, R. Cimiraglia, P. Kallay, H.P. Lüthi, K. Ruud, J. Sanchez-Marin, A. Scemama, P. Szalay, A. Tajti, M. Cecchi, M. Carpene, A. Costantini, C. Manuali,E. Garcia, S. Farantos 1

2. SUMMARY 1) DATA AND FLUX TRANSFER IN CMMST APPLICATIONS
2) HTC-HPC FUNCTIONALITIES TRANSFER (IGI-CINECA experimentation)
3) KNOWLEDGE TRANSFER IN CMMST APPLICATIONS 2

3. 1) A TYPICAL DATA AND FLUX TRANSFER: THE VIRTUAL EXPERIMENT3

4. THE CROSSED BEAM (or spectroscopy, NMR, crystallography, etc
THE CROSSED BEAM (or spectroscopy, NMR, crystallography, etc.) VIRTUAL EXPERIMENT
- O. Gervasi, A. Lagana’, SIMBEX: a portal for the a priori simulation of crossed beam experiments,  Future generation Computer Systems, 20(5), (2004). 4

5. THE GRID EMPOWERED WORKFLOWNO NO
Is there
a suitable PES? NO
Are ab initio
calculations
available?
Are ab initio
calculations
feasible?
INTERACTION
YES
YES
YES
SUPSIM
Are
dynamics
calculations
direct? NO
Take Force fields from databases
FITTING
Import the
PES routine
YES
YES
DYNAMICS
Exact
quantum
calculations?
Approximate
quantum
calculations? NO NO
Semiclassical
calculations? NO
YES
YES
YES
QDYN
TD / TI
APPROXIMATE
QDYN
SEMICLASSICAL
SC_IVR
QUASI-
CLASSICAL
OBSERVABLES
Fixed J and Energy
Fixed
Energy
Fixed
Temperature NO NO NO
YES
YES
YES
Scalar and vector correlations
Cross-sections
Thermal
Rate coefficients
Thermodynamic properties

6. DATA FORMATS System input Q5Cost Interaction D5Cost Dynamics
Statistics
Virtual Monitors 6

7. AB INITIO PACKAGES (Wikipedia)
ABINIT GPL Fortran PW
ACES II Acad Fortran GTO
ACES II MAB Acad. Fortran GTO
ACES III GPL Fortran/C++ GTO
ADF Comm Fortran STO
ATK Comm C++/Pyton NAO/EHT

8. AB INITIO PACKAGES CADPAC Acad Fortran GTO COLUMBUS Acad Fortran GTO
CRYSTAL Acad Fortran GTO
DALTON Acad Fortran GTO
DFT GPL C PW/Wavelet
DIRAC Acad F77, 90, C GTO
GAMESS Acad/Comm Fortran GTO
GAUSSIAN Comm Fortran GTO
MOLCAS Comm Fortran GTO
MOLPRO Comm Fortran GTO
NWChem ECLv F77/C GTO, PW
TERACHEM Comm C/CUDA GTO

9. DATA FORMATS
°QC: FIXED GEOMETRY MULTI STATE - SD (Small data) input, parameters, properties -> formatted human readable like XML - LD (Large data) binary working quantities like 4 index integrals IJKL  OPEN BABEL: open, collaborative project allowing search, conversion, analysis, or data storing in CMMST CML: A XML-based format for chemistry HDF5: a hierarchical data model °QD: ALL GEOMETRIES SINGLE STATE (formats as for QC)

10. HDF5
° CONTAINERS (groups) domains of quantities defined by common basis functions (AO atomic orbitals, MO molecular orbitals, Wave functions WF, ..) ° METADATA (attributes) simple and small sets of data describing a set of data ° DATA (data ses) large set of binary quantities referring to wavefunction integrals storing in matrices with an arbitrary number of indices ° LIBRARIES (Utilities and tools) Q5dump reports the content of Q5cost files Q5edit python based program text editor

11. Determinants/ coefficients
System
overlap
oneint
twoint
Title
Electrons /a,b AO
Name
Num_orb_sym
Num_orb_tot Labels
Transformation MO
AO_pointer
Num_orb_tot Labels Orbitals SCF_energy
Classification
Occ_num
Symmetry
Ctime (s)
Atime (s)
Q5version (s)
Symmetry:
- num_sym
- labels
densities
Geometry:
- charges
- coordinates
- nuclear_energy
- num_atom
- atomic_number
Basis
Coord system
Atom
Angular number
Magnetic number Coeff/exp
Num of contracted
Num of primitives
prop
Description
Rank
Real/Complex
Index/value WF
MO_pointer
Energy
Core Energy
Num_dets
DetCoeff
Determinants/ coefficients
Energy derivatives
Non adiabatic coupling
EXTENSION OF Q5 TO SUPPORT D5

12. INSERTION OF Q5/D5 IN GEMS
Fitting
ForceField
SMatrix
QuantumFunction
Trajectories
Spectra
CrossSection
RateCoeffs
System
Interaction
Dynamics
Observables
AbInitio
q5 “file system” +
energy derivatives +
non-ad. coupling els. –
system general info

13. QUANTUM DYNAMICS PACKAGES
ABC
RWAVEPR
FLUSS
MCTDH

14. CLASSICAL DYNAMICS PACKAGES (LARGE SYSTEMS)
VENUS
AMBER
CHARMM
DL_POLY
GROMACS
MOLDY
TINKER
YASARA

15. Force field representation
Many body expansion truncated
to two-body terms
Two body terms are of the
atom(ion) – atom(ion) type
Portability among different systems

16. 2) HTC – HPC FUNCTIONALITIES TRANSFER BETWEEN IGI AND PRACE

17. THE DECOUPLED TRAJECTORY DISTRIBUTION
Define quantities of general
use
TRAJ
Iterate over initial conditions
the integration of individual
trajectories (ABCTRAJ, etc.)
Collect individual trajectory results
return 17

18. Define quantities of general
THE DECOUPLED WAVEPACKET DISTRIBUTION
Define quantities of general
use
Iterate over initial conditions
the time propagation
(RWAVEPR, CYLHYP, etc.) TD
Collect single initial state
S matrix element
return 18

19. DECOUPLING QUANTUM TIME INDEPENDENT
Define quantities of general
use including the integration
bed TI
Iterate over the reaction coor-
dinate to build the interaction
matrix
Collect coupling matrix elements
Broadcast coupling matrix
Iterate over total energy value
the integration of scattering
equations
return
Collect state to state S matrix
elements 19

20. THE DISTRIBUTION OF SUPSIM (Ab initio)
Iterate over the system
Geometries the call of ab
initio suites of codes
(GAMESS, GAUSSIAN, MOLPRO, etc)
Define the characteristics of
the ab initio calculation, the
coordinates used and the
Variable’s intervals
SUPSIM
L. Storchi, F. Tarantelli, A. Lagana’, Computing Molecular energy surfaces on the grid, Lecture Notes in Computer Science 3980, (2006).
return
Collect single molecular geometry energy 20

21. SUPSIM: HTC + HPC (squares) CALCULATIONS

22. MCTDH: HPC (square) + HTC CALCULATIONS

23. GriF: a collaborative tool for grid empowering computational applications
Makes grid applications black box like and the distribution of tasks over the grid automatic.
Adopt a collaborative JAVA Service Oriented Architecture (SOA) framework articulated as a set of grid services
Provide users with standard operational modalities based on friendly user driven services allowing the composition of one or more services transparently to their implementation details.
Conveniently OPTIMIZES THE ROUTING of the jobs to the MOST appropriate HTC OR HPC machine
C. Manuali – A. Laganà
University of Perugia (IT)

24. Service Oriented organization of GriF: two JAVA servers, one JAVA client
TOP
1,2 service discovery
3-7 program execution on the UI
YR= yet a registry
YP= yet a provider
YC = yet a client
BOTTOM
grid proxy
management and its YC
interaction

25. THE GRIF SERVICE ORIENTED APPROACH
A repository (Softscience?) of services
A metric to evaluate QoS and QoU
A credit award and service cost system
A parameterized resources selection
C. Manuali, A. Lagana’
GRIF: A New Collaborative Framework for a Web Service Approach to Grid Empowered Calculations
Future Generation of Computer Systems, 27(3), (2011) DOI /j.future

26. 3) INCORPORATE GEMS INTO KNOWLEDGE OBJECTS (KO)

27. THE DISTRIBUTED REPOSITORY OF KNOWLEDGE OBJECTS
Incorporate GEMS into KOs
Reusable, downloadable units of knowledge.
KOs stored in distributed repositories.
Online indexes of KO with access control.
Dynamical evolution of KOs and distributed repositories
Linking repositories belonging to different organizations on the Grid to share contents and mutually improve them.
So, here’s what we thought:
-we could package content into Learning Objects, which are self-contained units of knowledge regarding a particular subject
-then we also could store these learning objects into repositories, which are websites that allow authenticated users to browse and download the learning content
- finally, if we could make our repositories talk to each other, we could have an environment where learning materials are able to freely flow and be downloaded and used easily 27

28. BASIC FEATURES Core Drupal Modules Freely available community modules
Two (opensource) custom modules
Some federates (to begin testing)
A database
And here’s our final recipe:
We took the core drupal modules
A couple of freely available community modules
We wrote two addittional modules
And added some federates and a database to the mix 28

29. KO SW Our results Federation of autonomous repositories
Automatic content sharing
Downloadable content (for registered users)
Simplified content import from Moodle
KO Dependency management SW
And here it is what we got from it: a distributed federation with no central server (meaning that all the federates have the same importance) capable of automatic real-time content sharing, allowing users of any federate to browse and download content uploaded to any other federate. To ease the initial population phase, content can be added using an optional Moodle import module, which allows an administrator to transfer existing content from a Moodle installation.
Plus, we added dependency management: If you think about Learning Objects from a wider perspective, they could be not only simple text files, slides or pdfs, but they could be more complex objects like 3d virtual worlds and uncommon file formats which will need special software tools to be visualized by the end user. Dependencies allows to create a relationship between the learning object and what we call software attachment in order to tie the two together. In this way the system will ensure that the user always downloads the required software attachments when he or she requests learning objects from the repository. KO 29

30. An implemented use caseKO
Chemistry (Perugia)
Computer Science (Perugia)
The use case I’m going to talk about involves two different repositories:
The first one is the computer science repository, where an user with elevated privileges will upload FreeWRL
, an opensource X3D viewer, as a software attachment.
Then we will add a second repository, belonging to the chemistry department, and we will make both join the same federation. After this step we will see that a user of the chemistry repository willing to download an X3D Learning Object, will also automatically get the needed software attachment. SW
User icons by pixel-mixer.com 30

31. NEXT STEPS
Stabilize the other sites (Thessaloniki, Madrid, Lyon) and add new ones
Improve software
Speed up synchronization/recovery,
Upgrade online visualizers for particular file formats (pictures, TEX files…)
Extend KOs’ lifetime
Allow third parties to improve existing KOs
Track KOs after the download
Allow uploading KO outputs to the Repository
Our future plans include to speedup network transmissions and further improve repository reliability in case of network problems
We’d also like to intelligently visualize particular content type like tex files
We’re currently working on an accessory module to allow others to attach content to existing learning objects
We’re also aiming at tracking LO usage after the download with auxiliary software capable of sending back certain informations to the federation on user request
We’re also currently working on a way to automatically import content from moodle, wich is a well known lms, to drupal. 31

32. The new use case
Chemistry (Perugia)
Computer Science (Perugia) KO KO SW
It’s not mandatory that the requesting student belongs to the chemistry or the computer science repository, in fact it could be registered to a different repository, as long as it belongs to the same federation. The download procedure is slightly different though.
The user will find the learning object listed on the server he belongs to, but the learning object, as we just saw, is not stored there. The second chemistry server will then ask the one in Perugia to authorize the LO download, and in response to this request an authorization token will be issued: this token will be sent back to the requesting server that will redirect the user to the download page on the chemistry repository in perugia, where he will finally download the requested LO
along with the needed software attachment.
Chemistry (Tessaloniki) SW
User icons by pixel-mixer.com 32

33. AIR POLLUTION SIMULATION
CPM10 Concentration from CHIMERE-aerosols 33

34. SUMMARY Flux and (standardized) data transfer
Functionalities integration including HTC-HPC
Knowledge transfer, evolution and communication

35. FUNDING AND COLLABORATIONS
CDK group, Dept. Chemistry, Perugia (Crocchianti, Faginas Lago, Pacifici, Skouteris, Costantini, Rampino, Manuali, Verdicchio, Filomia)
HPC group, Dept. Math&Inf, Perugia (Gervasi, Tasso)
DeciQ and Qdyn groups of COST D37
COMPCHEM Virtual Organization
EGI-Inspire, ESA, Computational Chemistry Division of the European Chemical Society
TANKS FOR YOUR ATTENTION