A problem about equal-style variable when using the user-cuda

Hi, all

Recently, when I use the package user-cuda to accelerate my computation,
I found in "fix aveforce" the equal-style variable with nested equal-style
variable can't be estimated correctly. I suspect maybe it is a bug of
user-cuda package ?

Following is an example. On the line 218, I use a variable v_force_particle_top_1
which use v_curr_time, v_dila_x_accumu_1 and v_dila_z_accumu_1 to estimate
its value. The latter three variables use thermo keywords "step" "elaplong"
in their expression.

When using acceleration by user-cuda, the result shows upper part doesn't
compress the lower part correctly. But when I used the acceleration
by gpu package, the upper part compress the lower part obviously.

I guess the variable of fix aveforce on line 218 gets a value "0"
when using user-cuda package.

By the way, I use Lammps version 21Jun12.

Christian can answer this. It could be that the option
to use a variable with fix addforce was added to main
LAMMPS after the USER-CUDA version was derived
from it. Even if this is enabled, it will force the timestepping
running on the GPU to go back to the CPU every
timestep (when fix addforce is invoked), so it may
hurt your performance.

Steve

Hi all

yeah I just looked it up, at the time when the fix_aveforce_cuda was written, fix_aveforce did not yet accept variables as input, but just numbers.
I am going to fix that later today (shouldn't be too hard -- fingers crossed).

Christian

Hi Steve,
Do you mean the estimation of the variables MUST be
carried out on CPU ?

Regards,
Kai Wang
Institute of Metal Research, CAS

Hi Christian,

Thank you for fixing bug.

I want to ask another question: if the USER-CUDA packages will support
fix deform and fix move in the near future ?

PS: Please don't feel stressed. I can also work, although some slower.

Regards,
Kai Wang
Institute of Metal Research, CAS

yes, I think that is the case - Christian can answer for sure.

Steve