Repository of miscellaneous geometry modelling programs in Python

[Adrian Rossiter]

Hi All

I have set up a Git repository to collect together some of the
Python programs I have previously posted to forums

https://github.com/antiprism/antiprism_python

Here is the README

https://github.com/antiprism/antiprism_python/blob/master/README.md

Adrian.
--
Adrian Rossiter
adr...@antiprism.com
http://antiprism.com/adrian

[Roger Kaufman]

Hi Adrian,

I looked at the list but I didn't download. The list has much of
everything I have collected over time. There was one script called
'willams' that I have that wasn't in the list.

There was one called 'cell_dod' which made an array of convex and
non-convex dodecahedrons. I should look to see if a 2x2 array could be
made which be more interesting. The more I look at it, I think I
probably wrote this one.

cell_dod.py 0.5 1 | off_util -M a | antiview -v 0.1
cell_dod.py 0.5 2 | off_util -M a | antiview -v 0.1

There was a series of them (which I also may have written) to inscribe
dipyramids into other polyhedra

cube_dip_face.py 6/2 | antiview -v 0.01 -e 0.005

trap_and_stel calculated the antiprism would make a congruent reciprocal
anti-dipyramid. There may have proceeded work done in the polygon program

trap_and_stel 5

Here was a script that was supposed to make anti-dipyramids like these
http://www.antiprism.com/misc/gyro_pyr_pr.wrl
It doesn't appear to be working. There was a parameter -T in the polygon
command which no longer exists.

pyr2trap 5

There were a couple for intersection prisms (careful, these make a
series of images)

I added my 'inscribe.py' python script which sizes one polyhedron to fit
into another polyhedron. I am not sure how generalized it can be made.

I zipped these up into http://www.interocitors.com/tmp/python_scripts.zip

Roger

[Roger Kaufman]

I am thinking that many of these scripts might have been mine. Many also
require Antiprism to be installed in order to work. If they are not
appropriate for the python package that is ok. If they remind you of any
other scripts we have had then that is good.

I was looking at making a cellular dodecahedron array which is 2x2. I
have one here. This array is busy looking and is a bit hard to follow
but I think it is better than the 3x3 array.

http://www.interocitors.com/tmp/cell_dod.2x2.gif

http://www.interocitors.com/tmp/cell_dod.3x3.gif

One thing I noticed is that it is difficult in general to create a NxN
fcc array and an array where the opposite positions are occupied. To
create a 2x2 (and NxN where N is even) array and its opposite I did
these commands.

bravais fcc -g 1 -G 8 | antiview
bravais fcc -g 1 -G 8 | off_trans -I | antiview

To create odd arrays these will work

lat_grid fcc 2 | antiview
bravais fcc -g 2,1,1 | off_trans -T 1,0,0 | lat_util -k cube -r 2 | antiview

The last command only creates a 3x3 array correctly, and is a limitation
that is in the script.

There needs to be better way to create these arrays where N really
creates and NxN array of fcc points or its opposite. I had developed the
-G 8 concept in bravais in attempt to help with this but it is not the
solution. It works for even N even those the arrays are actually 2N. But
it doesn't work for the odd case.

As an aside, the lat_util command no longer needs the -x and -X commands
as off_util can now keep or delete based on color. I should take those out.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 25 Mar 2016, Roger Kaufman wrote:
> I am thinking that many of these scripts might have been mine. Many also
> require Antiprism to be installed in order to work. If they are not
> appropriate for the python package that is ok. If they remind you of any
> other scripts we have had then that is good.

The scripts I put in the repository were all stand-alone scripts. I
tidied them up a bit and they all use the native Python command line
interface. They could do with a bit more documentation and some
examples.

I haven't completely decided what to do about the scripts that call
Antiprism programs, but my current thought is to split the Python
repository into three directories:

* stand-alone programs

* dependent programs that someone might reasonably run as-is

* example scripts (just a selection) that are either illustrative
or that someone might reasonably adapt to other uses.

I will look through the scripts you posted to see how they might
be included.

The main goal of the repository is just to draw attention to
existing code that might still have some use, by making it available
in one place, with documentation, and linking to it. I may also bundle
the repository with Antiprism.

> One thing I noticed is that it is difficult in general to create a NxN fcc
> array and an array where the opposite positions are occupied. To create a 2x2
> (and NxN where N is even) array and its opposite I did these commands.
>
> bravais fcc -g 1 -G 8 | antiview
> bravais fcc -g 1 -G 8 | off_trans -I | antiview
>
> To create odd arrays these will work
>
> lat_grid fcc 2 | antiview
> bravais fcc -g 2,1,1 | off_trans -T 1,0,0 | lat_util -k cube -r 2 | antiview

Another possibility (similar to your followup post) is to split an
sc lattice, e.g. for 3, 4, 5, 6

bravais sc -g 2 -s rt2 | off_util -K E0 -x V -x e| antiview
bravais sc -g 2 -s rt2 | off_util -K E1 -x V -x e| antiview

bravais sc -g 3 -G i -s rt2 | off_util -K E0 -x V -x e| antiview
bravais sc -g 3 -G i -s rt2 | off_util -K E1 -x V -x e| antiview

bravais sc -g 4 -s rt2 | off_util -K E0 -x V -x e| antiview
bravais sc -g 4 -s rt2 | off_util -K E1 -x V -x e| antiview

bravais sc -g 5 -G i -s rt2 | off_util -K E0 -x V -x e| antiview
bravais sc -g 5 -G i -s rt2 | off_util -K E1 -x V -x e| antiview

[Roger Kaufman]

Hi Adrian,

On 3/28/2016 12:10 PM, Adrian Rossiter wrote:
> The main goal of the repository is just to draw attention to
> existing code that might still have some use, by making it available
> in one place, with documentation, and linking to it. I may also bundle
> the repository with Antiprism.

And it makes a nice backup.

> Another possibility (similar to your followup post) is to split an
> sc lattice, e.g. for 3, 4, 5, 6
>
> bravais sc -g 2 -s rt2 | off_util -K E0 -x V -x e| antiview
> bravais sc -g 2 -s rt2 | off_util -K E1 -x V -x e| antiview
>
> bravais sc -g 3 -G i -s rt2 | off_util -K E0 -x V -x e| antiview
> bravais sc -g 3 -G i -s rt2 | off_util -K E1 -x V -x e| antiview
>

Thats a better solution because it only requires the additional -G i for
odd N. It only requires testing for odd/even in python

My question is why it is so difficult to make the odd lattice with bravais.

this is fcc

lat_grid fcc 2 | antiview
bravais sc -g 2 -s rt2 | off_color -e K | off_util -K E1 | antiview

so what is this? It seems like I should know this! But there is no
simple lattice to make it. It has a central point at the origin. It is
not bcc
bravais sc -g 2 -s rt2 | off_color -e K | off_util -K E0 | antiview

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 28 Mar 2016, Roger Kaufman wrote:
> My question is why it is so difficult to make the odd lattice with bravais.

Interesting centres are probably points where a subgroup of the
lattice symmetry group fixes just that point. The primitive
cells of any lattice are parallelohedra the centroid of the
various dimensional elements all have central symmetry within
the lattice, and a vertex (x1), edge centre (x 3),
face centre (x3) and body centre (x1) are all interesting
centres.

In which case, what particular lattices have other centres?
The point symmetry needs to map nearest lattice points onto
nearest lattice points, the only new possibilities I can see,
offhand, are at the centre of an equilateral triangle of points,
and at the centre of a tetrahedron. That suggests that besides
the FCC tetrahedron centre, another other interesting points is
the centre of its triangle face. Also, for a hexagonal unit cell,
the centre of a triangle on its base.

> so what is this? It seems like I should know this! But there is no simple
> lattice to make it. It has a central point at the origin. It is not bcc
> bravais sc -g 2 -s rt2 | off_color -e K | off_util -K E0 | antiview

It is FCC.

[Adrian Rossiter]

Hi Roger

On Tue, 29 Mar 2016, Adrian Rossiter wrote:
> and at the centre of a tetrahedron. That suggests that besides
> the FCC tetrahedron centre, another other interesting points is
> the centre of its triangle face. Also, for a hexagonal unit cell,
> the centre of a triangle on its base.

Thinking some more, the triangle centre in FCC doesn't work. That
just leaves the triangle centre in the hexagonal cell face, and
the extra face and edge centres generally, as possibilities for
-G.

[Roger Kaufman]

Hi Adrian,

On 3/29/2016 1:37 AM, Adrian Rossiter wrote:
>
>> so what is this? It seems like I should know this! But there is no
>> simple lattice to make it. It has a central point at the origin. It
>> is not bcc
>> bravais sc -g 2 -s rt2 | off_color -e K | off_util -K E0 | antiview
>
> It is FCC.

I realized this fairly soon! What is throwing me off is that bravais
deals with lattice cells, not layers of lattice points.

However, there is something peculiar about how -g and -G i act together.
-g 2 would mean an array of 2x2x2 cells. And -g 2 seems to be the
default. (I haven't looked at the code yet)

bravais fcc -g 2 | antiview
bravais fcc | antiview

But when -G i is added, it generates an array that is 3x3x3. Indeed! -g
2 is ignored when -G i is used

bravais fcc -g 2 -G i | antiview
bravais fcc -G i | antiview

This was worked out for Steve Waterman at the time to make the grid big
enough for generating polyhedra just based off the radius. But this
required -g a to be set.

bravais fcc -g a -G i -c s -r rt20 | antiview
bravais fcc -G i -c s -r rt20 | antiview

If -G is used and -g is not set then apparently -g defaults to 3. I
think I know why I did this. It is probably because if only a 2x2x2
array is generated, it will be re-centered by antiview (without a
centering parameter). And then it will have centering as in -G p.

In any case, there should be warnings as to what -g is doing because
there are some values it can't be set to. Another possibility could be
to strip off the outer layer vertices.

bravais fcc -g 2 -G i -Z red | antiview -v 0.1

Roger

[Roger Kaufman]

Hi Adrian,

On 3/29/2016 9:42 AM, Roger Kaufman wrote:
> In any case, there should be warnings as to what -g is doing because
> there are some values it can't be set to. Another possibility could be
> to strip off the outer layer vertices.
>
> bravais fcc -g 2 -G i -Z red | antiview -v 0.1

With the -G option, it was more or less added to center the grid for
Waterman polyhedra. He was focusing of FCC. Once Steve was satisfied
with what it was doing it went un-maintained.

In the help it says the default container is cubic. This is true to the
extent that the Cartesian coordinate system is cubic! i.e. it doesn't
really do anything. It could instead enforce -g in this case.

It can be done now with a cube in an off file. So it could be done
internally.

off_trans -S 4,4,4 cube > cube.off
bravais fcc -g 2 -G i -k cube.off -r k -Z red | antiview -v 0.05

I see why it was done the way it was. The help says....

.... Combinations for grid center:
even,even,even - on cell corner odd,odd,odd - in cell
body
even,odd,even - on cell mid-edge odd,even,odd - on
face center

So in order to do the various -G centers it just uses this pattern. So
if it has to add to one of the scales of -g to do the scaling, that is
what it does. But it doesn't trim them back in the final product!
Because Steve was always doing spherical scoops they were being trimmed
in that manor.

So -g is lying too, it says calculated, but its default is really 2
unless -G is used then it is altered.

This is fairly easy to fix then.

Do you have a planned release date for the next build?

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 29 Mar 2016, Roger Kaufman wrote:
> Do you have a planned release date for the next build?

A snapshot is overdue. I will make one next week.

[Roger Kaufman]

Hi Adrian,

On 3/31/2016 2:52 AM, Adrian Rossiter wrote:
> Hi Roger
>
> On Tue, 29 Mar 2016, Roger Kaufman wrote:
>> Do you have a planned release date for the next build?
>
> A snapshot is overdue. I will make one next week.

I can resume work next week. A couple weeks would be good.

On bravais I want to truncate the grid per the elements in -g. While
doing this I want to change -g to take doubles so that the grid can be
truncated to fractional values. I don't know what demons this will release.

If it looks like it will take too long I will let you know.

Roger

[Roger Kaufman]

Hi Adrian,

On 3/31/2016 8:25 AM, Roger Kaufman wrote:
> On bravais I want to truncate the grid per the elements in -g. While
> doing this I want to change -g to take doubles so that the grid can be
> truncated to fractional values. I don't know what demons this will
> release.

I think this will take a bit of time so I don't want this to hold up the
next release. I will probably find bugs too and so it will need a while
to work on. And some of the parameters are confusing and should be
worked on.

I wrote a python script to compare what it could do on FCC as opposed to
what it does now. The grid dimensions would remain integer, but the grid
would be trimmed to match the -g x,y,z

If you run the script it can be seen that it made sense to add to the
grid, per the unit cells as it does now.

'shell i 3 3 3' is the only time the grid actual can be true to x,y,z
input. green points = current output. yellow points = trimmed output.

'shell p 3 3 3' shows that it can be a 3x3x3 array of points but it
doesn't line up with cells emanating from the center. Same for f and e
centering.

I am leaning toward the mod to be: show the actual array of cells
requested (as in the yellow points), then optionally add to the grid to
make complete cells as it does now (the green points), or optionally
trim points outside the cells.


'shell 8 3 3 3' The '8' centering I am not sure what to do with it.
There is a symmetry here but it isn't a valid centering per the cell
structure. And it can be achieved by shifting the grid. It produced
different Waterman polyhedra. Perhaps instead it should be thought of as
an interesting offset point.

bravais fcc -c s -g a -G i -r 3 -C i -F S -T 128 | antiview
bravais fcc -c s -g a -G 8 -r 3 -C i -F S -T 128 | antiview

So there are some things to think about with the program.

Roger



#!/usr/bin/python

# #!/bin/bash
# rm cube.off
# off_trans -S $1,$2,$3 cube > cube.off
# ./bravais fcc -g $1,$2,$3 -G i -k cube.off -r k -Z red -u | antiview
-v 0.05

import os
import sys

gtype = sys.argv[1]
g1 = float(sys.argv[2])
g2 = float(sys.argv[3])
g3 = float(sys.argv[4])

print g1,g2,g3

os.system("off_trans -S %s,%s,%s cube > cube.off" % (g1*2,g2*2,g2*2))
os.system("./bravais fcc -g %s,%s,%s -G %s -k cube.off -r k -Z red -u -V
yellow | antiview -v 0.1 &" % (int(g1),int(g2),int(g2),gtype))
os.system("./bravais fcc -g %s,%s,%s -G %s -Z red -u -V green | antiview
-v 0.1" % (int(g1),int(g2),int(g2),gtype))