🚀 go-pugleaf

Have you checked Mercury?
http://www.ccdc.cam.ac.uk/prods/mercury/index.html
It can read .cif and save as .mol, but I'm not sure that's what you
are looking for.

The following link gives high-pressure Te structure.
http://cst-www.nrl.navy.mil/lattice/struk/Te.html

BTW, there has been recently a new solution proposed for the
crystallographic phase problem.
http://xxx.lanl.gov/abs/cond-mat/0209690

Saco wrote:
> 
> Have you checked Mercury?
> http://www.ccdc.cam.ac.uk/prods/mercury/index.html
> It can read .cif and save as .mol, but I'm not sure that's what you
> are looking for.

My needs as stated are very specific.  Given the crystal strucure of
elemental tellurium, ICSD 65692.CIF (fractional coordinates), generate
an (unordered) *.XYZ list of Cartesian coordinates for a given radius
(or number of unit cells in each direction x,y,z).  Almost any crystal
software package will do this, ORTEP to ATOMS.  

The *problem* is that I need a 120-150 A radius, or about 250,000
atoms (about 9 MB of output).  Loathsome fat, stupid, and incapable
Windows freezes solid at those memory requirements if any attempt is
made to order the list or output in a window instead of a scratch
file.  I have exhausted obscenities in seven languages damning
BillGates to Hell

Mercury is a very capable, very sophisticated package.  I'll give it a
run.  I suspect I need a very primitive, very incapable program that
just builds a lattice to a given radius.  I'm looking at crystallff. 
It could be the perfect tool!  Its extensive documentation very neatly
omits giving even a single example of an input sequence.  I'm down to
one fatal error.
 
> The following link gives high-pressure Te structure.
> http://cst-www.nrl.navy.mil/lattice/struk/Te.html

"8^>)  I specifically need the helical P3(1)21/P3(2)21 hexagonal
structure.
 
> BTW, there has been recently a new solution proposed for the
> crystallographic phase problem.
> http://xxx.lanl.gov/abs/cond-mat/0209690

Isn't that something?  It will be interesting to see if it is adopted
as a general method.

Thanks for the help.

-- 
Uncle Al
http://www.mazepath.com/uncleal/
 (Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?"  The Net!

Uncle Al <UncleAl0@hate.spam.net> wrote in message news:<3DAD8AE7.59098CA4@hate.spam.net>...

> The *problem* is that I need a 120-150 A radius, or about 250,000
> atoms (about 9 MB of output).  Loathsome fat, stupid, and incapable
> Windows freezes solid at those memory requirements if any attempt is
> made to order the list or output in a window instead of a scratch
> file.  

Eventually there comes a time when it's faster to write something
yourself, particularly when most of the programs you've mentioned are
going to aim to draw a picture of your 250,000 atoms for you. They
might even search through them calculating bond distances and angles
so as to be able to draw chemically reasonable little sticks between
the quarter of a million little balls. The problem is not the
operating system, but the programs you are running on it.

Just loop over a, b and c lattice translations throwing away anything
outside the radius you want. In fortran (which I hope you can read)
that leads to something like the following:
      program hexlat
      a=4.0    ! a and c parameters 
      c=5.0    ! ...clearly you'll want to fill in the right numbers
      r=150.0  ! radius of sphere
      PI=4.0*atan(1.0)
      iamin=int(r/a)+1      ! number of cells in a,c directions
      icmin=int(r/c)+1      ! ...plus 1 as fortran rounds down
      do 1 ia=-iamin,iamin
        do 1 ib=-iamin,iamin
          do 1 ic=-icmin,icmin
            x=a*ia+a*ib*cos(2.*PI/3.)  ! Check these equations...
            y=     a*ib*sin(2.*PI/3.)  ! You might want different 
            z=c*ic                     ! coords to these (a||x, c||z)
1           if(sqrt(x*x+y*y+z*z).le.r)write(*,*)x,y,z
      end

At 15 lines of code (typed right in and untested :) it's hardly worth
looking for something to download. If this is enough to get you
started, then you just need to make a list of atoms in the origin cell
and add those co-ordinates to the x,y and z in the code above,
checking that the axis conventions are right. I've intentionally left
that out as an exercise - far too much crystallography is already done
by black boxes.

> I have exhausted obscenities in seven languages damning BillGates to Hell

Empower yourself and write your own program. I can't really see
there's a general audience for lists of 250,000 atom co-ordinates that
can be summarised by a cell, space group and list of atoms in the
asymmetric unit. The real problem for a general program is that
reading a cif file and being ready for all of the possible 230 space
groups introduces a rather large overhead.

Hope this helps,

Jon

Jon wrote:
> 
> Uncle Al <UncleAl0@hate.spam.net> wrote in message news:<3DAD8AE7.59098CA4@hate.spam.net>...
> 
> > The *problem* is that I need a 120-150 A radius, or about 250,000
> > atoms (about 9 MB of output).  Loathsome fat, stupid, and incapable
> > Windows freezes solid at those memory requirements if any attempt is
> > made to order the list or output in a window instead of a scratch
> > file.
> 
> Eventually there comes a time when it's faster to write something
> yourself, particularly when most of the programs you've mentioned are
> going to aim to draw a picture of your 250,000 atoms for you. They
> might even search through them calculating bond distances and angles
> so as to be able to draw chemically reasonable little sticks between
> the quarter of a million little balls. The problem is not the
> operating system, but the programs you are running on it.

It's both.  Metaphorically speaking, you can't buy a plain wrench
anymore.  If it doesn't come with a battery pack and an LCD screen it
isn't salable.
 
> Just loop over a, b and c lattice translations throwing away anything
> outside the radius you want. In fortran (which I hope you can read)
> that leads to something like the following:
>       program hexlat
>       a=4.0    ! a and c parameters
>       c=5.0    ! ...clearly you'll want to fill in the right numbers
>       r=150.0  ! radius of sphere
>       PI=4.0*atan(1.0)

Aw, c'mon, explictly enter it as double precision floating point.

>       iamin=int(r/a)+1      ! number of cells in a,c directions
>       icmin=int(r/c)+1      ! ...plus 1 as fortran rounds down
>       do 1 ia=-iamin,iamin
>         do 1 ib=-iamin,iamin
>           do 1 ic=-icmin,icmin
>             x=a*ia+a*ib*cos(2.*PI/3.)  ! Check these equations...
>             y=     a*ib*sin(2.*PI/3.)  ! You might want different
>             z=c*ic                     ! coords to these (a||x, c||z)
> 1           if(sqrt(x*x+y*y+z*z).le.r)write(*,*)x,y,z
>       end
> 
> At 15 lines of code (typed right in and untested :) it's hardly worth
> looking for something to download. If this is enough to get you
> started, then you just need to make a list of atoms in the origin cell
> and add those co-ordinates to the x,y and z in the code above,
> checking that the axis conventions are right. I've intentionally left
> that out as an exercise - far too much crystallography is already done
> by black boxes.

It is certainly worth a hard look.  Thanks for the boot to the head! 
My concern is at the seams when stuff starts stacking.  I prefer
existing qualified software, without the accessory bells and whistles,
that is assuredly free of bugs.  We have the 464K Fortran source code
for Bruce Ravel's ATOMS.  That could be dissected, pruned, and a
minimal GUI installed.

A 120,000-atom lattice is of no use to anybody except maybe me.  As a
synthetic organic chemist I have no feel for crystallography
software.  If somebody knows of exiting canned code, great.  If we
have to cut it out of a larger package, that's OK too.  If we write it
from scratch, that is a last resort.  

"Check these equations..."  Hell, yes!  Remember what happend to a
$billion NASA Mars probe because some jackass mixed English and metric
units.  "Aside from that, Mrs. Lincoln, how did you like the play?"
 
> > I have exhausted obscenities in seven languages damning BillGates to Hell
> 
> Empower yourself and write your own program. I can't really see
> there's a general audience for lists of 250,000 atom co-ordinates that
> can be summarised by a cell, space group and list of atoms in the
> asymmetric unit. The real problem for a general program is that
> reading a cif file and being ready for all of the possible 230 space
> groups introduces a rather large overhead.
> 
> Hope this helps,

"8^>) 

If we can't go the social advocacy route, we'll roll up our sleeves
and earn it.  The number of small unit cell heavy atom chiral lattices
in which all nearest neighbor paths are homochiral appears to be
limited to tellurium (pity about missassignment of the BiTeI
structure).  The program doesn't have to do much, just a lot of it
exactly - and dump to disk where Window's can't choke on it.

When the going gets tough, the tough look for algorithms.

-- 
Uncle Al
http://www.mazepath.com/uncleal/
 (Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?"  The Net!

uncle Al wants it to work in windows, he may not have a fortran compiler.
It is more easy with python.  You can download it from www.python.org.
Read the tutorial and here you go, it allows you to do other cool things too.
In the python shell you can type (translate from fortran below)

          from math import *
          ff = open("te.xyz","w")
          a = 4. ; c=5. ; r=150.
          iamin = int(r/a) + 1 ; icmin = int(r/c) + 1
          for i in range(iamin):
              for j in range(iamin):
                  for k in range(icmin):
                      x = a*i + a*j*cos(2.*pi/3.)
                      y =       b*j*sin(2.*pi/3.)
                      z = c*k
                      if x**2 + y**2 + z**2 < r**2 :
                            ff.write("%8s%12.6f%12.6f%12.6f\n" % ("Te",x,y,z))
          ff.close()

(ctrl-Z to exist shell)
It takes about 30 seconds on my pentium 4 machine to generate
the required file (about 10 Mbytes).
best 
paul

> > Just loop over a, b and c lattice translations throwing away anything
> > outside the radius you want. In fortran (which I hope you can read)
> > that leads to something like the following:
> >       program hexlat
> >       a=4.0    ! a and c parameters
> >       c=5.0    ! ...clearly you'll want to fill in the right numbers
> >       r=150.0  ! radius of sphere
> >       PI=4.0*atan(1.0)
> 
> Aw, c'mon, explictly enter it as double precision floating point.
> 
> >       iamin=int(r/a)+1      ! number of cells in a,c directions
> >       icmin=int(r/c)+1      ! ...plus 1 as fortran rounds down
> >       do 1 ia=-iamin,iamin
> >         do 1 ib=-iamin,iamin
> >           do 1 ic=-icmin,icmin
> >             x=a*ia+a*ib*cos(2.*PI/3.)  ! Check these equations...
> >             y=     a*ib*sin(2.*PI/3.)  ! You might want different
> >             z=c*ic                     ! coords to these (a||x, c||z)
> > 1           if(sqrt(x*x+y*y+z*z).le.r)write(*,*)x,y,z
> >       end

Paul Nuber wrote:
> 
> uncle Al wants it to work in windows, he may not have a fortran compiler.
> It is more easy with python.  You can download it from www.python.org.
> Read the tutorial and here you go, it allows you to do other cool things too.
> In the python shell you can type (translate from fortran below)
> 
>           from math import *
>           ff = open("te.xyz","w")
>           a = 4. ; c=5. ; r=150.
>           iamin = int(r/a) + 1 ; icmin = int(r/c) + 1
>           for i in range(iamin):
>               for j in range(iamin):
>                   for k in range(icmin):
>                       x = a*i + a*j*cos(2.*pi/3.)
>                       y =       b*j*sin(2.*pi/3.)
>                       z = c*k
>                       if x**2 + y**2 + z**2 < r**2 :
>                             ff.write("%8s%12.6f%12.6f%12.6f\n" % ("Te",x,y,z))
>           ff.close()
> 
> (ctrl-Z to exist shell)
> It takes about 30 seconds on my pentium 4 machine to generate
> the required file (about 10 Mbytes).
> best
> paul

I was looking for an elegant general solution given *.CIF data in
existing code.  Silly me.  I am entirely happy with a brute force
solution for the specific case.  The "obvious" solution for a regular
lattice is to take an existing large Cartesian rendering, look at the
constant x,y,z increments at its far fringes (significant figures),
and run a triple arithmetic increment from the origin to to any radius
desired.

The program will roar to its conclusion whether compiled from Fortran,
C++, Python, or (hold your nose) Basic.  No trig at all.

"8^>)  Thanks folks.  To the keyboard!

-- 
Uncle Al
http://www.mazepath.com/uncleal/
 (Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?"  The Net!

nuberpaul@nandomail.com (Paul Nuber) wrote in message news:<46223b20.0210172119.334bb773@posting.google.com>...
> uncle Al wants it to work in windows, he may not have a fortran compiler.

g77 is available for windows, and is surprisingly good for the price. 

> It is more easy with python.  

The point was to provide something which a human with no in depth
knowledge of programming has a good chance of understanding. Since
fortran has been pretty stable since 1966, there's a better chance
that a mature scientist has at least seen it before. For the python
you posted, we needed to "import math", know about the range function,
have some notion of objects to handle the file and realise that the
line noise is a format statement. For the fortran you had to know to
how to compile (g77 myfile.f), execute and save the results (a.exe >
outputfile), and probably be aware of the implicit typing if you
wanted to change it. For both you needed some idea of a loop, either
"for" or "do" syntax. Both examples present their own problems for a
programming novice, so without wanting to start a religous war, I
don't understand why any one language is "more easy" than another. I
would be interested to seen an implementation using recursion instead
of loops, ideally in haskell, since I keep meaning to try and learn a
bit of it.

Cheers,

Jon

PS: Since fortran is usually at least 10 times faster than plain
python, I personally find that my development time for number
crunching applications is correspondingly reduced :)

Jon wrote:
> 
> nuberpaul@nandomail.com (Paul Nuber) wrote in message news:<46223b20.0210172119.334bb773@posting.google.com>...
> > uncle Al wants it to work in windows, he may not have a fortran compiler.
> 
> g77 is available for windows, and is surprisingly good for the price.
> 
> > It is more easy with python.
> 
> The point was to provide something which a human with no in depth
> knowledge of programming has a good chance of understanding. Since
> fortran has been pretty stable since 1966, there's a better chance
> that a mature scientist has at least seen it before. For the python
> you posted, we needed to "import math", know about the range function,
> have some notion of objects to handle the file and realise that the
> line noise is a format statement. For the fortran you had to know to
> how to compile (g77 myfile.f), execute and save the results (a.exe >
> outputfile), and probably be aware of the implicit typing if you
> wanted to change it. For both you needed some idea of a loop, either
> "for" or "do" syntax. Both examples present their own problems for a
> programming novice, so without wanting to start a religous war, I
> don't understand why any one language is "more easy" than another. I
> would be interested to seen an implementation using recursion instead
> of loops, ideally in haskell, since I keep meaning to try and learn a
> bit of it.
> 
> Cheers,
> 
> Jon
> 
> PS: Since fortran is usually at least 10 times faster than plain
> python, I personally find that my development time for number
> crunching applications is correspondingly reduced :)

Whoa!  No pissing contests!  The best code is the code that works.

I've got an 80 A radius sphere of Te lattice courtesy of 

http://millenia.cars.aps.anl.gov/cgi-bin/atoms/atoms.cgi

on a good day.  (0200 hrs this past Saturday.  I figured everybody
else on the server with the program had either gone home or not come
in yet).  Cut out a wholly contained 90-90-90 degree block with the
same center, all six of whose sides exactly split the difference in
the lattice.

Take the block and translate it three or five times along -x and x. 
Take the string and translate it three or five times along -y and y. 
Take the plane and translate it three or five times along -z and z. 
Carve a humongous sphere out of the cube.  Each of the blocks is
perfect.  Only worry about the interfaces.

The x-direction is OK at all symmetrically paired boundaries if they
does not cut an atom.  The z-axis is only coherent at multiples of the
unit cell c-axis and always duplicates atoms - clean out the *.XYZ
file with software.  The y-axis requires some thought.  It doesn't
have a rational repeat distance.

A program that only runs addition and subtraction should run in real
time in Windows.  Probably.

-- 
Uncle Al
http://www.mazepath.com/uncleal/
 (Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?"  The Net!

Uncle Al <UncleAl0@hate.spam.net> wrote in message news:<3DB4524A.AE58D39@hate.spam.net>...
> Jon wrote:
> > 
> > nuberpaul@nandomail.com (Paul Nuber) wrote in message news:<46223b20.0210172119.334bb773@posting.google.com>...
> > > uncle Al wants it to work in windows, he may not have a fortran compiler.
> > 
> > g77 is available for windows, and is surprisingly good for the price.
> > 
> > > It is more easy with python.
> > 
> > The point was to provide something which a human with no in depth
> > knowledge of programming has a good chance of understanding. Since
> > fortran has been pretty stable since 1966, there's a better chance
> > that a mature scientist has at least seen it before. For the python
> > you posted, we needed to "import math", know about the range function,
> > have some notion of objects to handle the file and realise that the
> > line noise is a format statement. For the fortran you had to know to
> > how to compile (g77 myfile.f), execute and save the results (a.exe >
> > outputfile), and probably be aware of the implicit typing if you
> > wanted to change it. For both you needed some idea of a loop, either
> > "for" or "do" syntax. Both examples present their own problems for a
> > programming novice, so without wanting to start a religous war, I
> > don't understand why any one language is "more easy" than another. I
> > would be interested to seen an implementation using recursion instead
> > of loops, ideally in haskell, since I keep meaning to try and learn a
> > bit of it.
> > 
> > Cheers,
> > 
> > Jon
> > 
> > PS: Since fortran is usually at least 10 times faster than plain
> > python, I personally find that my development time for number
> > crunching applications is correspondingly reduced :)
> 
> Whoa!  No pissing contests!  The best code is the code that works.

Indeed no pissing contests but I cannot stop banging some words on here.
a. for a novice a non-compiling language is "more easy", he does not
   have to read through the pages of man page if his program does not
   compile
b. python is intuitive and easy to learn (read the tutorial, 0.5 days, and
   you can start programming)

don't get me wrong, I wrote tons of Fortran before convincing the
sonofafox to give me the degree.  Python is just like writing something
in awk, sed, csh : convenient.  It can also be very powerful too, 
rumor is that a good part of Google is powered by Python.  
My original intent: he might find it handy when he face similar
problems latter (e.g. if he wants to read a .cif file and repeat
10^4 times the unit cell, he can do it ALL in a python shell,
read the cif with a program which understand space group, spit
out a xyz file for a single cell, read the xyz file, 
repeat the unit cell, spit out the big chunk.
He might even want to program the socket and send
to his friend too!).

best
paul