Some included benchmarks not working on windows

Howdy,

I’m trying to run the lammps benchmarks on windows 7, I’ve gone through and built with different MPI and FFT libraries, as well as the mkl. Everything works single threaded, but when I try and run with mpiexec, most run, but in.chain and in.rhodo fail with information to the effect of:

job aborted:

[ranks] message

[0] application aborted

aborting MPI_COMM_WORLD, error 1, comm rank 0

LAMMPS.exe aborted the job. abort code 1

I would be grateful for any insight on to what might be causing this and how to fix it.

Thank you,

Jeremy Kemp

jeremy,

Howdy,

I’m trying to run the lammps benchmarks on windows 7, I’ve gone through and
built with different MPI and FFT libraries, as well as the mkl. Everything
works single threaded, but when I try and run with mpiexec, most run, but
in.chain and in.rhodo fail with information to the effect of:

job aborted:

[ranks] message

[0] application aborted

aborting MPI_COMM_WORLD, error 1, comm rank 0

LAMMPS.exe aborted the job. abort code 1

I would be grateful for any insight on to what might be causing this and how
to fix it.

which version of the sources do you have?
there was a little glitch in the 15 June2012
version that is fixed in the 21June2012 version

axel.

I have the june 18th versions. Is this about the #include for a non-existant header? I commented that out to get it to build, but I'll rebuild with a new tarball.

I have the june 18th versions. Is this about the #include for a non-existant header? I commented that out to get it to build, but I'll rebuild with a new tarball.

the june 18th is broken for molecular system.
you have to update to at least the june 21st version.

no. it is more subtle.

what header did you need to comment out?

axel.

After I installed any package through the visual studio macro, read_dump.cpp had an include for "style_reader.h", but I could not find it anywhere in the project, and commenting it out fixed it.

After I installed any package through the visual studio macro, read_dump.cpp had an include for "style_reader.h", but I could not find it anywhere in the project, and commenting it out fixed it.

this is a new feature. support for VS and windows is not exactly
a high priority, since the vast majority of machine worth running
LAMMPS on are operated with some kind of unix. trying to get
a well working windows version of LAMMPS is also a bit of a
challenge by the quirks of windows itself. the VS project files
are contributed by a volunteer and thus by construction always
lagging behind the development.

i occasionally compile windows binaries using a cross compiler
from linux, which eases a lot of the pains, but does not help with
the intrinsic windows OS issues, of course.

the modification you made is harmless. you essentially just
disabled some (new) features.

axel.

I've been working on a few scientific HPC applications recently, and I have to say that LAMMPS has the best windows support I've seen yet. So, I am grateful to whoever is doing that. In fact, I would be interested in seeing what tools were used to make the visual studio solution, or if it was done by hand.

And the newer June22 build works flawlessly, thank you for your assistance.

I've been working on a few scientific HPC applications recently, and I have to say that LAMMPS has the best windows support I've seen yet.

there are two components to that. a) writing portable code and making
sure that it
does compile for windows. this has been mostly done by paul crozier
and a little bit
by me (my experience in working on VMD, where the windows user base is very
large, and thus portability is extremely important has been a help).
and b) providing
the build environment for visual studio

So, I am grateful to whoever is doing that. In fact, I would be interested in seeing what tools were used to make the visual studio solution, or if it was done by hand.

according to the list of contributers,
you'd have to ask ilya valuev (cc'd).
http://lammps.sandia.gov/authors.html

i am willing to deal with a cross compiler
and answer questions, but my brain is
wired too much the unix/linux way to be
of any use on a windows machine.

And the newer June22 build works flawlessly, thank you for your assistance.

excellent!

if i may ask you a question wrt. portable build
environments. there are a lot of people that
claim using cmake would make it trivial to
support both unix/linux and windows/VS
build environments. however, i have the strong
suspicion that is similar to when people claim
their code works well on linux (with gcc), that
it would run on *any* unix machine (which is
often not true because of them not being aware
of the differences between platforms).
i would appreciate, if you could share your
perspective on this, since you are likely to
have run into a cmake based application.

thanks,
     axel.

I've not used cmake in any my own projects, but I had to use cmake to build LLVM/clang on windows, and it's still in the experimental phase. Pretty much everything else requires cross compiling or Cygwin. Well, llvm requires Cygwin as well as cmake, and relative to the time to set up cmake, most of my time was spent getting the various Cygwin and gnuwin32 set up properly. The 'experimental' stage means some parts don't yet work, even with these tools properly set up. So, from what I have seen, even with the gnu tools on windows, and cmake, it's still not easy to port to windows. They have an irc channel and some of the devs are in there regularly, so you might be able to get more insight there.