kspace in plugin create a segmentation fault

Dear Developers,

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.

Best regard
Nico

What is wrong with the existing ewald/dipole style in the KSPACE package?

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.

You probably need to use a debugging tool to help find the cause of the segfault, such as valgrind, AddressSanitizer, or gdb.

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. :wink:

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).

[Update:]

In case somebody gets curious, I’ve pushed my changes to the following branch: GitHub - akohlmey/lammps at kspace_zero

Thanks for the answer and good luck for the debugging :muscle: :muscle:
Best regards