Feature request? Triclinic boxes - space filling polyhedra

Hello everyone! I have a quick question, regarding simulation boxes. I’ve seen in the documentation that a non-orthogonal box could be set by choosing the vector accordingly. However, along the text in the doc, the idea of them being the primitive vectors of a lattice arises, and it is quite suitable to define other space filling polyhedra, like truncated octahedron and so on.

My question is if this is already implemented and maybe “forgiven” on the documentation (I don’t think that’s the case, but if so, it could be stated). If not, is there any chance it’s going to be implemented anytime soon?

Thanks in advance!

Pablo

we have no plans for truncated octahedra …

Steve

Hello everyone! I have a quick question, regarding simulation boxes. I've
seen in the documentation that a non-orthogonal box could be set by choosing
the vector accordingly. However, along the text in the doc, the idea of them
being the primitive vectors of a lattice arises, and it is quite suitable to
define other space filling polyhedra, like truncated octahedron and so on.

My question is if this is already implemented and maybe "forgiven" on the
documentation (I don't think that's the case, but if so, it could be
stated). If not, is there any chance it's going to be implemented anytime
soon?

features typically get added to LAMMPS when one of three conditions is true:
- it is easy to do with little effort
- it is a feature that somebody always wanted to implement, but needed
a good reason to do it
- a person *really* wants it and thus added the feature and contributed the code

i suspect that the first two options don't apply and only you can tell
if the third one is an option for you. :wink:

axel.

p.s.: occasionally, there is also option 4, somebody willing to offer
something in exchange for a custom feature, but that is very rare.

Hi all,

Sorry to bother again, but there is a small bug with the ‘if’ statement in combination with ‘include’. Consider the following script:

if “1==1” then &
“print 0” &
“include ‘incl1.in’” &
“print 2” &
“include ‘incl3.in’” &
“print 4” &
“include ‘incl5.in’”

Here incl1.in contains print 1, incl3.in contains print 3, and incl5.in contains print 5. One would think that the output of the lammps script will be
0
1
2
3
4
5
However, it turns out that the output is
0
2
4
5
3
1
I’m guessing that somehow the include statements are interpreted as if they were nested.

Thanks,
Bart

"One would think that X [will happen]" does not imply that "if the
implementation does not do X then it is a bug."

While avoiding violations of the Principle of Least Surprise is a
useful aspiration, it is a terrible filter for erroneous behavior.

Unless there's documentation that promises you a particular semantic
for parsing this command, you should not assume _any_ ordering.

Jeff

If you look at input.cpp it seems that the include command just puts
the filename onto a LIFO stack to be processed as soon as the if
command is terminated.

This is correct. Said another way, there is no
simple way to allow “include” commands in
the middle of an “if” command. Though the
LAMMPS input script syntax might seem like
it’s a programming language, it’s really nothing
like that.

So the code should throw an error if you try this,
and the doc page should say it’s not allowed.

Steve