Thanks for the prompt reply. Detailed comments below...
Thanks? That's very reassuring to hear.
1) Is it possible to forgo all this simply by invoking "neighbor->build()" at the end of the fix's "post_integrate()". (I can worry about optimizing speed later.).
2) If so, then, after modifying the contents of the local atom->type array, would I need to do anything else before doing this?
Interestingly, un/pack_forward_comm() from "fix_bond_create.cpp" does not pack or unpack atom type information (just partner lists, probabilities, and special bond information).
3) (I'm curious, how does it transmit atom type changes to other procs?)
I will have to modify both atoms in the bond, and one of them could be owned by another processor. Unfortunately neither fix_atom_swap.cpp, nor fix_bond_create.cpp can do this.
4) Actually, I was thinking of reporting this as a bug in fix_bond_create.cpp: Users can specify either "iparam" OR "jparam", but not both. (If they specify both, then only one of the atoms will be changed.) This significantly limits what "fix bond/create" can do, and makes it makes it practically impossible to use it for many polymerization problems (for example).
(I also have a selfish motive to complain about this: If someone solved this issue, then I could probably steal that code and put it in the fix I am working on. I might post a separate question about this on the list...)
Either way, I am interested to learn of any other fixes I can study which can modify properties of atoms belonging to other processors.
Thanks for engaging me in a discussion on this topic. I think it is really important (and not just for my own work). LAMMPS already has fantastic capabilities and infrastructure. With some really trivial changes like this, LAMMPS will be able to do exiting, amazing new things.
I'm CCing this to Tim Sirk who was also modifying trying to modify fix_bond_create.cpp. (Hi Tim)