I sent this to users, but it bounced. Still important. ---------- Forwarded message ---------- From: Robert Hanson <hans...@stolaf.edu> Date: Fri, Aug 15, 2014 at 12:36 AM Subject: jmol-14.3.6_2014.08.14.zip To: "jmol-us...@lists.sourceforge.net" <jmol-us...@lists.sourceforge.net>
I would appreciate testing of http://chemapps.stolaf.edu/jmol/zip/jmol-14.3.6_2014.08.14.zip There is a significant change here, a necessary one that addresses an insidious difference between Java and JavaScript. It is subtle and not generally a problem. Mostly it relates to crystallographic files with symmetry, but I would appreciate testing by others just to make sure I didn't break anything else. Would like to get this released this week end. ___JmolVersion="14.3.6_2014.08.14" bug fix: JavaScript drag-drop clears cache inappropriately when spt file is dropped IMPORTANT NOTE: The problem described here only affects the reading of states that have been created for crystallographic files, and then only if the state was created in Java and then displayed in JavaScript, or vice-versa. The problem is due to the fact that the Java implementation of Jmol uses float values for atom coordinates, while JavaScript is restricted to using only double values. The problem arises when a comparison must be made between two decimal values. After symmetry has been applied, it is possible for atom coordinates to be off in the 4th-7th decimal digit for floats and 14th-17th for doubles in the range -256 to 256. The problem is most acute for inorganic crystal systems where symmetry has been applied and especially after the CONNECT NONE command has been issued. Aspects where a problem might arise include: -- packing of unit cells, where atoms are discarded -- iterating over atoms, where atom order is important -- autobonding, where distances and order are critical -- comparing Cartesian or fractional coordinate values Solution to the problem is to automatically round all fractional atom coordinates to a precision of 0.00001 and all Cartesian atom coordinates to a precision of 0.0001. This forces both double and float implementations to the same value and results in no practical error, since these ranges are well beyond the precision of atom coordinates in crystals. Coincidence is assured for fractional coordinates up to about 126 and for Cartesian coordinates up to about 838. This rounding is not implemented for state or PNGJ file with state version v where v < 140206 || v >= 140300 && v < 140206 and in general only in the case where the file coordinates are fractional. Thus, those files be read exactly as in the version they were created by. And they will have have the same issues as well. The result is also much cleaner-looking atom coordinates. For example, in JavaScript: print {*}.fxyz {0.33333328149215147 0.999999891271352 1.0000000000000024} {0.6666666148254848 0.999999891271352 1.0000000000000024} {0.9999999844017011 1.000000000000001 0} {0.9999999616049127 0.9999999316096356 0.6290004156275991} {0.9999999709556066 0.9999999596617175 0.3709995843724032} {0.9999999481588181 0.999999891271352 1.0000000000000024} becomes: {0.33333 1 1} {0.66667 1 1} {1 1 0} {1 1 0.629} {1 1 0.371} {1 1 1} new feature: set legacyJavaFloat -- set by Jmol when a state is read that is before 14.2.6 or in the range 14.3.0 - 14.3.5; -- prevents fractional and cartesian coordinate rounding. -- cleared by ZAP or LOAD or loading of any later state script new feature: MOLDEN extensions [SpaceGroup] [Operators] [Cell] -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Department of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Department of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
_______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
