Basis Light-Front Quantization: a non-perturbative approach for quantum field theory Xingbo Zhao With Anton Ilderton, Heli Honkanen, Pieter Maris, James P. Vary, Stan J. Brodsky Department of Physics and Astronomy Iowa State University Ames, USA CScADS, Snowbird, Utah, July 23-26, 2012

Basis Light-Front Quantization (BLFQ) approach – A nonperturbative numerical approach to quantum field theory – Evaluate the structure and interaction of “elementary” particles – such as electrons and nucleons, from first principle – Alternative approach to Lattice Gauge Theory History – Tam-Dancoff Method [1950s] – DLCQ [1985] – BLFQ [2010] Group member – James Vary (advisor), Pieter Maris (professor), Xingbo Zhao (postdoc), Paul Wiecki (student), Yang Li (student) Funded by DoE A) Project Overview

B) Science Lesson Two codes presented here: ‘electron’ and ‘laser’ – electron: calculates the structure of electron based on quantum electrodynamics (QED) nonperturbatively 1.Construct the Hamiltonian matrix in optimized basis (large sparse matrix; large: intrinsically infinite d.o.f for quantum field, sparse: the basis respect symmetry of the Hamiltonian) 2.Diagonalize the Hamiltonian matrix (time-independent Schrodinger Eq.) 3.Obtain the eigenvalues (electron mass) and eigenstates (electron wavefunctions) for ground state (physical electron) and several low-lying excited states (excited electrons) 4.Evaluate other observables (anomalous magnetic moment, parton distribution function) from electron wavefunction (vector-matrix-vector multiplication) – laser: calculates the radiation from electron placed in strong background laser field 1.Obtain electron wavefunction (column vector) from ‘electron’ code 2.Construct the operator (matrix) for the background laser field 3.Multiply the laser matrix with the wavefunction consecutively and obtain the quantum state at all time steps (time-dependent Schrodinger eq.)

C+D) Parallel Programming Model +Code Environment Electron: – Eigenvalue/state problem for large sparse matrix – Only a few lowest-lying states are required – (P)ARPACK used for (parallel) serial diagonalization – Fortran 90 at linux and Mac OS – MPI as sole parallelization – Blas and lapack are required by ARPACK – Numerical recipe library used for solving nonlinear algebraic equation for renormalization Laser: – Large sparse matrix-vector multiplication problem – Fortran 95 and Mathematica – Parallelization (Fortran) is planned – Matrix-vector multiplication by Fortran 95 built-in ‘matmul’

E) I/O Patterns and Strategy Input I/O and output I/O patterns – Electron: Master process reads-in single input file, and writes single output file for the entire code; both input and output files are text files – Laser: Not yet parallelized; optimization on output desired Approximate sizes of inputs and outputs (before, during, and after computation) – Electron: input: ~ KB, output: ~ KB – Laser: input: ~ GB or above, output: ~ GB or above Checkpoint / Restart capabilities: – Electron: Results are a list of data from different input parameters, each datum is written to file once available – Laser: Write the history of electron evolution while it is being generating

F) Visualization and Analysis How do you explore the data generated? – Electron A separate Fortran code reads in the output files of different runs, combines them and generates a single data file, which is subsequently sent to Grace to make plots – Laser Mathematica (manipulate[]) is used to make animation for time evolution of electron quantum state Future plans for your viz and analysis – Laser Visualize evolution of electron state in momentum space (essentially basis transform – matrix-vector multiplication)

G) Performance What do you believe is your current bottleneck to better performance? – Electron: Communication between MPI processes in the diagonalization process for Hamiltonian matrix – Laser: Parallelization needs to be done; scaling should be ok since matrix-vector multiplication involves little communication between MPI processes Future plans for improving performance – Electron: analyze the diagonalization process using perf. tools and improve the algorithm for parallelization if necessary – Laser: Implement parallelization

H) Tools Debugging – Mostly embedded write() statements to print intermediate results; Other tools – Mathematica is often used to cross-check results in small basis space cases Current status and future plans for improved tool integration and support – No experience on tool integration and support, want to learn here…

Scaling for ‘electron’: Top Pains – need to understand the message passing mechanism/process better to detect / overcome bottlenecks, hope perf. tools could help… – slow debug turnaround time esp. when large core number requested I) Scalability Walltime only 223s ! 24 cores

J) Roadmap Better understanding on parallelization based on MPI/OpenMP – Bottlenecks on current hardware and ways around – Usage of perf tools to find out bottlenecks Electron – Improve the parallelizing algorithm for the diagonalization part (reducing communication?) – Openmp/MPI Hybrid (PARPACK compatibility?) Laser – Implement parallelization using MPI/OpenMP – GPU? (mainly sparse matrix-vector multiplication)