Dear Lammps Users and Developers
I want to study the shear stress in a system. I used the “fix deform” command and a triclinic boxe (region prism). for calculating the volume and then shear stress in a group I used voronoi/atom. but the error is " ERROR: Compute voronoi/atom not allowed for triclinic box(…/compute_voronoi_atom.cpp:62) "
I study the manual, but there is not any limitation to use of voronoi/atom.
1- is there any suggestion to calculate the volume of a group in triclinic box?
Thanks
Dear Lammps Users and Developers
I want to study the shear stress in a system. I used the "fix deform"
command and a triclinic boxe (region prism). for calculating the volume and
then shear stress in a group I used voronoi/atom. but the error is " ERROR:
Compute voronoi/atom not allowed for triclinic
box(../compute_voronoi_atom.cpp:62) "
I study the manual, but there is not any limitation to use of voronoi/atom.
well, the general rule with software that is as flexible as LAMMPS
usually is that anything that is not explicitly mentioned is not
explicitly supported. the error message of the compute doesn't go
away, because it is not mentioned in the manual. i would assume that
this is a limitation of the underlying voro++ library and that it
would require some programming effort to make it work (if it is
possible at all).
1- is there any suggestion to calculate the volume of a group in triclinic
box?
if you have regular dense system, you could just approximate it
through computing average volume per atom and then summing it up.
axel.
then shear stress in a group I used voronoi/atom. but the error is " ERROR:
Compute voronoi/atom not allowed for triclinic
box(../compute_voronoi_atom.cpp:62) "
Actually, on second thought, this limitation does not really make
sense. I'm already relying on a layer of ghost atoms to provide the
boundary condition for the tesselation. I might as well embed a
triclinic domain into an orthogonal voro++ box. I'll work that into
the next version of the voronoi/atom compute.
Daniel
Ok, here is an experimental version that should support triclinic boxes.
The voronoi domain is setup using sublo_bound,subhi_bound rather than
sublo,subhi.
sublo_bound,subhi_bound are computed analogous to boxlo_bound,boxhi_bound.
Let me know if this works. I'll have to clean it up a bit and debug
the commented out features before I submit this officially.
Cheers,
Daniel
compute_voronoi_atom.cpp (6.78 KB)
compute_voronoi_atom.h (1.62 KB)
Daniel - you may have already figured this out, but in LAMMPS
the per-processor domain in triclinic is simply a tilted region
(e.g. a rhombus) but still with surrounding ghost atoms. All in
Cartesian coords. So it seems like the owned atoms should
still be surrounded by enough ghost atoms to do the Voronoi
tesselation correctly. Maybe just the bounding box changes …
Steve
Daniel - you may have already figured this out, but in LAMMPS
Yeah, that is what I meant two mails ago, and what I implemented one
mail ago 
Dear Daniel
Thanks for your files. I have done my simulation again with
your files in previous email, and there was no error about voronoi/atom and triclinic box.
Thanks again
Mohammad
Dear Daniel
In my simulation I had a problem that I dont think it was due to the new lmp_linux that I have compiled with your files.
whith this new compiled lmp_linux I don’ have the " ERROR: Compute voronoi/atom not allowed for triclinic box (…/compute_voronoi_atom.cpp:62) " but I found the “ERROR: Divide by 0 in variable formula (…/variable.cpp:1426)”.
after I have checked the simulation, I found that in new lmp_linux the “compute voronoi/atom” calculate the volume zero when I use the triclinic system.
Thanks in advance
Mohammad
Can you post an input script please.
Ok, there is obviously a bug in the new voro compute. The ghost atoms
get transferred correctly, but the bounding box that is transmitted to
voro++ is not large enough to contain all the atoms.
I did not realize, that once you go triclinic the content of
comm->cutghost changes to some very low value. I have to investigate
how to recover the real ghost cut-off.
D'uh. Cutoff is in lamda (sic) coordinates for triclinic boxes!
Here is a version that calculates the correct voro++ bounding box size.
I verified it with a triclinic box containing a periodic lattice.
Voronoi volumes are identical for all atoms now and bounding box
surrounds all the ghost atoms.
I'll look at the 'radical' tesselation next.
Daniel
compute_voronoi_atom.cpp (7.61 KB)
Dear Daniel
I tried to compile the LAMMPS with your comute_voronoi_atom.cpp file,
but it give a error when compiling this file.
I think you forgot to send the comute_voronoi_atom.h file.
Thanks
Use the version from the radical voronoi tesselation thread. From
20mins ago. That one is complete and up to date.
Dear Dniel
I have used the version from the radical voronoi tesselation thread to compile the LAMMPS.
I have ran my simulation with this new lmp_linux but, I have the following error when I used a simple triclinic box.
"===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= EXIT CODE: 139
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
test.tar.gz (145 KB)
Before I run this myself, can you check if it runs in serial? Do you
know how to use gdb or valgrind? A better error message would help a
lot.
Daniel
Oh no, this is nasty. The segfault occurs in libvoro++ and ahead of
this valgrind reports uninitialized data unrelated(?) to the voronoi
compute.
reset_timestep 0
==27075== Conditional jump or move depends on uninitialised value(s)
==27075== at 0x726701: LAMMPS_NS::Output::reset_timestep(long)
(output.cpp:527)
==27075== by 0x9BB43B: LAMMPS_NS::Update::reset_timestep(long)
(update.cpp:379)
==27075== by 0x9BB3B0: LAMMPS_NS::Update::reset_timestep(int,
char**) (update.cpp:356)
==27075== by 0x6AAB6D: LAMMPS_NS::Input::reset_timestep() (input.cpp:1380)
==27075== by 0x6A64E8: LAMMPS_NS::Input::execute_command() (input.cpp:563)
==27075== by 0x6A4A2C: LAMMPS_NS::Input::file() (input.cpp:201)
==27075== by 0x6BB4C3: main (main.cpp:30)
==27075==
==27075== Conditional jump or move depends on uninitialised value(s)
==27075== at 0x72673F: LAMMPS_NS::Output::reset_timestep(long)
(output.cpp:528)
==27075== by 0x9BB43B: LAMMPS_NS::Update::reset_timestep(long)
(update.cpp:379)
==27075== by 0x9BB3B0: LAMMPS_NS::Update::reset_timestep(int,
char**) (update.cpp:356)
==27075== by 0x6AAB6D: LAMMPS_NS::Input::reset_timestep() (input.cpp:1380)
==27075== by 0x6A64E8: LAMMPS_NS::Input::execute_command() (input.cpp:563)
==27075== by 0x6A4A2C: LAMMPS_NS::Input::file() (input.cpp:201)
==27075== by 0x6BB4C3: main (main.cpp:30)
==27075==
Ok, there are obviously some other things wrong, but I tracked down
the voronoi problem. Again it is due to my lack of familiarity with
triclinic boxes (it is a learning experience). My own test script for
the voronoi compute starts with an orthogonal box, tesselates it,
deformes to box to make it triclinic and tests it again. This always
worked, BUT just because the subdomain dimension variables
(domain->sublo, domain->subhi) are only initialized for orthogonal
boxes (and stay uninitialized if you start right away with a triclinic
box). Triclinic subdomain dimensions are stored differently and I'll
have to modify the compute again to properly utilize them.
Ok, try these files. This should correct the error with the triclinic
input. The issue between test1.r and test2.r should go away as well.
By the way, for your purposes you just need to define _one_ voronoi
compute. It is enough to make the reduce compute group selective
(otherwise you are wasting time by performing the tesselation three
times!)
compute vol all voronoi/atom
compute cent center reduce sum c_vol[1]
compute down middown reduce sum c_vol[1]
compute up midup reduce sum c_vol[1]
compute_voronoi_atom.cpp (11.5 KB)
compute_voronoi_atom.h (1.75 KB)
Dear Daniel
I tested the new files. It seems the main problem solved, but there I saw the following
during volume calculation at screen.
Thanks
"0 BOXLO 0.008180 BOXHI 16.351820
1 BOXLO 0.014167 BOXHI 28.321353
2 BOXLO 0.044213 BOXHI 89.281387
0 SUBLO 0.000000 SUBHI 0.000000
0 BOXLO 0.008180 BOXHI 16.351820
1 BOXLO 0.014167 BOXHI 28.321353
2 BOXLO 0.044213 BOXHI 89.281387
0 SUBLO 0.000000 SUBHI 0.000000
1 SUBLO 0.000000 SUBHI 0.000000
1 SUBLO 0.000000 SUBHI 0.000000
2 SUBLO 0.000000 SUBHI 0.000000
2 SUBLO 0.000000 SUBHI 0.000000
"
Dear Daniel, Lammps Developers,
I am sorry If I missed anything. But do the latest compute voronoi files in this thread good/error-free for triclinic box simulations ?
It does not feel, everything was resolved after this last mail ?
Best wishes
Prashant