Hi all,
I have started to do some development on this project by making it a child class of PPPM. I have been able to modify `modify_params` in kspace.cpp to be able to accept a new parameter as well as actually invoke my new class using `kspace_style tild` (tild is the name of my new class). However, I still have a few questions before I can really move forward.
i don't think that this is a good idea. from your posts, i didn't
really understand what it is that you want to implement, but it seems
that is different from other kspace styles in LAMMPS. only that you
want to use the density->FFT->convolution->FFT->apply potential
paradigm.
PPPM is set up to complement pair styles with coul/long to have a full
treatment of coulomb interactions. there are checks for it, so that it
seems much more reasonable to derive from Kspace directly (PPPMDisp,
which add long-range treatment for the (1/r)^6 term to PPPM does so
instead of deriving from PPPM. but another important question is:
since there can be only one kspace style at a time, so how would your
kspace style coexist with potentials requiring long-range coulomb?
...and if you have a solution for that, would your additional feature
*require* long-range coulomb (and a matching complementary short-range
pair style)?
I have a few questions regarding `compute group/group` and its use of kspace.
Where is the `compute group/group` invoked/executed?
of course in compute_group_group.cpp in the function
ComputeGroupGroup::kspace_contribution() which calls
force->kspace->compute_group_group()
I figured it gets called because of `ComputeStyle(group/group, ComputeGroupGroup)` but can't find where `group/group` is actually evaluated/processedp. Is there an equivalent string comparison for invoking compute functions?
no. LAMMPS uses polymorphism.
How (and where) does CompGroupGroup class invoke the kspace::compute_group_group function?
have you head of a tool called "grep"?
$ grep -n compute_group_group compile/lammps/src/compute_group_group.cpp
22:#include "compute_group_group.h"
336: force->kspace->compute_group_group(groupbit,jgroupbit,0);
346: force->kspace->compute_group_group(groupbit,jgroupbit,1);
Can one kspace_style be used with multiple compute functions, and if so, can you specify an interaction parameter (float) as an argument that would be used during the compute function?
yes and no. there must be only one function called "compute()" and its
arguments cannot be changed, or you would violate the requirements of
polymorphism unless you change *all* compute functions, which is not
likely going to happen. you can - of course - have a regular compute()
function that calls other compute functions depending on some global
setting stored in your class.
Is there a way to force the amount of grid points for the FFT and the grid points for the PPPM are exactly the same? If I force them to be the same, I think it would be easier to convolve the density fields.
i don't understand the question. the grid for density and the field
are "local" grids that stretch across the individual subdomain owned
by each MPI rank. they have to be communicated/redistributed into
"sticks" or "pencils" for the parallel(!) FFTs, since for an FFT data
must be continuous in one direction. hence the parallel 1-d FFT must
be followed (in the simple case) with a transpose, then another FFT
and another transpose and the final forward FFT, to have the data in
reciprocal space for the convolution to determine the derivative. and
then - of course - the process must be reversed.
Lastly, would the modification of the checks for the modify_params rountine count as a trivial change to the core code?
yes. but at this point, i believe there are much more serious
conceptional issues, that need to be addressed. what you are asking
and how you seem to be looking at the code is making me worry a lot
about your approach and your difficulties of reading and understanding
existing code.
axel.