README for vcif_3, 9 Dec 2009
Introduction:
This is a preliminary release of vcif with support for DDLm using
dREL, working against the August 2008 specification of DDLm.
As of this writing, DDLm is being revised to a new "CIF 2"
specification, so this kit should not be used for production work
yet. Check the sourceforge vcif site for later releases
http://sf.net/projects/vcif
If you have any difficulty with this kit, contact
Elena Zlateva, elitty at gmail dot com
or
Herbert J. Bernstein, yaya at bernstein-plus-sons dot com
Work on vcif 3 was funded in part by the International Union of
Crystallography and is based in work on CBFlib funded in part
by grants from the NIGMS of the U.S. National Institutes of Health and
the Office of Science of the U. S. Department of Energy.
Our thanks to James Hester for providing the dREL parser used by
vcif_3.
Usage:
-----
Assuming cif2cbf is in your PATH and csh as you shell:
Place the file to be tested, say c2ctest5.cif, and the appropriate
dictionary, say, cif_expanded.dic in the current working directory
and execute:
cif2cbf -B read -v cif_expanded.dic -w -i c2ctest5.cif \
-o /dev/null |& grep CBFlib
in a bash shell, the above command should be:
cif2cbf -B read -v cif_expanded.dic -w -i c2ctest5.cif
-o /dev/null 2>&1 grep CBFlib2>&1
In this case the output you should get would be (line folded for clarity):
CBFlib: warning input line 14 (1) -- _cell.volume value provided conflicts
with generated value. CBFlib generated value 1759.01678255:
CBFlib: warning input line 15 (1) -- _cell.volume value provided conflicts
with generated value. CBFlib generated value 1759.01678255:
CBFlib: warning input line 15 (1) -- _cell.volume value out of dictionary range
CBFlib: warning input line 16 (1) -- _cell.volume value provided conflicts
with generated value. CBFlib generated value 1759.01678255:
CBFlib: warning input line 17 (1) -- _cell.volume value missing - CBFlib
generated value: 1759.01678255
Installation:
-----------
You will need a unix-like system with C, C++, Fortran and Python installed.
the combination of gcc 4, g++4, g95 or gfortran for gcc 4, and python 2.5
work. Under windows, use of MINGW and MSYS are recommended.
You will need source of this kit
vcif_3_9Dec09.tar.gz http://downloads.sf.net/vcif/vcif_3_9Dec09.tar.gz
For the Python portions of the package, you will need
package snapshot URL
numpy-1.4.0rc1.tar.gz http://downloads.sf.net/cbflib/numpy-1.4.0rc1.tar.gz
ply-3.2_7Dec09.tar.gz http://downloads.sf.net/cbflib/ply-3.2_7Dec09.tar.gz
dREL-ply-0.5_9Dec09.tar.gz http://downloads.sf.net/cbflib/dREL-ply-0.5_9Dec09.tar.gz
PyCifRW-3.3_6Dec09.tar.gz http://downloads.sf.net/cbflib/PyCifRW-3.3_6Dec09.tar.gz
the vcif3 kit contains copies of the last 3 kits in the cbflib_bleeding_edge
directory. Assuming you have python and gcc installed, install numpy, ply and
PyCifRW. Follow the instructions in the READMEs for those three kits. The general
idea is to go into the kit directory and execute
python setup.py install
Both will require the same level of system access as was needed for
your base python installation, so in many unix systems, you will need to
do
sudo python setup.py install
instead.
In the cbflib_bleeding_edge directory, after choosing the appropriate Makefile or
editing it for your system:
make install
to put cif2cbf, drel_prep.py, drel_yacc.py, drel_lex.py and drelc.py into
your PATH
Summary of Changes:
12/07/09 vcif_3_9Dec09.tar.gz
First release candidate for vcif_3 using patch from J. Hester. Found logic
error in the CBFlib call in trying to get a value for a tag already in
the data file.
12/09/09 vcif_3_9Dec09.tar.gz
Change dREL call logic to change any use of the tag being evaluated to have
a different name by appending _local, so dREL will always try to generate the
value with a method. Updated the vcif package to include a preprocessing
script for the data passed on to the dREL compiler. This script (drel_prep.py)
changes the occurrences of the item name we are validating to a local name,
so as to ensure the dREL compiler produces calculations whether or not there
is a given value. Currently, the validation runs against the exact value
returned from the calculations. A certain degree of allowed error is to be
implemented in the next release.
Note: The support of looped values runs a bit slow in the current
implementation, but will be improved in the next release.