Hello list,
during some debugging of one of my own fixes I stumbled across two
little issues.
1. cutsq in pair style table can remain uninitialized if not all pair
interactions are specified. This can happen if pair table is used as a
substyle in pair hybrid/overlay for only a subset of interactions.
The alternative is to supply empty tables for the interactions where
it is not needed, but since LAMMPS doesn't throw an error and the fix
is small I would sugegst to modify
PairTable::allocate() in pair_table.cpp to:
memory->create(setflag,nt+1,nt+1,"pair:setflag");
memory->create(cutsq,nt+1,nt+1,"pair:cutsq");
for (int i = 1; i <= nt; i++)
for (int j = i; j <= nt; j++) {
setflag[i][j] = 0;
cutsq[i][j] = 0.0;
}
2. During a test compile with clang (fantastic error reporting
compared to gcc) I noticed a warning pointing out:
pair_buck_long_coul_long.cpp:102:25: warning: & has lower precedence
than ==; == will be evaluated first [-Wparentheses]
if (*arg&&(ewald_order&0x42==0x42)) error->all(FLERR,PAIR_CUTOFF);
As is this evaluates as ewald_order&(0x42==0x42) which is equal to
just ewald_order
I havent examined this in detail, but I doubt that is what the author
intended, which probably is
if (*arg&&((ewald_order&0x42)==0x42)) error->all(FLERR,PAIR_CUTOFF);
And another little issue (after my previous mail got such ovewhelming
feedback 
)
There is a "using namespace std;" in dihedral_table.h it is not
necessary (can be removed) and considered bad style. It is actually
harmful if you are trying to activate the USER-REAXC package due to an
ambiguity between std::real and read (a typedef in reaxc_types.h)
which prevents successful compilation.
Cheers,
Daniel
removed it - thanks
haven't looked at your other issues yet - if a post like
a bug report requires me to think more than about 15 seconds, then
I have to wait to look into it until I have time.
Steve
removed it - thanks
there is more that can be done to clean up and simplify things.
e.g. there is overlap with math_extra.h and more stuff can be
removed from the header.
haven't looked at your other issues yet - if a post like
a bug report requires me to think more than about 15 seconds, then
I have to wait to look into it until I have time.
i've integrated the stuff into LAMMPS-ICMS so it won't get lost.
pair_buck_long_coul_long.cpp is written in a very weird and almost
unreadable style, it may be better in the long run to rewrite it to be
more similar to other pair styles in lammps. a lot of the stuff looks
like it can easily confuse a compiler at higher optimization levels.
they tend to do a much better job with simpler code, even if it is not
using any possible short cut that the programming language allows...
there are a few more of that kind. those have proven to be too
confusing to get OpenMP support working correctly with them, btw.
axel.
Fixed #2 - thanks.
For #1, I'm not seeing the issue. This would be a bug
if pair table accessed cutsq for type pairs it wasn't defined for.
But I don't think that should be the case. Pair hybrid
should only pass it a neighbor list for type pairs it is defined for.
I also think this is the way all the pair styles work. E.g. cutsq
is undefined in pair lj/cut in the same way? Or am I missing
something unique about pair table?
Steve
For #1, I'm not seeing the issue. This would be a bug
if pair table accessed cutsq for type pairs it wasn't defined for.
But I don't think that should be the case. Pair hybrid
should only pass it a neighbor list for type pairs it is defined for.
Uhm... well, it popped up in my up-to-date LAMMPS while running
valgrind. So there definitely is access to uninitialized data here.
Pair style was set up like this:
pair_style hybrid/overlay table spline 5000 coul/long 10.0
pair_coeff 1 2 table morleon.in TAB_UO
pair_coeff 1 2 coul/long
pair_coeff 1 1 coul/long
pair_coeff 2 2 table morleon.in TAB_OO
pair_coeff 2 2 coul/long
Can you post a simple example script (with data and table files)
so I can replicate the issue?
Thanks,
Steve
Can you post a simple example script (with data and table files)
For #1, I'm not seeing the issue. This would be a bug
if pair table accessed cutsq for type pairs it wasn't defined for.
But I don't think that should be the case. Pair hybrid
should only pass it a neighbor list for type pairs it is defined for.
Today that "bug" caught up with me again, and I found out why. I'm
swapping atom types (using a Monte Carlo fix I wrote) and did not
realize that in hybrid styles where every sub-style has it's own
specific neighborlists, I need to force a neighborlist rebuild
(otherwise I switch atoms to types that should not be in certain
substyle neighborlists).
Sorry about the 'noise' 
Daniel