Dear Steve,
Thank you for a quick reply.
Some comments are below.
do I understand correctly that
EVERY time re-neighboring and/or movement of atoms from processor to
processor
occurs, appropriate methods of fixes are called:
Fix->(min_)pre_exchange() ?
If you mean during a run (as opposed to between runs),
then yes. And reneigh and migrations of atoms between
procs always happen at the same time.
I mean during a run command or minimize command.
What is 'between runs'?
Is there any other event possible when neighbor lists are changed and
those
changes are not 'seen' by pre_exchange() function?
Not sure what you mean by this. The neighbor lists
are changed after pre_exchange(). So they are not
"seen" in that sense.
Sorry for not being clear, I mean if for that particular
run (or minimization) step reneigboring occurs,
then appropriate functions (pre_exchange() / min_pre_exhange() )
of fix are always called.
New neighbors are available to Fix at fix->pre_force().
At some point during re-neighboring, Neighbor->ago is probably reseted
to zero?
yes
Kind regards,
Denis.
Comments below.
Steve
Dear Steve,
Thank you for a quick reply.
Some comments are below.
do I understand correctly that
EVERY time re-neighboring and/or movement of atoms from processor to
processor
occurs, appropriate methods of fixes are called:
Fix->(min_)pre_exchange() ?
If you mean during a run (as opposed to between runs),
then yes. And reneigh and migrations of atoms between
procs always happen at the same time.
I mean during a run command or minimize command.
What is 'between runs'?
Commands like displace_atoms or change_box will migrate
atoms when you invoke the command. They don't call
fixes when they do so.
Is there any other event possible when neighbor lists are changed and
those
changes are not 'seen' by pre_exchange() function?
Not sure what you mean by this. The neighbor lists
are changed after pre_exchange(). So they are not
"seen" in that sense.
Sorry for not being clear, I mean if for that particular
run (or minimization) step reneigboring occurs,
then appropriate functions (pre_exchange() / min_pre_exhange() )
of fix are always called.
New neighbors are available to Fix at fix->pre_force().
yes
Some more questions below...
Kind regards,
Denis.
Comments below.
Steve
If you mean during a run (as opposed to between runs),
then yes. And reneigh and migrations of atoms between
procs always happen at the same time.
I mean during a run command or minimize command.
What is 'between runs'?
Commands like displace_atoms or change_box will migrate
atoms when you invoke the command. They don't call
fixes when they do so.
So, how can I check if these commands indeed migrated some atoms?
say, I do 'displace atoms',
then minimize and then 'run'.
Imaging that 'displace atoms' migrated atoms,
minimization worked with no migration (no min_pre_exchange() called),
and now in 'run' can I check if atoms were migrated before?
Does minimize increment Neighbor->ago each minimization step or
Neighbor->ago is incremented only in integration of Newton's laws?
Is it reseted in commands like displace_atoms ?
Why don't you explain what you want to do.
Neighbor->ago is correct at all times so far
as I recall. I don't see why you care if atoms
migrated or not. LAMMPS doesn't keep track
of whether any atoms actually moved to new
procs.
Steve
Dear Steve,
I'm just exploring the ATC code.
The thing is, if atoms move or neighbors change with respect to the previous run,
some stuff needs to be recalculated.
with regards to Neighbor->ago,
so if re-neighboring is done on
displace_atoms / delete_atoms, then it's reseted to 0, right?
The only question is, if there is a minimization running,
does it increment Neighbor->ago each minimization iteration?
Or Neighbor->ago is incremented only at the end of minimization, similar to
displace_atoms/ delete_atoms ?
Kind regards,
Denis.
yes, I beleive that neighbor->ago is reset in
all those cases.
Steve