git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@10935 f3b2605a-c512-4ea7-a41b-209d697bcdaa

This commit is contained in:
sjplimp
2013-11-04 16:59:03 +00:00
parent 519dd71a0b
commit 5f9001a59d
15 changed files with 1265 additions and 1217 deletions

View File

@ -189,6 +189,7 @@ within the LAMMPS code. The options that are currently recogized are:
<UL><LI>-DLAMMPS_GZIP
<LI>-DLAMMPS_JPEG
<LI>-DLAMMPS_PNG
<LI>-DLAMMPS_FFMPEG
<LI>-DLAMMPS_MEMALIGN
<LI>-DLAMMPS_XDR
<LI>-DLAMMPS_SMALLBIG
@ -200,18 +201,25 @@ within the LAMMPS code. The options that are currently recogized are:
<LI>-DPACK_MEMCPY
</UL>
<P>The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your Unix support the
"popen" command.
compile with -DLAMMPS_GZIP. It requires that your machine supports
the "popen" function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.
</P>
<P>If you use -DLAMMPS_JPEG, the <A HREF = "dump.html">dump image</A> command will be
able to write out JPEG image files. For JPEG files, you must also link
LAMMPS with a JPEG library, as described below. If you use
<P>If you use -DLAMMPS_JPEG, the <A HREF = "dump_image.html">dump image</A> command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the <A HREF = "dump.html">dump image</A> command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out text-based PPM image
used, LAMMPS will only be able to write out uncompressed PPM image
files.
</P>
<P>If you use -DLAMMPS_FFMPEG, the <A HREF = "dump_image.html">dump movie</A> command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the "popen" function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.
</P>
<P>Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of

View File

@ -183,6 +183,7 @@ within the LAMMPS code. The options that are currently recogized are:
-DLAMMPS_GZIP
-DLAMMPS_JPEG
-DLAMMPS_PNG
-DLAMMPS_FFMPEG
-DLAMMPS_MEMALIGN
-DLAMMPS_XDR
-DLAMMPS_SMALLBIG
@ -194,18 +195,25 @@ within the LAMMPS code. The options that are currently recogized are:
-DPACK_MEMCPY :ul
The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your Unix support the
"popen" command.
compile with -DLAMMPS_GZIP. It requires that your machine supports
the "popen" function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.
If you use -DLAMMPS_JPEG, the "dump image"_dump.html command will be
able to write out JPEG image files. For JPEG files, you must also link
LAMMPS with a JPEG library, as described below. If you use
If you use -DLAMMPS_JPEG, the "dump image"_dump_image.html command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the "dump image"_dump.html command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out text-based PPM image
used, LAMMPS will only be able to write out uncompressed PPM image
files.
If you use -DLAMMPS_FFMPEG, the "dump movie"_dump_image.html command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the "popen" function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.
Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of

View File

@ -97,8 +97,8 @@
dump 2 subgroup atom 50 dump.run.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg id type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg id type xs ys zs id type c_Stress<B>2</B>
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress<B>2</B>
dump 1 all xtc 1000 file.xtc
dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce
</PRE>
@ -237,9 +237,9 @@ extended CFG format files, as used by the
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "*" must be included in the filename, as
discussed below. The list of atom attributes for style <I>cfg</I> must
begin with either "id type xs ys zs" or "id type xsu ysu zsu" or
begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
since these quantities are needed to
write the CFG files in the appropriate format (though the "id" and
write the CFG files in the appropriate format (though the "mass" and
"type" fields do not appear explicitly in the file). Any remaining
attributes will be stored as "auxiliary properties" in the CFG files.
Note that you will typically want to use the <A HREF = "dump_modify.html">dump_modify

View File

@ -85,8 +85,8 @@ dump myDump all atom 100 dump.atom
dump 2 subgroup atom 50 dump.run.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF\[3\] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg id type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg id type xs ys zs id type c_Stress[2]
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress[2]
dump 1 all xtc 1000 file.xtc
dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce :pre
@ -225,9 +225,9 @@ extended CFG format files, as used by the
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "*" must be included in the filename, as
discussed below. The list of atom attributes for style {cfg} must
begin with either "id type xs ys zs" or "id type xsu ysu zsu" or
begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
since these quantities are needed to
write the CFG files in the appropriate format (though the "id" and
write the CFG files in the appropriate format (though the "mass" and
"type" fields do not appear explicitly in the file). Any remaining
attributes will be stored as "auxiliary properties" in the CFG files.
Note that you will typically want to use the "dump_modify

View File

@ -25,8 +25,14 @@
<LI>Nwait = wait this many timesteps before measuring
<LI>map_file = file containing the mapping info between atom ID and the lattice indices
<LI>map_file = <I>file</I> or <I>GAMMA</I>
<PRE> <I>file</I> is the file that contains the mapping info between atom ID and the lattice indices.
</PRE>
<PRE> <I>GAMMA</I> flags to treate the whole simulation box as a unit cell, so that the mapping
info can be generated internally. In this case, dynamical matrix at only the gamma-point
will/can be evaluated.
</PRE>
<LI>prefix = prefix for output files
<LI>one or none keyword/value pairs may be appended
@ -44,6 +50,7 @@
</P>
<PRE>fix 1 all phonon 20 5000 200000 map.in LJ1D sysdim 1
fix 1 all phonon 20 5000 200000 map.in EAM3D
fix 1 all phonon 10 5000 500000 GAMMA EAM0D nasr 100
</PRE>
<P><B>Description:</B>
</P>
@ -124,6 +131,13 @@ which lattice point; the lattice indices start from 0. An auxiliary
code, <A HREF = "http://code.google.com/p/latgen">latgen</A>, can be employed to
generate the compatible map file for various crystals.
</P>
<P>In case one simulates an aperiodic system, where the whole simulation box
is treated as a unit cell, one can set <I>map_file</I> as <I>GAMMA</I>, so that the mapping
info will be generated internally and a file is not needed. In this case, the
dynamical matrix at only the gamma-point will/can be evaluated. Please keep in
mind that fix-phonon is designed for cyrstals, it will be inefficient and
even degrade the performance of lammps in case the unit cell is too large.
</P>
<P>The calculated dynamical matrix elements are written out in
<A HREF = "units.html">energy/distance^2/mass</A> units. The coordinates for <I>q</I>
points in the log file is in the units of the basis vectors of the

View File

@ -17,7 +17,12 @@ phonon = style name of this fix command :l
N = measure the Green's function every this many timesteps :l
Noutput = output the dynamical matrix every this many measurements :l
Nwait = wait this many timesteps before measuring :l
map_file = file containing the mapping info between atom ID and the lattice indices :l
map_file = {file} or {GAMMA} :l
{file} is the file that contains the mapping info between atom ID and the lattice indices. :pre
{GAMMA} flags to treate the whole simulation box as a unit cell, so that the mapping
info can be generated internally. In this case, dynamical matrix at only the gamma-point
will/can be evaluated. :pre
prefix = prefix for output files :l
one or none keyword/value pairs may be appended :l
keyword = {sysdim} or {nasr} :l
@ -30,7 +35,8 @@ keyword = {sysdim} or {nasr} :l
[Examples:]
fix 1 all phonon 20 5000 200000 map.in LJ1D sysdim 1
fix 1 all phonon 20 5000 200000 map.in EAM3D :pre
fix 1 all phonon 20 5000 200000 map.in EAM3D
fix 1 all phonon 10 5000 500000 GAMMA EAM0D nasr 100 :pre
[Description:]
@ -111,6 +117,13 @@ which lattice point; the lattice indices start from 0. An auxiliary
code, "latgen"_http://code.google.com/p/latgen, can be employed to
generate the compatible map file for various crystals.
In case one simulates an aperiodic system, where the whole simulation box
is treated as a unit cell, one can set {map_file} as {GAMMA}, so that the mapping
info will be generated internally and a file is not needed. In this case, the
dynamical matrix at only the gamma-point will/can be evaluated. Please keep in
mind that fix-phonon is designed for cyrstals, it will be inefficient and
even degrade the performance of lammps in case the unit cell is too large.
The calculated dynamical matrix elements are written out in
"energy/distance^2/mass"_units.html units. The coordinates for {q}
points in the log file is in the units of the basis vectors of the

View File

@ -13,6 +13,7 @@
/* ----------------------------------------------------------------------
Contributing author: Liang Wan (Chinese Academy of Sciences)
Memory efficiency improved by Ray Shan (Sandia)
------------------------------------------------------------------------- */
#include "math.h"
@ -34,7 +35,7 @@
using namespace LAMMPS_NS;
enum{INT,DOUBLE}; // same as in dump_custom.cpp
enum{INT,DOUBLE,STRING}; // same as in DumpCustom
/* ---------------------------------------------------------------------- */
@ -42,26 +43,23 @@ DumpCFG::DumpCFG(LAMMPS *lmp, int narg, char **arg) :
DumpCustom(lmp, narg, arg)
{
if (narg < 10 ||
strcmp(arg[5],"id") != 0 || strcmp(arg[6],"type") != 0 ||
strcmp(arg[5],"mass") != 0 || strcmp(arg[6],"type") != 0 ||
(strcmp(arg[7],"xs") != 0 && strcmp(arg[7],"xsu") != 0) ||
(strcmp(arg[8],"ys") != 0 && strcmp(arg[8],"ysu") != 0) ||
(strcmp(arg[9],"zs") != 0 && strcmp(arg[9],"zsu") != 0))
error->all(FLERR,"Dump cfg arguments must start with "
"'id type xs ys zs' or 'id type xsu ysu zsu'");
"'mass type xs ys zs' or 'mass type xsu ysu zsu'");
if (strcmp(arg[7],"xs") == 0)
if (strcmp(arg[8],"ysu") == 0 || strcmp(arg[9],"zsu") == 0)
error->all(FLERR,"Dump cfg arguments can not mix xs|ys|zs with xsu|ysu|zsu");
error->all(FLERR,
"Dump cfg arguments can not mix xs|ys|zs with xsu|ysu|zsu");
else unwrapflag = 0;
else if (strcmp(arg[8],"ys") == 0 || strcmp(arg[9],"zs") == 0)
error->all(FLERR,"Dump cfg arguments can not mix xs|ys|zs with xsu|ysu|zsu");
error->all(FLERR,
"Dump cfg arguments can not mix xs|ys|zs with xsu|ysu|zsu");
else unwrapflag = 1;
// arrays for data rearrangement
rbuf = NULL;
nchosen = nlines = 0;
// setup auxiliary property name strings
// convert 'X_ID[m]' (X=c,f,v) to 'ID_m'
@ -105,8 +103,6 @@ DumpCFG::DumpCFG(LAMMPS *lmp, int narg, char **arg) :
DumpCFG::~DumpCFG()
{
if (rbuf) memory->destroy(rbuf);
if (auxname) {
for (int i = 0; i < nfield-5; i++) delete [] auxname[i];
delete [] auxname;
@ -117,7 +113,8 @@ DumpCFG::~DumpCFG()
void DumpCFG::init_style()
{
if (multifile == 0) error->all(FLERR,"Dump cfg requires one snapshot per file");
if (multifile == 0)
error->all(FLERR,"Dump cfg requires one snapshot per file");
DumpCustom::init_style();
}
@ -160,78 +157,57 @@ void DumpCFG::write_header(bigint n)
fprintf(fp,"entry_count = %d\n",nfield-2);
for (int i = 0; i < nfield-5; i++)
fprintf(fp,"auxiliary[%d] = %s\n",i,auxname[i]);
// allocate memory needed for data rearrangement
nchosen = static_cast<int> (n);
if (rbuf) memory->destroy(rbuf);
memory->create(rbuf,nchosen,size_one,"dump:rbuf");
}
/* ----------------------------------------------------------------------
write data lines to file in a block-by-block style
write head of block (mass & element name) only if has atoms of the type
------------------------------------------------------------------------- */
/* ---------------------------------------------------------------------- */
void DumpCFG::write_data(int n, double *mybuf)
{
int i,j,m,itype;
int i,j,m;
double *rmass = atom->rmass;
double *mass = atom->mass;
// transfer data from buf to rbuf
// if write by proc 0, transfer chunk by chunk
for (i = 0, m = 0; i < n; i++) {
for (j = 0; j < size_one; j++)
rbuf[nlines][j] = mybuf[m++];
nlines++;
if (unwrapflag == 0) {
m = 0;
for (i = 0; i < n; i++) {
for (j = 0; j < size_one; j++) {
if (j == 0) {
fprintf(fp,"%f \n",mybuf[m]);
} else if (j == 1) {
fprintf(fp,"%s \n",typenames[(int) mybuf[m]]);
} else if (j >= 2) {
if (vtype[j] == INT)
fprintf(fp,vformat[j],static_cast<int> (mybuf[m]));
else if (vtype[j] == DOUBLE)
fprintf(fp,vformat[j],mybuf[m]);
else if (vtype[j] == STRING)
fprintf(fp,vformat[j],typenames[(int) mybuf[m]]);
}
// write data lines in rbuf to file after transfer is done
m++;
}
fprintf(fp,"\n");
}
} else if (unwrapflag == 1) {
m = 0;
double unwrap_coord;
if (nlines == nchosen) {
for (itype = 1; itype <= ntypes; itype++) {
for (i = 0; i < nchosen; i++)
if (rbuf[i][1] == itype) break;
if (i < nchosen) {
if (rmass) fprintf(fp,"%g\n",rmass[i]);
else fprintf(fp,"%g\n",mass[itype]);
fprintf(fp,"%s\n",typenames[itype]);
for (; i < nchosen; i++) {
if (rbuf[i][1] == itype) {
if (unwrapflag == 0)
for (j = 2; j < size_one; j++) {
if (vtype[j] == INT)
fprintf(fp,vformat[j],static_cast<int> (rbuf[i][j]));
else fprintf(fp,vformat[j],rbuf[i][j]);
}
else {
// Unwrapped scaled coordinates are shifted to
// center of expanded box, to prevent
// rewrapping by AtomEye. Dividing by
// expansion factor restores correct
// interatomic distances.
for (j = 2; j < 5; j++) {
unwrap_coord = (rbuf[i][j] - 0.5)/UNWRAPEXPAND + 0.5;
for (i = 0; i < n; i++) {
for (j = 0; j < size_one; j++) {
if (j == 0) {
fprintf(fp,"%f \n",mybuf[m]);
} else if (j == 1) {
fprintf(fp,"%s \n",typenames[(int) mybuf[m]]);
} else if (j >= 2 && j <= 4) {
unwrap_coord = (mybuf[m] - 0.5)/UNWRAPEXPAND + 0.5;
fprintf(fp,vformat[j],unwrap_coord);
}
for (j = 5; j < size_one; j++) {
} else if (j >= 5 ) {
if (vtype[j] == INT)
fprintf(fp,vformat[j],static_cast<int> (rbuf[i][j]));
else fprintf(fp,vformat[j],rbuf[i][j]);
fprintf(fp,vformat[j],static_cast<int> (mybuf[m]));
else if (vtype[j] == DOUBLE)
fprintf(fp,vformat[j],mybuf[m]);
else if (vtype[j] == STRING)
fprintf(fp,vformat[j],typenames[(int) mybuf[m]]);
}
m++;
}
fprintf(fp,"\n");
}
}
}
}
nlines = 0;
}
}

View File

@ -31,14 +31,12 @@ class DumpCFG : public DumpCustom {
private:
char **auxname; // name strings of auxiliary properties
int nchosen; // # of lines to be written on a writing proc
int nlines; // # of lines transferred from buf to rbuf
double **rbuf; // buf of data lines for data lines rearrangement
int unwrapflag; // 1 if unwrapped coordinates are requested
void init_style();
void write_header(bigint);
void write_data(int, double *);
};
}

View File

@ -44,7 +44,7 @@ enum{ID,MOL,TYPE,ELEMENT,MASS,
TQX,TQY,TQZ,SPIN,ERADIUS,ERVEL,ERFORCE,
COMPUTE,FIX,VARIABLE};
enum{LT,LE,GT,GE,EQ,NEQ};
enum{INT,DOUBLE,STRING};
enum{INT,DOUBLE,STRING}; // same as in DumpCFG
#define INVOKED_PERATOM 8

View File

@ -8,6 +8,14 @@ dump2try99.py same as dump2trj for LAMMPS 99 format
-------------------------
Modifications in file amber2lammps.py, by Vikas Varshney
Dated Nov 4, 2013
Email address: vv0210@gmail.com
added support for flags used in current version of AMBER
-------------------------
Modifications in file amber2lammps.py, by Vikas Varshney
Dated July 5, 2005
Email address : vv5@uakron.edu

View File

@ -8,6 +8,7 @@
#
# Modified by Vikas Varshney, U Akron, 5 July 2005, as described in README
# Bug Fixed :Third argument in Dihedral Coeffs section is an integer - Ketan S Khare September 26, 2011
# Modified by Vikas Varshney, Oct 8, 2013 to include additional flags (Atomic_Number, Coulombic and van der Waals 1-4 factors which are included in newer vesions of .top and .crd files in amber12.
#============================================================
@ -554,6 +555,11 @@ class Amber:
for i in range(self.NATOM):
self.CHRG.append(eval(Pop(Item_list,0)))
print 'Reading Atomic Number...'
self.ANUMBER = []
for i in range(self.NATOM):
self.ANUMBER.append(eval(Pop(Item_list,0)))
print 'Reading Atomic Masses...'
self.AMASS = []
for i in range(self.NATOM):
@ -619,6 +625,16 @@ class Amber:
for i in range(self.NPTRA):
self.PHASE.append(eval(Pop(Item_list,0)))
print 'Reading 1-4 Electrostatic Scaling Factor...'
self.SCEEFAC = []
for i in range(self.NPTRA):
self.SCEEFAC.append(eval(Pop(Item_list,0)))
print 'Reading 1-4 Van der Waals Scaling Factor...'
self.SCNBFAC = []
for i in range(self.NPTRA):
self.SCNBFAC.append(eval(Pop(Item_list,0)))
print 'Reading Solty...' #I think this is currently not used in AMBER. Check it out, though
self.SOLTY = []
for i in range(self.NATYP):

View File

@ -1,6 +1,13 @@
Stephanie Teich-McGoldrick (Sandai) is the current maintainer
of the msi2lmp tool. She can be contacted at steichm at sandia.gov
08 Oct 2013 Axel Kohlmeyer <akohlmey@gmail.com>
Fixed a memory access violation with Class 2 force fields.
Free all allocated memory to better detection of memory errors.
Print out version number and data with all print levels > 0.
Added valgrind checks to the regression tests
02 Aug 2013 Axel Kohlmeyer <akohlmey@gmail.com>
Added rudimentary support for OPLS-AA based on