Thank you Axel, I had misinterpreted your advice earlier. I have now instead declared eTest as a public vector in pair_eam_test.h
it does not have to be public. more importantly, you have to allocate/resize/free it as necessary using memory->create() or memory->destroy() (see the array PairEam::rho for example)
Using the extract function of atom.cpp as an example, I added this to the extract function in pair_eam_test.cpp:
if(strcmp(name,“eTest”)==0) return (void *) eTest;
that is not sufficient, you also need to set dim as necessary to indicate the dimensionality. the existing example is for a 2d array, but you have only 1d data.
In the fix, I believe I should then access the eTest vector as:
no. you have to check on your pair style and call force->pair->extract() with the corresponding settings to obtain the pointer. check whether it is not NULL and whether the dimensionality matches. force->pair->extract() is used in several places.
However, I am stuck on what goes in the (?) section.
considering the kinds of dirty hacks that you are doing, i am surprised of your limited ability to read and search through source code. if you keep doing what you are doing, you have to acquire and practice this kind of skill or you will be stuck all the time and there may not be people around that are willing and able to help you.
with grep you should be able quickly identify cases where the Pair::extract() method is used and learn from it.
Also, if a post-force fix such as fix setforce uses atom style arrays like atom->x, atom->f, atom->type, etc, why would there be complications with a custom fix/property vector? I had thought that the communications of custom vectors are done in the same way the existing atom style vectors are.
they are. i just said that it was rather complex and convoluted to have a (hacked) pair style that is dependent on you defining a specific property with fix property/atom in your input and then consume it with yet another fix. at the very least. this is just an invitation to get crashes. perhaps i am thinking too much in terms of what is a meaningful and maintainable modification in LAMMPS and less in terms of how to just hack your way to some result no matter how dirty and hackish.
you didn’t say that you want to access this data from fix setforce. in that case, you fix property/atom would have the advantage to already being exposed to the LAMMPS script interface and (atom style) variable expressions. but then again, i don’t understand why the compute pe/tally version wasn’t sufficient, that would be the cleanest approach in my opinion and also produce a per-atom property that is accessible in atom style variables. using Pair::extract() on the other hand would be most useful when trying to access it directly from a inside a fix, which is what you had specified you would be doing.
besides there is no communication necessary here. all data is only stored and accessed only for local atoms on the respective MPI subdomain.
at any rate, this is starting to get too hackish and too dirty for me. you are moving too far into uncharted territory with an approach that has no chance to ever been included into the LAMMPS distribution and thus useful for others but you.
feel free to continue on your path, but understand that i rather spend my time on modifications and improvements to LAMMPS that are of use for more than just one person. we are a very small team of people and have to budget our efforts carefully. up to this point, i had the hope that there would be something in here that could be later cleaned up and refactored to be usable in a more general way. but that is now gone and consequently so is my desire to spend time on it.