Obtaining diameter of a particle type from the information loaded by a read_data

Dear,

I need help with the following:

From a read_data I need to get the diameter of a particle type and store it in a variable. I search alternatives but I can not do this , how I can do this with lammps ? Perhaps the question is trivial, but I could not find the solution .

please help.

Cheers

Dear,

I need help with the following:
>From a read_data I need to get the diameter of a particle type and store it
in a variable. I search alternatives but I can not do this , how I can do
this with lammps ? Perhaps the question is trivial, but I could not find the
solution .

this statement is rather confusing and thus it is difficult to give advice.

most importantly: diameter is not a per-type property but a per-atom property.
as such, it can be accessed through compute property/atom and from
there on accessed from variables the usual way.

axel.

Hello,

The diameter will not change in my simulation , I would like to calculate this information once and store it in a variable. Something like:

read_data ./data
Variable index diam_A $ ( cal_diam ( group_A ) )

Is there a way to do this ? or can only be done using the property compute / atom ?. Regarding the latter I have the impression that it is inefficient to recalculate each time step an amount that does not change over time, eg diameter.

Christopher

Hello,

The diameter will not change in my simulation , I would like to calculate
this information once and store it in a variable. Something like:

read_data ./data
Variable index diam_A $ ( cal_diam ( group_A ) )

Is there a way to do this ? or can only be done using the property compute /
atom ?. Regarding the latter I have the impression that it is inefficient to
recalculate each time step an amount that does not change over time, eg
diameter.

there is nothing being computed with compute property/atom. it is
merely a gateway to the storage.
looking up and accessing a variable is not free either. in general, i
would not worry much about any O(1) or O(N) operation. what will cost
significant time and will slow you down are all kinds of operations
with higher computational complexity and that require reductions and
synchronization.

axel.

Thank you, I understand :slight_smile: