Download a non-perturbative approach for quantum field theory

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
A) Project Overview
• 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
B) Science Lesson
• Two codes presented here: ‘electron’ and ‘laser’
– electron: calculates the structure of electron based on quantum
electrodynamics (QED) nonperturbatively
1.
2.
3.
4.
–
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)
Diagonalize the Hamiltonian matrix (time-independent Schrodinger Eq.)
Obtain the eigenvalues (electron mass) and eigenstates (electron
wavefunctions) for ground state (physical electron) and several low-lying
excited states (excited electrons)
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.
2.
3.
Obtain electron wavefunction (column vector) from ‘electron’ code
Construct the operator (matrix) for the background laser field
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…
I) Scalability
• Scaling for ‘electron’:
Walltime only 223s !
24 cores
• 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
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)