I was troubleshooting a compute I made that uses a call to force->pair->cutsq and I noticed when I printed the value of cutsq[type1][type2] in a dump file (Its a per atom compute so I just assigned the per atom value as cutsq to see if it was the same for every atom) it’s fine in the first timestep then on the next output step some values will be fine and many others will just be zero. I’m only using the pair style lj/cut so I expect cutsq[type1][type2] would always return the same number, what’s going on there?
I was troubleshooting a compute I made that uses a call to
force->pair->cutsq and I noticed when I printed the value of
cutsq[type1][type2] in a dump file (Its a per atom compute so I just
assigned the per atom value as cutsq to see if it was the same for every
atom) it's fine in the first timestep then on the next output step some
values will be fine and many others will just be zero. I'm only using the
pair style lj/cut so I expect cutsq[type1][type2] would always return the
same number, what's going on there?
difficult to say without knowing more details, but it looks like there
is something wrong in your code.
have you run it with valgrind's memory checker to see, if there are
any illegal memory accesses?
axel.
I’ve tried just setting the per-atom-compute member to a constant equal to the cutoff radius to see if the output problem persists but then it worked just as intended. The only wrench in the works I’ve found is that particular call to the pair class for the cutoff radius’ square. I’ll try valgrind to see whats going on with any other class being called but it doesn’t seem like this is related to a memory problem in the compute; no segfault and the per atom vector is allocated fine as far as I can see in the dump provided I don’t use cutsq.
I've tried just setting the per-atom-compute member to a constant equal to the cutoff radius to see if the output problem persists but then it worked just as intended. The only wrench in the works I've found is that particular call to the pair class for the cutoff radius' square. I'll try valgrind to see whats going on with any other class being called but it doesn't seem like this is related to a memory problem in the compute; no segfault and the per atom vector is allocated fine as far as I can see in the dump provided I don't use cutsq.
you probably won't believe how many times people have claimed, that it
cannot be a problem of their code and that they have "checked
everything" and there *still* was a problem in their code. just not
what they had looked for.
axel.