On Tue, 24 Feb 2004, Miguel Howard wrote:
> > But
> > for the output, a specialized file format, or protocol, is needed
> > anyway. As input the molecular structure is needed and any file format
> > (if correctly parsed) can pass it, but in output we need to pass many
> > different kinds of data:
> >
> > -calculated energy
> > -calculated forces
> > -intermediate/final energies and coordinates
> > -(later perhaps) molecular dynamics snapshot data
> > -(later perhaps) calculated normal modes
> > -(later perhaps) el.stat.potentials, el.densities, etc...
> > -and so on...
>
> This makes me a little nervous ... :-)
Even if this looks bad, it isn't so; please let me explain :)
> If you want to pass pack all that data then you are probably going to want
> to feed it back to Jmol. That implies that Jmol can store this data, do
> something with it, and/or display it.
Ok, primarily this data is passed to the plugin, and only if needed it is
then passed further to jmol. So far I have planned operations "calculate
energy" and "do geometry optimization" and this is how it should work:
calculate energy:
^^^^^^^^^^^^^^^^^
1) plugin takes atoms/bonds from jmol, and makes the input file which is
then passed to the cgi-program with instructions "calculate energy".
2) cgi-program calculates the energy value (using MM or some QM method,
whatever is requested).
3) the cgi-program writes to the output something like "the energy is xx
kJ/mol" and this information is passed back to the plugin.
4) the plugin reads the output, parses the energy information from it, and
shows the result to the user ; the value is not passed to Jmol.
do geometry optimization:
^^^^^^^^^^^^^^^^^^^^^^^^^
1) plugin takes atoms/bonds from jmol, and makes the input file which is
then passed to the cgi-program with instructions "do geometry
optimization".
2) cgi-program does the geometry optimization ; for simplicity let's say
that no intermediate values are requested and nor sent to the plugin
(althought this would be nice since user could then know what's happening).
3) the cgi-program writes to the output something like "the final energy
is xx kJ/mol" and this information is passed to the plugin ; also the
final coordinates are passed to the plugin, for example using the
coordinates record of the ghemical file format:
!Coord
0 1.122 0.222 2.434
1 0.232 2.434 0.223
etc...
4) the plugin reads the output, parses the energy information from it, and
shows the result to the user ; then it also reads in the coordinate
information, *and* passes that to Jmol by updating the atom coordinates at
Jmol ; now the user gets both the final energy and the final coordinates
as well, which is the optimized structure. Now the whole operation is
processed remotely, and the user has all the results.
So please remember that it is the task of the plugin to read the output
and display it to the user ; it might either display it directly (like
showing the value of the calculated energy) or it might let Jmol show it
(like by updating the atom coordinates at Jmol and asking Jmol to update
the graphics).
The above two operations are the first ones, put also other options
could be added later (like molecular dynamics etc).
> Other than text labels, none of this capability exists today.
>
> Actually, we can also show vectors on atoms, so that may be a way to show
> a 'calculated force' as well.
Yes, this is exactly what I thought.
> So, what do you want to do with all these 'energy' values?
Please see above ; the plugin can show them directly to the user.
> > There is no ready file format that could pass all this (at least the way
> > we need) so for output a specialized file format is needed anyway.
> >
> > What do you think? In my optinion the file format conversions would be
> > better done so that the user can see the result first and only after
> > that (if it looks correct) do the calculations.
>
> I do not understand.
Well, basically I meant that file format conversions should be handled
separately from this comp.chem. plugin, because it is somewhat different
issue and therefore handling it separately is easier. Or in other words,
it would be for the comp.chem. plugin easiest to just copy the atoms and
bonds form jmol, and then pass them to cgi-program using a single,
well-defined/tested file format.
> > If the conversion and
> > calculation steps are combined, it might lead into very strange errors
> > (for example the calculations are done for a molecule with misplaced
> > bonds). Therefore I would make the input format also a specialized one.
> >
> >> Tell me what all of your parameters are, what the acceptable values
> >> are, and I will build the form for you.
> >
> > The parameters needed are
> >
> > "method" tells what kind of model is used(MM/QM etc).
> > "request" tells what operation should be done.
> >
> > The accepted values initially would be
> >
> > "method" = "MM"
> > "request" = "CalcEne" or "DoGeomOpt"
> >
> > Later some more choices will be added.
>
> By 'more choices will be added' do you mean more options for these two
> parameters or do you mean more parameters?
More options for these two.
> I think it would be good if we could use words other than 'method' and
> 'request'. These words are already over-subscribed, particularly in the
> world of http and protocols.
"request" could also be "job" ; and "methods" could be "params" or
something like that since it just tells how the job should be done.
> I assume that you also want a 'data' field.
Yes, it could be "data" or "input". These tree fields would be enough.
I haven't had time to work on the cgi-program now, so it seems to go into
next week...
Tommi
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
