It looks like "#include “lmptype.h” ’ was removed from several .cpp files in the update on Nov 20. Was there a reason for this? It has caused issues with my compilation; i get the error INT64_MAX is undefined. Is there a simple way around this issue, other than replacing that line manually after every LAMMPS update I download?
Thanks, Steven Strong
I removed it from some files b/c I thought it was redundant. It is
included in pointers.h, which nearly every other LAMMPS src file
includes (often thru a chain of includes).
I don’t see the compile errors when I build.
What are examples of files that are throwing this error, which gets
fixed by adding “include lmptype.h” ??
Steve
Here is the list of files for which I get compile errors:
neb.cpp
prd.cpp
read_data.cpp
read_dump.cpp
tad.cpp
thermo.cpp
I removed it from some files b/c I thought it was redundant. It is
included in pointers.h, which nearly every other LAMMPS src file
includes (often thru a chain of includes).I don't see the compile errors when I build.
What are examples of files that are throwing this error, which gets
fixed by adding "include lmptype.h" ??
... and more importantly, what compiler/OS platform is this on?
It is a ROCKS cluster using icc.
When I last compiled lammps (the 5 Nov 14 version), using the same makefile, there were no issues. And this time, once I add #include lmptype.h to the top of each include list, it compiles with no problems. However, if i add lmptype.h at the bottom of the list, it gives the same error (INT64_MAX is undefined). An older thread says that lmptype.h must be included before mpi.h (http://lammps.sandia.gov/threads/msg26519.html). So possibly the problem is that in those files, the chain which includes pointers.h isn’t included before mpi.h.
It is a ROCKS cluster using icc.
which version of ROCKS (or rather which version or RHEL/CentOS)?
32-bit or 64-bit?
When I last compiled lammps (the 5 Nov 14 version), using the same makefile,
there were no issues. And this time, once I add #include lmptype.h to the
top of each include list, it compiles with no problems. However, if i add
lmptype.h at the bottom of the list, it gives the same error (INT64_MAX is
undefined). An older thread says that lmptype.h must be included before
mpi.h (http://lammps.sandia.gov/threads/msg26519.html). So possibly the
problem is that in those files, the chain which includes pointers.h isn't
included before mpi.h.
i regularly compile with icc and have so far never seen this.
which version of icc and what MPI library do you have?
axel.
It is CentOS 5.4 x86_64 (ROCKS 5.3)
icc v11.1
openmpi v1.4.1
It is CentOS 5.4 x86_64 (ROCKS 5.3)
oh. that is *very* old. quite possible that this one's C library is
not fully up to the standard level as it is based on software that was
released at least 8 years ago.
BTW: unless you have somebody using LAMMPS on huge systems with > 2
billion atoms, you should be able to compile LAMMPS with
-DLAMMPS_SMALLSMALL without any modifications and without any negative
side effects.
Thanks for the details.
So neb.cpp includes neb.h which includes pointers.h
which includes lmptype.h. Similarly for all the
other files in your list.
So I don’t see how adding lmptype.h to neb.cpp
helps the compilation find INT64_MAX. It included
lmptype.h either way. Any ideas Axel?
If you are updating LAMMPS with the new files,
I would make sure that you do a “make clean-all”
first, to see if that helps with some broken dependency.
Steve
I have tried make clean-all, and it doesn’t make a difference
An older thread (http://lammps.sandia.gov/threads/msg26519.html) says that lmptype.h must be included before mpi.h, when using openMPI, which I am. This seems to be to be the issue, because if I move the include mpi.h to the end of the list in neb.cpp, it compiles fine, even without lmptype.h. Also, the flag -DLAMMPS_SMALLSMALL solves the problem; I’m not running anything larger than 2 billion atoms.
Thanks, Steve
yep, that’s the issue - nice find
The files you list are ones that include mpi.h and also use MAXBIGINT.
They need to also include lmptype.h before mpi.h b/c of OpenMPI’s problem.
I’ll add it back for the next patch.
thanks,
Steve
Thanks, I don’t think they need lmptype.h added back to the list though, they just need mpi.h moved to the end of the list, or moved below the header that includes pointers.h, right?
no, that causes other problems as I recall. mpi.h
should always be the first include (except for lmptype.h).
Even before the system headers, like stdlib.h
Steve