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.