Bob, I'll be very interested in seeing what you end up with. A couple more
thoughts on this....
I did some tests, and there are two problems. First, the data are definitely
mangled. I see escape sequences that should not be there -- \/ -- (escape
FORWARD slash) for example, and there must be something else wrong, because
what is happening is that the first "cryptic" line, which represents the
position of the edges of the triangles, is too short, so Jmol is going to
the next line (the color line, which in this case just indicates no color)
and reading that. Then it runs out of data on the color line and chokes. I
find no problem reading JVXL files written by 11.6.21 (I don't have 11.6.15
here) and no notes relating to bug fixes, so I think there's no problem with
the ORIGINAL JVXL file. Something along the way of getting it into the
database and back out has mangled it or possibly something in gmail wrecked
it. I don't know.
Yes, the WebMO .MO file would be FAR better to save in the database, because
it preserves all the other useful information.
Also, there's a bug in Jmol that doesn't let it read isosurface data from
the inline string. The following WOULD be the way to read that file if that
bug were not there:
jmolAppletInline(300,getMol(),"isosurface '';" )
(that's isosurface single-quote single-quote)
In other words, "load the model inline and then read the isosurface from the
file that was loaded".
That will work in the next version of Jmol. But you won't need it if you use
the MO file. With that you would just use:
jmolAppletInline(300,getMol(),"mo 1")
and if there are multiple MOs in the file, then you can get all of them in
the right-click menu, and you can enumerate them on your page using:
jmolAppletInline(300,getMol(),"mo 1;javascript 'fileLoaded()'; ")
and then, in JavaScript:
function fileLoaded() {
var mos = jmolGetPropertyAsArray("auxiliaryInfo.models[1].moData.mos")
alert(mos.length + " molecular orbitals were loaded")
for (var i = 0; i < mos.length; i++) {
alert(mos[i].energy)
}
}
The auxiliaryInfo property has data like this:
auxiliaryinfo.models[1].moData.mos *Vector[1]
auxiliaryinfo.models[1].moData.mos[1].occupancy 2.0
auxiliaryinfo.models[1].moData.mos[1].energy -0.42780003
auxiliaryinfo.models[1].moData.calculationType "?"
auxiliaryinfo.models[1].moData.energyUnits "eV"
[Note that in JavaScript you have to reduce those indexes by 1 because Jmol
starts with [1] and goes through [0] (so you can always pick up the last
element with [0] or the next to last with [-1], etc.]
You have to be a little careful there, as indicated, so that you do not try
to access file information until the applet is downloaded and the model file
is loaded. Here's the generic way to do that that also shows how you can
display all the auxiliary info that came with the file:
<head>
function getMol() { return "some valid model file data" }
function fileLoaded() {
var info = jmolGetPropertyAsString("auxiliaryInfo")
document.getElementById("outputdiv").innerHTML = "<pre>" + info + "<pre>";
}
</script>
</head><body>
<script type=text/javascript>
jmolAppletInline(300,getMol(),"javascript fileLoaded()")
</script>
<div id="outputdiv"></div>
</body>
</html>
My point is simply that you can easily pull out the information in the .MO
file that could be useful in the web page presentation.
Good luck!
Bob
On Sat, Jan 23, 2010 at 11:59 PM, Grossman, Robert B <
[email protected]> wrote:
> Ah, I see. And the .jvxl file that my friend sent me must have been
> created by Jmol from a QM calculation that my friend had generated with
> WebMO and loaded into Jmol. So when he was trying to make my life easier by
> sending me the .jvxl file instead of the WebMO results file, he was really
> making it more difficult, because I was loading the data inline, and Jmol
> couldn't read the isosurface data in the .jvxl file.
>
> It all becomes much clearer now...
>
> It seems the best solution for us is just to store the QM results file into
> the database, deliver the data inline to Jmol, and use scripts and the
> Javascript library to have Jmol generate the MOs. It achieves all our
> goals.
>
> Thanks for your patient explanations.
>
>
> On 1/23/10 11:34 PM, "Robert Hanson" <[email protected]> wrote:
>
>
>
> On Sat, Jan 23, 2010 at 9:33 PM, Grossman, Robert B <
> [email protected]> wrote:
> We can let Jmol create the MO from the QM data in the browser - I think
> that is what we are doing now with the .mo file - but we greatly prefer to
> read the QM data from the database, not from a file.
>
> I'm still trying to understand the mutual dependencies among load,
> isosurface, and mo.
>
> When I use "jmolLoadInline()" with the contents of the .mo file, I can see
> the structure, and I can use the script "mo" (as implemented by the
> jmolMenu() JS command) to display the MOs.
>
>
> By .MO file, not sure what you mean there, unless that's a WebMO file. The
> fact that you can use the MO command indicates that you are creating the
> orbitals from the basis functions and coefficients.
>
> When I use "jmolLoadInline()" with the contents of the .jvxl file, I can
> see the structure, but I cannot find a script that will display the
> isosurface. Is there a script that will display the isosurface after I load
> it into Jmol with "jmolLoadInline()"?
>
>
>
> This older JVXL file format was modeled on the CUBE format and thus did
> save up to the first 100 atoms; the newer XML version doesn't. But all you
> are doing there is reading the atoms. The load command doesn't read any
> surfaces ever. If the file has QM basis and coefficients, then those are
> read at load time (and the popup menu will be populated with items showing
> all the orbitals and their energies).
>
> The JVXL file is really a surface file and is read using the ISOSURFACE
> command. Until last week you couldn't load those inline. (You could load
> PMESH data -- simple triangles -- inline, but you couldn't use the
> isosurface INLINE keyword with anything else. I think I changed that early
> last week. So if that's really what you want to do, you need to use Jmol
> 11.9.21.
>
> So you can load MO data two ways -- with the LOAD/MO command combination or
> with the ISOSURFACE command. In Jmol "MO" is a subset of "ISOSURFACE" so the
> same code is run, but the options are a bit different. When you use
>
> MO homo
>
> you get a basic, standard orbital, with a nice listing of orbital
> properties in the upper left corner. Options are pretty much limited to
> cutoff and color. With
>
> ISOSURFACE MO homo
>
> you don't get that listing, but you have a bit more flexibility -- you can,
> for example, choose to ignore atoms and only see contributions from a
> subset, and you can do contouring, planar slices, "topo" maps, and such. I
> need to get this into the documentation....
>
> Bob
>
>
>
>
> On 1/23/10 8:39 PM, "Robert Hanson" <[email protected]> wrote:
>
> I think it just got mangled as being part of the email.
>
> isosurface is used to create MOs from files that are not QM files. --
> surfaces.
> mo is used to generate the MO data directly from the basis functions. Most
> people these days, I think, just let Jmol read the QM file and create the MO
> in the browser -- no need for a server end. Are you certain you can't do
> that?
>
> Bob
>
> On Sat, Jan 23, 2010 at 6:08 PM, Grossman, Robert B <
> [email protected]> wrote:
> Hi Bob,
>
> The information is read from an Oracle database and written into a JSP
> page. We have the ability to write information to files, but we want very
> much to avoid having to do it. We also want to avoid having to deal with
> multiple files to display a single molecule and its associated MOs. From my
> point of view, Jmol's preference for loading information from files is a
> real drawback.
>
> We worked around the problem by using a .mo file instead of a .jvxl file.
> We were able to load the .mo file inline and display its MOs without any
> problem. A friend gave us the proper Jmol JS commands to use to display the
> MOs. jmolMenu([['mo delete;','none'],['mo 3',"3"],['mo 4',"4"] ...]); . No
> "isosurface" commands.
>
> I don't think that we could have mangled the .jvxl information because the
> .mo information, which was loaded and transmitted in exactly the same way,
> was not mangled. But I could be wrong.
>
> So is it correct that we use "isosurface" to load MOs into Jmol, and we use
> "mo" to induce Jmol to display them?
>
> -- Bob
>
> On 1/23/10 5:44 PM, "Robert Hanson" <[email protected]> wrote:
>
> Well, two things. First, you must have mangled the data some way - or at
> least clipping from this page doesn't work. Because the attached file did
> run. Second, you can only load an isosurface "inline" like that in the very
> latest version of Jmol. (I'm not sure it's even in the one I have up at
> http://chemapps.stolaf.edu) What you would need to do is (all Jmol script
> here)
>
> isosurface INLINE @{javascript("getMol()")}
>
> that tells Jmol to read the output of the JavaScript getMol() function as
> the data for the isosurface instead of reading the data from a file.
>
> Any reason you don't want to have that data in a file? -- or is this coming
> back from a server and you are trying to keep it all together? Sure would be
> simpler:
>
> isosurface "somefile.jvxl"
>
> Bob
>
>
>
> On Wed, Jan 20, 2010 at 3:27 PM, Grossman, Robert B <
> [email protected]> wrote:
> Hi,
>
> I have a JVXL file containing MO data that I am trying to display. I can
> see the molecule, but I can't see the MO. I have tried various scripts to
> turn on the MO, to no avail. Below I have copied the relevant part of my
> Web page. I am using 'mo HOMO;' as the script, but I have tried several
> other commands, including none, to no avail. How do I display the MO? Does
> the fact that I load inline prevent the MO from being displayed?
>
> -- Bob
>
> <script type="text/javascript">
> // <!--
> function getMol() {
> return '#JVXL VERSION 1.4\n#created by Jmol Version 11.6.15
> 2008-11-24 13:39 on Wed Dec 09 20:51:19 CST 2009\nMO range (-4.286028,
> -4.170638, -6.45537) to (5.6358566, 10.584962, 3.6056142)\ncalculation type:
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
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
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
