You will be presented with the full text of a science research paper. Please write an abstract for this paper. Your response should include the abstract and no additional text.

Paper text:
studying the early universe requires describing the evolution of interacting fields in a dense , high - energy environment .
the study of reheating after inflation and the subsequent thermalization of the fields produced in this process typically involves non - perturbative interactions of fields with exponentially large occupations numbers in states far from thermal equilibrium .
various approximation methods have been applied to these calculations , including linearized analysis and the hartree approximation .
these methods fail , however , as soon as the field fluctuations become large enough that they can no longer be considered small perturbations .
in such a situation linear analysis no longer makes sense and the hartree approximation neglects important rescattering terms . in many models of inflation preheating can amplify fluctuations to these large scales within a few oscillations of the inflaton field .
moreover , such large amplification appears to be a generic feature , arising via parametric resonance in single - field inflationary models and tachyonic instabilities in hybrid models .
the only way to fully treat the nonlinear dynamics of these systems is through lattice simulations .
these simulations directly solve the classical equations of motion for the fields .
although this approach involves the approximation of neglecting quantum effects , these effects are exponentially small once preheating begins .
so in any inflationary model in which preheating can occur lattice simulations provide the most accurate means of studying post - inflationary dynamics .
in 2000 g.f.and igor tkachev released latticeeasy @xcite , a c++ program for simulating scalar field evolution in an expanding universe . in the ensuing years latticeeasy
has been used by us and other groups to study such topics as preheating , baryogenesis , gravity wave production , and more .
these simulations have been extremely useful , but they have for the most part been confined to relatively simple toy models , primarily due to computational limitations .
to study cosmology in more complex models such as the mssm or gut theories will require the use of large , parallel clusters .
clustereasy is a version of latticeeasy that can be run in parallel on multiple processors .
section [ overview ] of this paper gives a brief overview of what latticeeasy does and how to use it , and notes the modifications that must be made in the latticeeasy files to run them in clustereasy .
section [ implementation ] describes the algorithms used to parallelize the simulations . for more detailed documentation
the reader is referred to the latticeeasy website ` http://www.science.smith.edu/departments/physics/fstaff/gfelder/latticeeasy/ `
latticeeasy consists of several c++ files , but only two are designed to be modified by most users .
each particular scalar field potential that the program solves is encoded in a _ model file _ called model.h , in which the user enters equations for the potential and its various derivatives .
the parameters that control individual runs are stored in a file called parameters.h .
these parameters include physical quantities such as masses and couplings , numerical quantities such as the number of gridpoints and the size of the time step , and parameters to control what types of output are generated by the simulation .
to use clustereasy the user must replace all of the non - user - modifiable files from latticeeasy with the new , clustereasy versions . the parameter files from latticeeasy can be used with no changes , however , and the model files only need the addition of two lines , described in the online documentation .
the formats of the outputs created by clustereasy are the same as those from the serial version .
one of the output options is to create a grid image that can be used to resume a run and continue it to later times .
grid images created by latticeeasy can be read in by clustereasy and vice - versa . the only way to distinguish clustereasy output from latticeeasy output is the file info , which contains basic information about the run such as the potential used and the physical and numerical parameters . in clustereasy this file has an additional line specifying the number of processors used for the run .    to run clustereasy
you need a cluster with mpi .
mpi is a standard set of libraries used for parallel programming in c , c++ , and fortran , and should be installed on any standard cluster .
you also need the freely available fourier transform library fftw .
( see the online documentation for possible compatibility issues with the way fftw is installed on different systems and how to resolve them . )    the makefile that comes with clustereasy assumes that the command for compiling a c++ mpi program is mpicc .
if this command is different on your system you will need to modify the makefile accordingly
. otherwise you should be able to compile the code simply by typing `` make . ''
you should consult your system documentation for the correct syntax for running a parallel program , but on most clusters it is ` mpirun -np < number of processors > latticeeasy ` note that the number of processors is determined at execution - time , not at compile - time .
latticeeasy uses a staggered leapfrog algorithm with a fixed time step .
this means that at each step the field values @xmath0 and their derivatives @xmath1 are stored at two different times @xmath2 and @xmath3 respectively .
the derivatives are used to advance the field values by a full step @xmath4 and then the field values are used to calculate the second derivatives @xmath5 , which are in turn used to advance the field derivatives by @xmath4 .
this evolution is done in place , meaning the newly calculated field values and/or derivatives overwrite the old ones .    to implement this scheme on multiple processors clustereasy uses `` slab decomposition , '' meaning the grid
is divided along a single dimension ( the first spatial dimension ) .
for example , in a 2d run with @xmath6 on two processors , each processor would cast a @xmath7 grid for each field . at each processor
the variable _
n _ stores the local size of the grid in the first dimension , so in this example each processor would store @xmath8 , @xmath6 . note that _ n _ is not always the same for all processors , but it generally will be if the number of processors is a factor of _ n_.    in practice , the grids are actually slightly larger than @xmath9 because calculating spatial derivatives at a gridpoint requires knowing the neighboring values , so each processor actually has two additional columns for storing the values needed for these gradients .
continuing the example from the previous paragraph , each processor would store a @xmath10 grid for each field . within this grid the values @xmath11 and @xmath12
would be used for storing `` buffer '' values , and the actual evolution would be calculated in the range @xmath13 , @xmath14 .
this scheme is shown in figure  [ clusterimage ] . at each time
step each processor advances the field values in the shaded region , using the buffers to calculate spatial derivatives .
then the processors exchange edge data . at the bottom of the figure i ve labeled the @xmath15 value of each column in the overall grid . during the exchange processor 0
would send the new values at @xmath16 and @xmath17 to processor 1 , which would send the values at @xmath18 and @xmath19 to processor 0 .
the actual arrays allocated by the program are even larger than this , however , because of the extra storage required by the fourier transform routines . in two and three dimensions clustereasy uses fftw .
when you fourier transform the fields the nyquist modes are stored in extra positions in the last dimension , so the last dimension is @xmath20 instead of @xmath21 .
the total size per field of the array at each processor is thus typically @xmath22 in 1d , @xmath23 in 2d and @xmath24 in 3d . in 2d
fftw sometimes requires extra storage for intermediate calculations as well , in which case the array may be somewhat larger than this , but usually not much .
this does not occur in 3d .
we have found that the speed of the simulation scales roughly as the number of processors , provided that number is significantly smaller than @xmath21 , the number of gridpoints along each edge of the lattice .
a good rule of thumb is that you probably wo nt get much benefit from using more processors than @xmath25 .
also , you will get slightly better performance per processor if the number of processors is a factor of @xmath21 so that the processors can divide the lattice up evenly .
clustereasy offers the opportunity to do simulations of much larger , more complex , and more realistic early universe theories than was possible with serial simulations .
we offer it in the hope that it will be useful to the research community .
the usual thanks offered in a paper are inadequate for the impressive contributions made by students and other collaborators on this project .
significant work on the project was done in particular by sirein awadalla , douglas swanson , and hal finkel .
others who contributed include jing li , dessislava michaylova , and olga navros .
i would also like to thank richard easther for valuable discussions and the canadian institute for theoretical astrophysics for hosting me during part of this work .
finally , i would like to thank igor tkachev , my collaborator on latticeeasy , without whom none of this would have been possible .
g.f . was supported by nsf grant phy-0456631 .
we describe a new , parallel programming version of the scalar field simulation program latticeeasy . 
 the new c++ program , clustereasy , can simulate arbitrary scalar field models on distributed - memory clusters . 
 the speed and memory requirements scale well with the number of processors . as with the serial version of latticeeasy 
 , clustereasy can run simulations in one , two , or three dimensions , with or without expansion of the universe , with customizable parameters and output . 
 the program and its full documentation are available on the latticeeasy website at http://www.science.smith.edu / departments / physics / fstaff / gfelder / latticeeasy/. in this paper we provide a brief overview of what clustereasy does and the ways in which it does and does nt differ from the serial version of latticeeasy 
 .    epsf