Hi,
We want us to use lammps for a distributed computing project, but need to include the reax library and the xtc library in the executable. Does anyone have any experience of how to create an executable for windows/linux with a static library?
Thanks,
Josef
p.s. why not include a Windows exe with more libraries attached for download?
This is a Q for Paul (CCd). I will say that there are a couple
dozen optional packages with LAMMPS, and several have
their own libs to be compiled separately, some in other
languages like Fortran. This is all pretty transparent on Linux,
but probably considerably more complex on Windows.
You can check out the latest src/WINDOWS dir with its
README. Supposedly all the hooks are now there
to build LAMMPS on Windows under VS, similar to
what you can do on Linux, i.e. you can include/exclude
the packages you want. See if it can do the packages
you, some of which like ReaxFF have their own libs.
Steve
This is a Q for Paul (CCd). I will say that there are a couple
dozen optional packages with LAMMPS, and several have
their own libs to be compiled separately, some in other
languages like Fortran. This is all pretty transparent on Linux,
but probably considerably more complex on Windows.
a few additional comments.
- all the libraries that are *internal* to LAMMPS are automatically
static libraries, it is mostly a matter of installing all the packages
and having the proper compiler for it. in the case of reax (not reax/c)
this requires fortran and linking fortran code from c++ is non
trivial. can't you get along with reax/c?
- since the adoption of glibc v2.x, a *fully* static binary on linux
would be a *very* bad idea a much *less* portable than a so-called
semi-static binary, that has most libraries linked in statically
with the exception of libc and its shared linker and then create
the binary on the installation with the oldest available glibc.
this is what is being done for VMD for example and has worked
very well (*very* few VMD users on linux compile it on their own
and next to nobody has issues with that).
the second option would be a more expansive package that
bundles the required shared linker, glibc and all its required
dependent libraries with the lammps binary and use a wrapper
script to launch the executable. this is the approach that many
"large" packages (OpenOffice, MATLAB) are doing to create
portable binaries.
- overall, compilation on windows with the visual studio environment
seems to be a bit cumbersome, since many parts of the LAMMPS
build system expect a unix-like environment. i have made pretty
good experiences with the MinGW port of the GNU compiler tools,
and have even been able to cross-compile well working windows
binaries from linux.
i'd be happy to help with specific details off-list, if needed,
since this seems to become a very use case specific,
non-lammps discussion.
cheers,
axel.
The LAMMPS Windows executables (a serial and a parallel version) that are available from the download page were built using cygwin, g++ (GCC) 3.4.4, GNU Make 3.82.90, and the Windows version of MPICH2. I include the "-mno-cygwin" flag so that Windows users need not have cygwin installed on their Windows machines in order to use the executables. No installation is necessary --- users simply download the executable, create their input and run. The parallel version requires MPICH2. In the latest build of these executables, about 20 of LAMMPS's 30 packages were included. The other 10 were excluded due to various difficulties in building them in this environment. If anyone would like to work on getting these included, please let me know. I'll attach the Makefiles that I used most recently in case anyone is interested.
Paul
Makefile.cygwin.mpi (2.51 KB)
Makefile.cygwin.no-mpi (2.51 KB)
Hi,
I have a question about the precision of the restart file. We’ve found that files that are restarted from a restart file produce slightly different results than those from simulations that go on uninterrupted. Is there a way to increase the precision of the the restart files?
Thanks,
Josef
Hi,
I have a question about the precision of the restart file. We've found that
files that are restarted from a restart file produce slightly different
results than those from simulations that go on uninterrupted. Is there a way
to increase the precision of the the restart files?
this has nothing to do with that.
restarts are done in full precision.
however restarting enforces a neighborlist
rebuild, which in turn will result in a reordering
of atoms and that will ultimately lead to the
divergence you notice due to floating point
math being non-commuting.
axel.
Axel is correct that there can be a variety of
subtle issues with restarting a calculation
that can lead to small round-off level precision
differences between 2 runs, and thus to divergence
of the trajectories over long timescales.
E.g. use of random #s like fix langevin, restarting
on a different number of procs, etc.
If you force the non-restarted run to reneighbor on
the same step as the restart file was written,
one issue that Axel mentioned should be eliminated.
The data written to a restart file is already at full
binary precision, so there is nothing more that can
be done about that.
Steve