voronoi surface

LAMMPS LAMMPS Mailing List Mirror
1

Dear lammps users,
I am trying to get the surface area of a solid slab which is in contact with a liquid the problem is that I am getting segmentation faults during the simulation when the compute voronoi is used.
I gave a brief description of my system:
All the system is modeled using the stilliger weber potential there are three types of atoms type 1 are called W(for water based on the mW model) this are the solvent particle, type 2 are in the slab and are hydrophilic particles, type 3 also in the slab and are hydrophobic particles, in other words is a solid surface containing a mixture of hydrophilic and hydrophobic particles with water above it.
When I run this system I get segmentation fault
I don’t know if it is a bug associated with the potential I am using or that I compiled lammps incorrectly, or that I am doing something wrong.
Can someone test it ??
I am attaching all the necessary files to run the test

Thanks
Matias

in.run3 (1.06 KB)

liquidplate.data (359 KB)

mW.sw (3.62 KB)

2

Ugh, that is bad. If the segfault disappears if the compute/voronoi is
disabled it is a strong indicator that I screwed up somewhere. Let me
check.
Daniel

3

Yeah, I can conform that there is indeed a problem and I have located
where the segfault happens. I'll have to dig in a bit deeper and go
back to the voro++ docs, as apparently I'm making assumptions about
the returned data sets that are not valid.

4

Alright, got it!

I'm requesting two lists from voro++, the list of voronoi cell face
areas and the list of corresponding neighbor atoms (each face
corresponds to a voronoi neighbor).
To do the computation Matias is doing I need to inspect the group of
said neighbor atom (in his case only faces facing towards a water
"atom" are counted).

However, it seems that voro++ returns neighbor IDs <0 in certain
cases. Taking those as an index into the atom->mask[] array obviously
broke thinks.

My guess is that faces that are the result of truncation of the voro++
volume get those invalid neighbor IDs assigned. This indicates that
the number density of particles in the simulation cell is rather low,
compared to the ghost atom cutoff. Ideally we have enough atoms in the
ghost atom layer so that no local atom voronoi cell touches the edge
of the voro++ cell (local domain volume + gost atom region).

Anyhow. I'm testing for invalid atom IDs now and discard the face
areas straight up (without attempting a group check).
Patched file is attached (this also contains the 2D fix from earlier this week).

Thanks for the bug report, Matias!
Cheers,
Daniel

compute_voronoi_atom.cpp (17 KB)

5

Hi Daniel
I cannot compiled it with the new cpp do i need a new .h file ??
I am gettig errors like this

…/compute_voronoi_atom.cpp(404): error: identifier “con_mono” is undefined
c_loop_all cl(*con_mono);

Thanks for the help
Matias

6

thanks Daniel - both changes in the new file will be in a patch

later today.

Steve

7

Hm, it compiled for me. You did do a make yes-voronoi first, right? In on travel right now an cannot check this.

8

Matias,
which version of LAMMPS are you using? I suspect it is a rather
outdated one. I had attached only the updated .cpp file (as no
modifications were necessary in the header file). You must have an
outdated header file.
I strongly urge you to update as - among many other fixes - the
voronoi compute has had a few updates.
Daniel

9

ok thanks, will test it with the new version and inform what happens

Thanks again !!!