I’m working on an ewald/dipole class and to test it I put it in plugin.
I realize that putting a class kspace in plugin create an segmentation fault at the moment of the destructor, at the end, in serial and in mpi.
I use the last version of lammps 29Aug2024. I created a small repo with a plugin and an example copied from lammps: example/SPIN/dipole_spin
I put the issues here but maybe should be in the github repo, I don’t know. Tell me.
Nothing is wrong, just I wanted to have in the same system a electric dipole (atom->mu) and magnetic dipole (atom->sp).
I adapted a bit the ewald_dipole_spin to remove the unit dependencies because I wanted to work in lj unit.
It is at this moment I found this strange behavior because I use the same procedure for the pair or fix style to put in plugin and it works perfectly. Only for the kspace class a segmentation fault appeared.
This appear at the moment of kspace destructor call. Could be because the shared library is already closed when the kspace destructor is called?
Also does not appear when the input script stop for a wrong command. When the code stop passing by the error class.
This is something that you should probably discuss with @julient
No. This looks like there is a corruption in the virtual function tables and these are very difficult to debug. I will look into it later today and post an update. I will have to start with a dummy new kspace style (perhaps it is time that we have a kspace style zero, anyway, since we have a “zero” style for any other of the force computing styles).
Would that be any different from just using the existing kspace_modify compute no?
“The compute keyword allows Kspace computations to be turned off, even though a kspace_style is defined. This is not useful for running a real simulation, but can be useful for debugging purposes or for computing only partial forces that do not include the Kspace contribution. You can also do this by simply not defining a kspace_style, but a Kspace-compatible pair_style requires a kspace style to be defined. This keyword gives you that option.”
Not much, but yes. It would try to set up everything the same way as if it was a real kspace style (e.g. estimate g_ewald) and the compute() function is called, but doesn’t do anything except for calling ev_init().
It could also setup all “flags” to be compatible with whatever setting is required (dipole, ewald, pppm, tip4p, msm, dispersion).
The use case is limited beyond what we already have, it would mostly be useful in importing or converting some restarts etc. Also, it is nice to complete the set. That satisfies the “completist” in me.
Quick update. I can observe the segfault even with a dummy kspace style that does nothing loaded as a plugin (and where there are no problems with the compiled in version).
Sadly, there are currently no hints toward a possible cause. This means that for the moment you either have to ignore the segfault or build your custom style inside the tree and not as a plugin.
I will keep the test code around and look at it occasionally, when I have a new idea where to look (or sometimes even when not).