does the eatom member array for the pair class store the total per atom potential energy? I was comparing it with pe/atom and the values are different so I’m confused what the eatom array is actually storing. I only have a pair force described and no fixes in the region used to compare the two dump outputs.
does the eatom member array for the pair class store the total per atom
potential energy? I was comparing it with pe/atom and the values are
different so I'm confused what the eatom array is actually storing. I only
have a pair force described and no fixes in the region used to compare the
two dump outputs.
the answer is: yes and no.
if you have the newton flag for pair interactions active (it is the
default), then Pair::ev_tally() will tally energy for ghost atoms.
to accumulate this information to their corresponding local atoms,
compute pe/atom first has to do a reverse communication.
axel.
Yea I noticed that in the compute thanks. I tried implementing the same reverse comm as seen in pe/atom for the energy array but for some reason I get an MPI_Wait error. Maybe I’ll just take a page out of compute heat and use an existing pe/atom to avoid complication.
Yea I noticed that in the compute thanks. I tried implementing the same
reverse comm as seen in pe/atom for the energy array but for some reason I
get an MPI_Wait error. Maybe I'll just take a page out of compute heat and
use an existing pe/atom to avoid complication.
i have no idea what you are talking about.
if you are writing a fix that needs access to the pe/atom data, you
can have your fix create the compute internally and then call the
compute during execution and use the data. thermostat computes use
that, for example to obtain the temperature. in general, you want to
avoid copying code, when you can just use the existing functionality.
otherwise you disconnect yourself from bugfixes and enhancements and
have more maintenance work.
axel.
If I create a compute style instance in the execution of another compute does it always require the definition of a compute ID and instancing through the member functions of modify? what would happen (as far as program breaking problems) if I just called the constructor of another compute style and started using its member functions and variables?
If I create a compute style instance in the execution of another compute
does it always require the definition of a compute ID and instancing through
the member functions of modify? what would happen (as far as program
yes.
breaking problems) if I just called the constructor of another compute style
and started using its member functions and variables?
if that would work, i'd recommend to watch out for flying pigs and
check the temperature in hell.
remember, that there is a mechanism in place, that makes certain that
certain prerequisite information is collected so that it can later be
used. in order to have energy per atom (or global energy) available
after the force computation, it needs to be known *before*. that is
only possible, if LAMMPS knows about this.
axel.
does the constructor and init always run before the compute routines such as peratom etc.?
does the constructor and init always run before the compute routines such as
peratom etc.?
i don't know how to answer that in a helpful way.
either your knowledge of C++ is seriously lacking, and there there is
no point for me to even try.
or you are trying something that i cannot understand from having no
context and no knowledge of the boundary conditions.
if you follow examples from other parts of LAMMPS, make an effort to
read and understand the code - and there are several examples that use
a peratom compute in one way or another - then you should know what is
relevant.
[[email protected]... src]$ grep -- '->compute_peratom' *.cpp
compute_chunk_atom.cpp: cchunk->compute_peratom();
compute_heat_flux.cpp: c_ke->compute_peratom();
compute_heat_flux.cpp: c_pe->compute_peratom();
compute_heat_flux.cpp: c_stress->compute_peratom();
compute_reduce.cpp: compute->compute_peratom();
compute_reduce_region.cpp: compute->compute_peratom();
dump_custom.cpp: compute[i]->compute_peratom();
fix_ave_atom.cpp: compute->compute_peratom();
fix_ave_chunk.cpp: compute->compute_peratom();
fix_ave_histo.cpp: compute->compute_peratom();
fix_ave_histo_weight.cpp: compute->compute_peratom();
fix_ave_histo_weight.cpp: compute->compute_peratom();
fix_store_state.cpp: compute->compute_peratom();
library.cpp: compute->compute_peratom();
library.cpp: compute->compute_peratom();
variable.cpp: compute->compute_peratom();
variable.cpp: compute->compute_peratom();
variable.cpp: compute->compute_peratom();
variable.cpp: compute->compute_peratom();
let me also point out the importance of using "modify->addstep_compute()"
axel.
Yea I have calls for the pe/atoms routines and its atomvector already. I’m debugging a segfault, apparently it fails after the constructor is done and no other routines in the calling compute run (including init) so there must be something wrong with the addition of the pe/atom compute in the constructor for the calling compute. I added the following lines in the constructor:
int nn = strlen(id) + 8;
id_pe = new char[nn];
strcpy(id_pe,id);
strcat(id_pe,"_PEatom");
char *newarg = new char[3];
newarg[0] = id_pe;
newarg[1] = group->names[igroup];
newarg[2] = (char *) “pe/atom”;
modify->add_compute(3,newarg);
delete [] newarg;
and the segfault happens after exiting the entire constructor so its not immediately caused by those commands.
Strange, I replaced that part in the constructor to create a new compute with some lines to read in an existing pe\atom in the input script to see if the code would work and it did, the potential energy is correct now :). This problem is bugging me though since I don’t understand why the creation of the compute caused a segfault and I’d rather not program computes that take other computes as args.