Menu
▾
▴
#24 file reader for CASTEP and AIMS input files
I have added two readers for input files, which make use of the periodic boundary conditions (PBC) infrastructure of Jmol
- CASTEP: http://www.castep.org (.cell files - only PBC)
- FHI-aims: http://www.fhi-berlin.mpg.de/aims/ (geometry.in files - both cluster models and PBCs)
Using the signed applet, the readers can be tried here
http://w3.rz-berlin.mpg.de/~meyer/jmol-demo-20090819/
patch against Jmol-11.6.27
sample CASTEP .cell file
sample FHI-aims geometry.in file (cluster)
sample FHI-aims geometry.in file (periodic boundary conditions)
Please send the .java files; I have to patch these into 11.8, not 11.6. Thanks.
to be added under "src/org/jmol/adapter/readers/more" ?
to be added in "src/org/jmol/adapter/readers/more"
includes chnages for AIMS and CASTEP readers, based on 11.6.27
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).
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
*
*/
%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.
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)
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;
version 1.1: added comments
version 1.1: added comments and changed to lower case keywords
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!
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.
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;
}
CASTEP-generated CML file
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?
versions 1.2 of AIMS and CASTEP readers, based on 11.8.5
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.
versions 1.2 of AIMS (with multipole support added) and CASTEP readers, based on 11.8.8
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...
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.