The codes are based on my event-driven molecular dynamics packing codes, so one should first read the documentation for them:
http://cherrypit.princeton.edu/donev/Packing/PackLSD/index.html
Also essential reading is:
"Stochastic Event-Driven Molecular Dynamics", by A. Donev, A. L. Garcia and B. J. Alder, 2007, J. Comp. Phys., 227(4):2644-2665, 2008

As a first step, download this tar file:
http://cherrypit.princeton.edu/donev/Packing/PackLSD/Polymer.tar.gz
It has an executable program that should run on generic Linux x86 machines, along with input files. It uses OpenGL for visualization, which should be helpful at first. As a first try the example is in 2D since things can be visualized better (the example uses a sample geometry/electric fields generated using Programs/Indentation.x). We'll move to 3D later, and I should also try running your examples to make sure the parameters are OK. Try running the example:

Programs/PackLSD.32.x < Input/Polymer.2D.Electric.input

to make sure the executable runs before doing anything else. If some dynamically-linked library is missing send me the output from

ldd Programs/PackLSD.32.x

The main input file for the code is a so-called Fortran namelist input file, in this case "Input/Polymer.2D.Electric.nml", which is a sequence of
field_name=value
statements. The namelsit has many options and I have removed the ones you should not need (initially) and tried to document inside the namelist. Comments can be put anywhere inside the namelist file following an exclamation point "!", which also allows . Some of the input is single scalar numbers, some are strings delimited with "", and some are sequences of numbers (arrays). For logical values "T"=true and "F"=false. I will refer to the number of spatial dimensions as n_dims=3, and the codes also work in 2D as well. Note that setting the field log_procedure_execution="M" will produce more detailed (monitoring) output which is useful when changing any of the parameters.

In addition to the namelist input, there is also an input file that is piped into the executable and it contains some main options, including the name of the run, in this case ". The initial configuration of the polymer chain, the simulation box and boundary conditions are read from the file "Data/Polymer.2D.Electric.dat" and the connectivity of the polymer chain is read as a "contact network" from the file "Data/Polymer.2D.Electric.nml.dat". The formats of these data files are described in the above webpage. In these simulations there are two particle species, 1 for the polymer beads, and 2 for the DSMC particles.

Firstly, a note about boundary conditions. The code supports (possibly non-orthogonal) rectangular unit cells, and periodic or hard-wall conditions can be specified along each dimension. All particles collide with the hard walls as if they are hard spheres, and the walls can be specular, rough, or thermal. In addition, some of the DSMC cells can be *internal hard-wall* or *blocked* cells (bright white color in the visualization). The centroid of no particle is allowed to cross into such a cell, allowing one to specify almost arbitrary "ragged" walls like indendentations or proturberances. One can also use such blocked cells to implement flat hard walls. Note the important difference that blocked cells work based on the centroid of the particles. That is, polymer beads can get closer to a wall of blocked cells than it can to a true wall. This may translate into an effective attraction between the beads and walls made of blocked cells, which we can worry about later if it actually happens.

All non-blocked cells that neighbor blocked cells must be marked (masked) as such (bright green in the visualization). This is because the DSMC particles in such cells need to be treated more carefully if there is a polymer bead around. Instead of adding code to compute such cells automatically, for now it is part of the input files. For most runs it should suffice to only mark the nearest neighbors of each blocked cell, if the cell sizes are chosen appropriately.

The accelerations for the particles (that is, the forces due to electric fields) are read from a file, the name of which is the namelist field cells_accelerations_file. The file has the following format:

grid_dimensions n_species
HW_1 NHW_2 accelerations_1 accelerations_2 ...
...

The first line gives the number of cells along each dimension, and the number of species. The first is used to initialize the DSMC grid and the second is only there as a check. Each subsequent line refers to a single DSMC cell and tells whether it is a hard-wall (blocked) cell, whether it is a cell neighboring a hard wall, and then gives the accelerations along each dimensions for each of the species (they will be zero for species 2 since there is no pressure gradient on the solvent).

The DSMC particles are hard spheres of diameter D/4, where D is the interaction diameter for the DSMC stochastic collisions. The value 4 is in the field lsd_options%dsmc_collision_radius and it is more efficient if it is smaller, i.e., if the DSMC particles are more point-like for the purpose of the event-driven algorithm.

There are three main modes in which one can run the codes. The first mode is one in which the whole domain is filled with solvent. This mode is achieved by setting the field lsd_options%dsmc_interior_width=-1 (or simply commenting it out since the default is -1). This version should be tested first.

The second mode is one where only the region around the polymer is filled with solvent and the rest is "implicit", that is, it is assumed the far-field flow is given by simple analytical expressions (e.g., simple shear). For this, the (positive) value of the field lsd_options%dsmc_interior_width determines how many cells around each polymer bead are masked as "filled with solvent", called interior cells. The value of lsd_options%dsmc_boundary_width should usually be 1 (or at most 2) and tells how thick the layer of boundary and protective cells around the interior region is. One should systematically increase dsmc_interior_width and re-run to make sure that enough of the flow features around the polymer are captured. The option hpp_mask_blocked_cells determines whether the cells nearby walls (made of blocked cells) are also filled with solvent. This option can be set to F if there is no flow, since nothing interesting happens near walls far away from the polymer. But if there is some non-trivial flow the only way to get it resolved near complex walls such as indentations or bumps.

The third mode in which the codes can be used is where only the region around the polymer chain is particle-based, and the rest is treated using fluctuating or deterministic hydrodynamics. For now that option only works in 2D, and it requires that the hydro cells be large so that good averages can be obtained. Therefore, I do not document it in the input files.

Some additional notes. The code saves snapshots of the polymer configuration (i.e., the position of all the non-DSMC particles) after every-so-many events are processed (called stages). The output file will be easy to read and will be in
Data/Polymer.2D.Electric.nonDSMC.000.dat
where 000 here is the number of cycles, and will be incremented for each cycle if there are multiple cycles. I have programs that can read and show animations of the polymer motion from such files, if needed. The format of these files is as follows:

----
# stage_number
# time
x1 y1 z1
x2 y2 z2
...

# next_stage_number
# time
x1 y1 z1
x2 y2 z2
...
----
