Jmol

ok, that's in for Jmol 11.9.10 and 11.8.9 -- please check those.
Additional features should be introduced to Jmol 11.9.10 only, not 11.8.9,
please.

I haven't given up on producing "CASTEP-CML", but the FoX libraries
(underlying XML engine) make some trouble with the available Fortran
compilers. Perhaps I need to start playing on another platform, but (again
and unfortunately) no time for that.
On the AIMS side I have added support for reading charges used for
electrostatic embedding
as given in "multipole" lines - see latest attached patch. Hope adding
that keyword to Resolver.java does not break other readers again...

Sorry, still no time for wurtzite.cml. But at least AIMS and CASTEP readers
now correctly display the cell contents of cells which are not 'properly'
(i.e. the way Jmol expects that internally) aligned with the reference
coordinate system.

Joerg, I need some help. I've added a file wurtzite.cml that appears to
have been created using CASTEP. The problem is in the transform3 fields.
These are the symmetry operations. Except the matricies appear to be
operating on Cartesian coordinates, not unit cell fractional coordintates.
This is very odd! I can't directly use these matrices to build symmetry
operations.

Q: Is this a file format you can produce with CASTEP?
Q: If so, can you get me some examples from other space groups -- in
particular monclinic and orthorhombic/tetragonal. I need to see what the
matrix looks like in those cases. Best would be some examples both in CIF
format and this CML format to compare.
Q: Do you know who knows how to properly work with these matrices?

Here is what I settled on:

private static boolean checkAims(String[] lines) {

// use same tokenizing mechanism as in AimsReader.java to also
recognize
// AIMS geometry files with indented keywords
// "atom" is a VERY generic term; just "atom" breaks HIN reader.
for (int i = 0; i < lines.length; i++) {
String[] tokens = Parser.getTokens(lines[i]);
if (tokens.length == 5 && tokens[0].startsWith("atom")
|| tokens.length == 4 &&
tokens[0].startsWith("lattice_vector"))
return true;
}
return false;
}

If the AIMS format is not finalized, I would like to suggest that it be
modified (I realize that could be a big deal) to
a) allow for comments in the form
#....
b) have a unique identifier such as

# FHI-AIMS (http://www.fhi-berlin.mpg.de/aims)

at the top.

Just noticed that revision 11359 compiles nicely with sun-jdk-1.6.0_15-b03
(64bit)
including changes below, but crashes even without changes below (!) when
trying
to run java -jar Jmol.jar:

uncaught exception: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
at org.jmol.viewer.StateManager.<clinit>(StateManager.java:487)
at org.jmol.viewer.Viewer.<init>(Viewer.java:248)
at org.jmol.viewer.Viewer.allocateViewer(Viewer.java:310)
at org.jmol.api.JmolViewer.allocateViewer(JmolViewer.java:90)
at
org.openscience.jmol.app.jmolpanel.JmolPanel.<init>(JmolPanel.java:150)
at org.openscience.jmol.app.Jmol.<init>(Jmol.java:36)
at
org.openscience.jmol.app.jmolpanel.JmolPanel.getJmol(JmolPanel.java:358)
at
org.openscience.jmol.app.jmolpanel.JmolPanel.startJmol(JmolPanel.java:293)
at org.openscience.jmol.app.Jmol.main(Jmol.java:41)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
range: 23
at java.lang.String.substring(String.java:1934)
at org.jmol.viewer.JmolConstants.<clinit>(JmolConstants.java:80)
... 9 more
Exception in thread "main" java.lang.NullPointerException
at
org.openscience.jmol.app.jmolpanel.JmolPanel.startJmol(JmolPanel.java:304)
at org.openscience.jmol.app.Jmol.main(Jmol.java:41)

Hence changes are untested!

1.) Based on the files you checked into 11.8, I added some comments at the
top
as requested and did some further changes as detailed in the following.
Resulting files
CastepReader.20090825.java
AimsReader.20090825.java
are attached.

2.) Strange - for some reason it seemed to work in 11.6.
Looking at your change (which makes perfect sense to avoid the warning)
I wonder why it actually does...

3.) I see your point. There are no official specs (yet) for FHI-aims
geometry.in files.
The code is written in Fortran, and hence you can easily exchange the tabs
for spaces
without the Fortran IO system (in list mode) bothering. In fact I just
convinced myself
that both "atom" and "lattice_vector" keywords must be lower case to be
accepted by
aims. To eliminate the collision with PBD, could you please change the
checkAims
method in Resolver.java accordingly, to e.g.

// FHI-aims only accepts keywords which are lower case -
// hence no conflict with PDB reader (which require upper case
"ATOM")
if ( tokens[0].startsWith("atom") ) return true;
if ( tokens[0].startsWith("lattice_vector") ) return true;

The proposed AIMS reader breaks PDB format. We can't allow "atom" to be a
marker, because "ATOM" is a marker for PDB files. So, if you want to read
these files, you must force the filetype using

load "aims::xxxx.in"

I can't find specs for that file type. Why are there tabs in the line? Can
we specify that "atom" must be lower case? (PDB must be upper case ATOM)

%BLOCK POSITIONS_ABS
ang

was causing a warning -- I've changed that. Please check out the 11.8.RC6
code that I have just checked in and work from that if you can now.

OK, I'm onto this. Please provide some comment text with http references,
for example:

/**
* Gaussian cube file format
*
* http://www.cup.uni-muenchen.de/oc/zipse/lv18099/orb_MOLDEN.html
* this is good because it is source code
* http://ftp.ccl.net/cca/software/SOURCES/C/scarecrow/gcube2plt.c
*
*
http://www.nersc.gov/nusers/resources/software/apps/chemistry/gaussian/g98/00000430.htm
*
* distances are in Bohrs because we are reading Gaussian cube OUTPUT
files
* not Gaussian cube INPUT files.
*
* Miguel 2005 07 17
* a negative atom count means
* that it is molecular orbital (MO) data
* with MO data, the extra line contains the number
* of orbitals and the orbital number
*
* these orbitals are interspersed -- all orbital values are
* given together for each coordinate point.
*
* also used for JVXL and JVXL+ file format
*
*/

Sorry - haven't thought about the fact that patch components
against empty files cannot be conveniently extracted when
trying to modify your current development version - I just
wanted to have the functionality added to a stable release
(which will be available from the AIMS web page quite soon).

Please send the .java files; I have to patch these into 11.8, not 11.6.
Thanks.