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 <robert.grossman@uky.edu> 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" <hansonr@stolaf.edu> wrote:



On Sat, Jan 23, 2010 at 9:33 PM, Grossman, Robert B <robert.grossman@uky.edu> 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" <hansonr@stolaf.edu> 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 <robert.grossman@uky.edu> 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" <hansonr@stolaf.edu> 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 <robert.grossman@uky.edu> 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
Jmol-users@lists.sourceforge.net
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
Jmol-users@lists.sourceforge.net
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
Jmol-users@lists.sourceforge.net
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