Hi Steve and All;

I’ve written a new compute function that only needs to run once, before any particles are perturbed. My problem is I also need the compute to run *after* the neighbor lists are generated (Neighbor::init() & Pair::init_list()).

If the neighbor lists are generated, its easy enough to access them through the Pair object. However I don’t see any way of changing the order/timing of a compute command so that it will happen after initialization is completed but before the simulation starts to ‘run’ (and particles move). Any ideas on how to do this?

-AdamC

Computes don't invoke themselves. They are invoked by

some operation that needs them, e.g. thermo output, dump

output, evaluating a variable in an input script, etc.

You should probably explain what it is you're trying to do.

It could be that a fix is a better way to do it.

Steve

I’m computing the elastic coefficients of the initial system. Its called when the command “compute elco” is in the input script. I was under the impression that fixes changed something about the system or enforced a setting, where as my program is just measuring a property.

I see that in the description of a fix from the website that computing diagnostics is listed as one of the functions fixes carry out, so what is the difference between a compute and a fix? Any clarification would be appreciated.

I'm computing the elastic coefficients of the initial system. Its called

when the command "compute <ID> <GID> elco" is in the input script.

Your compute elco defines a compute that calculates this. It's not

called until some other command invokes it. When are you wanting

it to be invoked, and by what command? See the howto section

of the manual on output (4.15) for all the various ways this

can be done. Is the calculation a

property of the current state of the system? If so, then it is

appropriate as a compute.

Steve

The ComputeELCO::compute() is definitely called when an input script includes the line ‘compute 1 all elco/alloy’. In fact, it’s run before the pair potential of the atoms is initialized (is this a bug?) this causes problems when the compute attempts to loop through an uninitialized neighbor list (segmentation fault).

Primarily, computing the elastic constants will need to be done after the system is ‘initialized’ but before it is perturbed (as well as at selected time steps but I planned on getting that working later).

From what you’ve said I take it that I can use a fix to call the ComputeELCO::compute() at some time step. To avoid the segfault described above the compute() would then check to make sure the system is initialized before running. Is this the intended design?

-AdamC

Your email is confusing to me. Computes do not have a compute() function.

They have functions like compute_scalar(), but those are not called

when the compute line appears in your input script. The constructor

is all that is called. Section 4.15 of the manual discusses all the

ways that computes can be invoked from other commands. If you

are invoking it by listing the compute in a variable, then you should

read the variable doc page (at the bottom) that talks about what happens

when a variable is used in an input command in between runs. In no

case, should LAMMPS allow the compute to be invoked when it is

not ready to be invoked (e.g. pair style or neighbor lists are not setup).

BTW, how do you compute elastic constants from one snapshot of

a system?

Steve

Sometimes writing emails is great bug fixing tool… that said, please disregard my last email. Although I don’t think everything is as it should be yet, I have a bit of work to do before I can continue this conversation… As usual thanks for your help.

As for the actual computing of the elastic constants I’m just taking the 2nd derivative of the inter-atomic potential (directionally dependent) and summing up the components. Painfully enough, this method is potential dependent and has to be rewritten for each potential. So I’m starting with EAM and ADP (after I get the ADP potential up) and working from there.

-AdamC

As for the actual computing of the elastic constants I'm just taking the 2nd

derivative of the inter-atomic potential (directionally dependent) and

summing up the components. Painfully enough, this method is potential

dependent and has to be rewritten for each potential. So I'm starting with

EAM and ADP (after I get the ADP potential up) and working from there.

There are ways to compute elastic constants dynamically, e.g. by observing

the fluctuations of a system if I recall. These do not require

computing a 2nd derivative, and hence work without any additions to the

LAMMPS potentials. Aidan (athomps at sandia.gov) knows a lot more

about this than I do.

Steve

I’ve looked into it and from what I found the method of infinitesimal perturbation for calculating the elastic constants is inaccurate for large systems due to error accumulation on the volume calculations.

-AdamC