I can answer that. All measurements are assumed to be in bohr.
As Miguel mentions, there is this original document that SUGGESTED that
cube files might be in Angstroms sometimes and Bohrs other times.
However, as I was developing from Miguel's code I noticed that his code
ignored that and just used Bohrs. I followed up by looking at some files
from Gaussian and found that website to not represent the files that
Gaussian produces.
For example:
http://educ.gaussian.com/visual/Diff/html/DiffGaussView.htm and
http://educ.gaussian.com/visual/Diff/Files/acrolein1_gs.cube
Acrolein
SCF Total Density
8 -6.512752 -6.512752 -4.970736
77 0.190777 0.000000 0.000000
69 0.000000 0.190777 0.000000
96 0.000000 0.000000 0.190777
8 8.000000 0.000000 0.000000 0.000000
6 6.000000 0.000000 0.000000 4.587499
6 6.000000 1.406901 0.000000 6.727236
6 6.000000 1.306368 0.000000 1.987047
1 1.000000 -2.018605 0.000000 4.704662
1 1.000000 3.324973 0.000000 1.869695
1 1.000000 0.499266 0.000000 8.534192
1 1.000000 3.425507 0.000000 6.610073
These coordinates are all in Bohr, even without the supposedly necessary
negative sign.
So taking Gaussian.inc as the authority on Gaussian cube files, I went
with Miguel's original plan.
The simple solution is that since you obviously know fo cube files that
are in Angstroms, we can add a system-wide flag that indicates that we
should read cube files in Angstroms when necessary. Something like:
set cubeFileUnitsAngstrom
set cubeFileUnitsBohr
or such.
Bob
Jonathan Gutow wrote:
>Dear jmol experts,
> I've encountered a scaling issue while converting surface
>grid files from one program format to another. It appears to be the
>difference between units of Bohr and Angstroms. Which does Jmol
>expect, or does it check some how?
>
> Thanks for your help.
>
>Jonathan
>
>
Miguel wrote:
>>Dear jmol experts,
>> I've encountered a scaling issue while converting surface
>>grid files from one program format to another. It appears to be the
>>difference between units of Bohr and Angstroms. Which does Jmol
>>expect, or does it check some how?
>>
>>
>
>Jmol's isosurface support was for Gaussian .cube files.
>
>URL is at http://astronomy.swin.edu.au/~pbourke/dataformats/cube/index.html
>
>It says:
>
>"If the sign of the number of voxels in a dimension is positive then the
>units are Angstroms, if negative then Bohr."
>
>** 2 minutes later **
>
>This is certainly the document that I looked at when I implemented the
>isosurface code, but a quick review of the code seems to indicated that I
>may not have implemented this properly. In particular, the current
>implementation looks like it is always converting scaling by
>ANGSTROMS_PER_BOHR, rather than doing so only when the count is negative.
>
>So, this may be a bug.
>
>Sorry, I can't look into this any deeper at this time.
>
>
>Miguel
>
>
>
>_______________________________________________
>Jmol-users mailing list
>Jmol-users@...
>https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>

> Dear jmol experts,
> =09I've encountered a scaling issue while converting surface
> grid files from one program format to another. It appears to be the
> difference between units of Bohr and Angstroms. Which does Jmol
> expect, or does it check some how?
Jmol's isosurface support was for Gaussian .cube files.
URL is at http://astronomy.swin.edu.au/=7Epbourke/dataformats/cube/index.=
html
It says:
=22If the sign of the number of voxels in a dimension is positive then th=
e
units are Angstroms, if negative then Bohr.=22
** 2 minutes later **
This is certainly the document that I looked at when I implemented the
isosurface code, but a quick review of the code seems to indicated that I=
may not have implemented this properly. In particular, the current
implementation looks like it is always converting scaling by
ANGSTROMS_PER_BOHR, rather than doing so only when the count is negative.=
So, this may be a bug.
Sorry, I can't look into this any deeper at this time.
Miguel

Dear All,
I have updated my perl scripts to small java applications
that automate the process of creating simple web pages that display
orbitals. I hope to expand this to include many of the basic things
people would like to do, such as animating vibrations with QM data.
See my home page (link below) for the link to the tools. My
web site is being reorganized, so a direct link my not work.
Hope someone finds this useful. Suggestions and comments are also welcome.
Jonathan
--
---------------------------------------------------------------------------
Dr. Jonathan H. Gutow
Chemistry Department gutow@...
UW-Oshkosh Office:920-424-1326
800 Algoma Boulevard FAX:920-424-2042
Oshkosh, WI 54901
http://www.uwosh.edu/faculty_staff/gutow/

Re: measurements AKA measurement AKA measure AKA measures AKA monitor
AKA monitors
currently we have:
set measurements OFF # HIDES all measurements
set measurements ON # UNHIDES all measurements
measurements # UNHIDES all measurements
measurements ON # UNHIDES all measurements
measurements OFF # DELETES all measurements
It seems odd to me that "measurements ON" is not the opposite of
"measurements OFF".
That is, it seems to me that "measurements OFF" should just hide the
measurements, not delete them, and that there should be another
mechanism to actually DELETE the measurements.
I propose:
measurements OFF #hide all (current) measurements
measurements ON #unhide all (current) measurements
measurements DELETE #delete all (current) measurements
to go along with some new functionality in 10.x, namely:
measure OFF (atom expression) (atom expression) ....
measure ON (atom expression) (atom expression) ....
measure DELETE (atom expression) (atom expression) ....
measure ALL (atom expression) (atom expression) ....
measure ALLCONNECTED (atom expression) (atom expression) ....
measure RANGE minValue maxValue (atom expression) (atom expression) ....
where the keywords OFF, ON, ALL, ALLCONNECTED, RANGE minValue maxValue,
and DELETE can be mixed as desired:
measure DELETE ALL RANGE 0.1 1.5 (carbon) (oxygen)
measure ALLCONNECTED (carbon) (oxygen)
measure OFF ALLCONNECTED (carbon) (oxygen)
(The keyword RANGE is optional here, as omitting it leads to no ambiguity.)
This would not effect the overriding
set measurements OFF
which would still hide all measurements regardless of their individual
visibility settings.
I believe this change will have minimal impact, as "measurement OFF"
will appear to work the same unless a later "measurement ON" is given in
current scripts. The current use of "measurement ON" I find unlikely,
since currently after a "measurement OFF" command, "measurement ON" does
nothing at all.
Comments?
Bob