Hi,
is there an elegant and efficient way to access parameters from the
pair_name.cpp in the related fix_name.cpp. I try to use one of the pair
style parameters (one double value) in the fix neighbor class for some
computation.
Regards
Patrick
I am not quite sure I got your point. Do you want to access a variable defined in pair class from other places, e.g. fix, without breaking access privileges?
If yes, there is a member called “extract” in all pair child classes that you can borrow for this purpose. An example is how kspace (e.g. ewald.cpp) gets “cutoff” from pair.
Sincerely,
Zhenxing
Hi,
in my pair_name.class i store a protected double omega with the value
from force->numeric(arg[7]) of the pair_coeff command.
This stored value i need in the void setup(int vflag) of the
corresponding fix_name_neigh.cpp.
If yes, there is a member called "extract" in all pair child classes
that you can borrow for this purpose. An example is how kspace (e.g.
ewald.cpp) gets "cutoff" from pair.
Ok, i will look at this. Is it also possible to call functions from the
pair in the corresponding fix_name_neigh.cpp.
Regards
Patrick
Hi,
in my pair_name.class i store a protected double omega with the value
from force->numeric(arg[7]) of the pair_coeff command.This stored value i need in the void setup(int vflag) of the
corresponding fix_name_neigh.cpp.
it is *very* difficult to discuss things on such a vague basis. are
you referring to code you wrote yourself? or code that is part of
LAMMPS?
the only code that ships with LAMMPS where there is something similar
is the peridynamics package, but none of those have an "omega" member.
If yes, there is a member called "extract" in all pair child classes
that you can borrow for this purpose. An example is how kspace (e.g.
ewald.cpp) gets "cutoff" from pair.Ok, i will look at this. Is it also possible to call functions from the
pair in the corresponding fix_name_neigh.cpp.
yes and no. i don't have the time to provide a long lecture that
covers all possible cases and discuss where this makes sense, and
where it would be a bad idea. due to its modular structure and
encapsulation through C++ classes, things are a bit different than in
an, say, old fashioned fortran code, where you would just call any
function you like, provided its prerequisites are present.
so, please provide some tangible information about your specific case
and what it is exactly you are trying to do and then we can start
talking about how to solve those issues.
axel
Hi,
it is *very* difficult to discuss things on such a vague basis. are
you referring to code you wrote yourself? or code that is part of
LAMMPS?the only code that ships with LAMMPS where there is something similar
is the peridynamics package, but none of those have an "omega" member.
I extended the peridynamics package with some features in the material
model and therefore i need some new parameters in the pair_coeff
command, e.g paramter1, ..., parameterN. I can use it in my
pair_peri_own.cpp but also want to use it in my fix_peri_neigh_own.cpp.
What i want to do is to provide a function double getParameter1() in
pair_peri_own.cpp and call this function in fix_peri_neigh_own.cpp to
get the value of parameter1.
Regards
Patrick
Hi,
it is *very* difficult to discuss things on such a vague basis. are
you referring to code you wrote yourself? or code that is part of
LAMMPS?the only code that ships with LAMMPS where there is something similar
is the peridynamics package, but none of those have an "omega" member.I extended the peridynamics package with some features in the material
model and therefore i need some new parameters in the pair_coeff
command, e.g paramter1, ..., parameterN. I can use it in my
pair_peri_own.cpp but also want to use it in my fix_peri_neigh_own.cpp.What i want to do is to provide a function double getParameter1() in
pair_peri_own.cpp and call this function in fix_peri_neigh_own.cpp to
get the value of parameter1.
no, you should not do that. you should follow the suggestion of
zhenxing and implement a Pair::extract() method similar to what is
done in, e.g. pair_coul_long.cpp to get access to "cut_coul". This is
a generic interface and much safer to use.
within a fix class you by default only have access to the Pair base
class and with extract you avoid having to do an error prone specific
cast to a specific style class. with extract, you would simply get a
NULL pointer, if the pair style is not compatible and not a crash.
axel.