Basis Light-Front Quantization: a non-perturbative approach

for quantum field theory

Xingbo ZhaoWith Anton Ilderton,

Heli Honkanen, Pieter Maris, James P. Vary, Stan J. Brodsky

Department of Physics and AstronomyIowa 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’ code2. 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)