pair model DPD, newton pair, and GPU acceleration

I am now compiling and start fairly simple testing of dpd accelerated with GPU. Several GPU specific source files are ready, and I am working on the dpd specific force computation part.

When I tried the cpu and gpu version of dpd, I found that when I ran at first gpu code, I saw the message:
ERROR: Cannot use newton pair with dpd/gpu pair style (pair_dpd_gpu.cpp:132)

With gpu code with newton off, the message disappeared.

When I ran standard cpu code with newton off, it says:
WARNING: Pair dpd needs newton pair on for momentum conservation (pair_dpd.cpp:255)

I know the newton pair is not compatible with GPU acceleration. Then, my question is if pair dpd absolutely needs newton pair, is the GPU acceleration of DPD pair impossible ?

My first impression is it’s not likely since the “dpd needs newton” message is warning, not error.

Please someone have can explain the situation.
regards,
Kazuyuki

I am now compiling and start fairly simple testing of dpd accelerated with
GPU. Several GPU specific source files are ready, and I am working on the
dpd specific force computation part.

When I tried the cpu and gpu version of dpd, I found that when I ran at
first gpu code, I saw the message:
ERROR: Cannot use newton pair with dpd/gpu pair style (pair_dpd_gpu.cpp:132)

With gpu code with newton off, the message disappeared.

When I ran standard cpu code with newton off, it says:
WARNING: Pair dpd needs newton pair on for momentum conservation
(pair_dpd.cpp:255)

I know the newton pair is not compatible with GPU acceleration. Then, my
question is if pair dpd absolutely needs newton pair, is the GPU
acceleration of DPD pair impossible ?

My first impression is it's not likely since the "dpd needs newton" message
is warning, not error.

Please someone have can explain the situation.

hmmm... the explanations are pretty obvious. perhaps you should have a
closer look at the publications about GPU acceleration that explain in
detail the approach and why certain choices are made. same goes for
DPD.

here is the short explanation:

the first error happens because gpu force kernels don't use newton's
3rd law, i.e. compute each pair interaction twice to avoid a race
condition when updating forces.

the warning for the second case happens, because DPD forces contain a
random component. without newton's 3rd law, you don't have the *same*
random component applied for both atoms of each pair, be it on the
same or on different MPI tasks. this will obviously not conserve
momentum.

axel.

The reason the 2nd case is a warning is that for some
models that may not be a big issue. E.g. big systems
where due to averaging momentum will be "nearly"
conserved. So LAMMPS gives you the option to
run that way.

Steve

here is one more item to consider. the HOOMD-blue package does have a GPU accelerated implementation of DPD. there also is a paper related to it. might be worth checking out how they address the GPU specific challenges:

http://codeblue.umich.edu/hoomd-blue/doc/classhoomd__script_1_1pair_1_1dpd.html

Thank you for all your comments. I’m glad to have received 4 really helpful comments from 3 people just in a day.

I will go on with dpd/gpu with ‘newton off’ option for a while. Then, I will focus on better accuracy.

Best regards,
Kazuyuki

2013/3/8 Axel Kohlmeyer <[email protected]>

If you have a pair dpd/gpu to contribute, we can release
it with the distro. Best if it fits into either the GPU or USER-CUDA
package.

Steve

From an older thread, but I think that this capability would be useful to have in LAMMPS. Thanks for sharing.

One small bug fix:

       if (multiproc) fclose(fp);

should be:

       if (multiproc==1 || (multiproc == 2 && multiproc_sendID < 0))
         fclose(fp);

- Mike

Just released this as a 2 April patch.
I reworked the logic a bit, adding nfile and fileper
keywords to the dump_modify command.
The new internal variables are documented in dump.h

See if it does what you expect …

Thanks Christopher,
Steve

I just tried a few small tests locally and the “nfile” and “fileper” keywords are doing what I expect. I will run some capability-scale tests later and let you know if I see anything suspicious.

Thanks for adding this,

chris

Just released this as a 2 April patch.
I reworked the logic a bit, adding nfile and fileper
keywords to the dump_modify command.
The new internal variables are documented in dump.h

See if it does what you expect …

Thanks Christopher,
Steve