Hello List,
I'm about to write a combined tabular coul/long pair style and just
want to check if anyone wants to talk me out of it.
This functionality can be performed with a hybrid/overlay (which is
what I'm using now). But that
a) seem a bit wasteful, as the realspace coulomb part might as well be
added to the tablulated potential data
b) does not work on the GPU (no hybrid/overlay)
Of course you could manually put the coulomb interaction in the pre
tabulated data. But then the pppmflag or ewaldflag has to be set to
convince LAMMPS to use the data. Also the realspace cutoff
(force->kspace->g_ewald) is not straight forward to determine ahead of
time (it is set by the kspace method).
So I thought it'd be easiest to add this as a new pair style and port
it to the GPU module as well.
Daniel
Ok, reading the source I saw the pppm and ewald options. 
That goes to show to always RTFM...
Something to ensure consistent 'gewald' values between real- and
k-space would still be nice.
Stan might have ideas on how to enforce consistency
between a pair table potential when used with the long-range
solvers. Maybe there needs to be an optional arg in the
pair_coeff command, or a keyword in the table file.
Steve
I revised my (poorly thought out 
plan. I'm working on a
pair_tabulate command right now, which let's you write table files
from within LAMMPS using the currently defined pair style (as long it
is a pair potential).
That way I'll get all the built-in pair styles for free, can do hybrid
potentials, can augment existing tables with coul/long etc.
And I can even write out a table file for styles only available on the
CPU and use it on the GPU within just one input file. This makes the
process transparent and ensures consistency with the kspace part.
Daniel
I revised my (poorly thought out plan. I'm working on a
pair_tabulate command right now, which let's you write table files
is there something wrong with pair_write?
http://lammps.sandia.gov/doc/pair_write.html
from within LAMMPS using the currently defined pair style (as long it
is a pair potential).
That way I'll get all the built-in pair styles for free, can do hybrid
potentials, can augment existing tables with coul/long etc.
And I can even write out a table file for styles only available on the
CPU and use it on the GPU within just one input file. This makes the
process transparent and ensures consistency with the kspace part.
yes, and you can even do this in the same lammps script.
axel.
Christ almighty! Let's just forget about this whole thread reeeeal quick.
Thanks Axel for the pointer. I would certainly have deserved a bit more mocking.
Daniel
Christ almighty! Let's just forget about this whole thread reeeeal quick.
Thanks Axel for the pointer. I would certainly have deserved a bit more mocking.
naw, i already got told off once today for being too much the way i
am. as you can see from the quoted text below, this is not the kind of
thing you want to see twice a day...
yes, and you can even do this in the same lammps script.
That was the idea, but I encountered a bug in LAMMPS that torpedoes this.
I have attached a minimal test case below. What triggers the bug is basically
1. create a pair hybrid/overlay style with "coul/long" and "table"
2. use pair_write to dump tha tables
3. create a pair style table and read in the table (or any table)
4. run
lammps->init() is triggered and jumps to neighbor->init(). There the
existing neighbor list requests are processed and (I guess) a request
from the old table style that is now deleted is touched.
Valgrind output:
==20673== 1 errors in context 2 of 8:
==20673== Invalid read of size 4
==20673== at 0x828A23D: LAMMPS_NS::Neighbor::init() (neighbor.cpp:466)
==20673== by 0x8246EBD: LAMMPS_NS::LAMMPS::init() (lammps.cpp:515)
==20673== by 0x848DF9E: LAMMPS_NS::Run::command(int, char**) (run.cpp:169)
==20673== by 0x823E893: void
LAMMPS_NS::Input::command_creator<LAMMPS_NS::Run>(LAMMPS_NS::LAMMPS*,
int, char**) (input.cpp:618)
==20673== by 0x823A5F4: LAMMPS_NS::Input::execute_command() (input.cpp:601)
==20673== by 0x8238C5F: LAMMPS_NS::Input::file() (input.cpp:215)
==20673== by 0x824D303: main (main.cpp:30)
==20673== Address 0x46f0290 is 0 bytes inside a block of size 552 free'd
==20673== at 0x402AB36: operator delete(void*) (vg_replace_malloc.c:502)
==20673== by 0x83CAC13: LAMMPS_NS::PairTable::~PairTable()
(pair_table.cpp:56)
==20673== by 0x8365592: LAMMPS_NS::PairHybrid::~PairHybrid()
(pair_hybrid.cpp:48)
==20673== by 0x8368FC3:
LAMMPS_NS::PairHybridOverlay::~PairHybridOverlay() (in
/data/daniel/Programs/mylammps/src/lmp_debug)
==20673== by 0x8368FEE:
LAMMPS_NS::PairHybridOverlay::~PairHybridOverlay()
(pair_hybrid_overlay.h:30)
==20673== by 0x821A758: LAMMPS_NS::Force::create_pair(char const*,
char const*) (force.cpp:131)
==20673== by 0x823D4D3: LAMMPS_NS::Input::pair_style() (input.cpp:1377)
==20673== by 0x823A232: LAMMPS_NS::Input::execute_command() (input.cpp:573)
==20673== by 0x8238C5F: LAMMPS_NS::Input::file() (input.cpp:215)
==20673== by 0x824D303: main (main.cpp:30)
LAMMPS_VERSION "12 Aug 2013"
test.in (1.07 KB)
in.bug (884 Bytes)
I’ll take a look at this. Thanks for sending the offending script.
An additional thought. The way it works now, pair table
uses one table for a pair of atom types. To use this with
KSpace, this means the table has to encode Qi*Qj/r (with
other terms). Which means all the atoms of type I and J
need to have the same Qi and Qj. That’s ok for some
models, but not for others. E.g. a system with one atom
type and many charge values. Maybe pair table should
be modified so that if one of the KSpace keywords
is used (ewald, pppm, etc), that the table only encodes
1/r (with other terms), and the per-atom Qi and Qj are added
as multipliers for each pair?
Paul (or others) - is there anything numerically problematic
with that - e.g. in the way the splines are fit?
Steve
I’ll post a patch to fix this. You can just add this line
in Pair::write_file()
// initialize potentials before evaluating pair potential
// insures all pair coeffs are set and force constants
// also initialize neighbor so that neighbor requests are processed
// NOTE: might be safest to just do lmp->init()
force->init();
neighbor->init();
Steve