Tommi wrote: >> 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".
OK > 2) > cgi-program calculates the energy value (using MM or some QM method, > whatever is requested). OK > 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. OK > 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. Understood. So in this case no data goes to the Jmol viewer ... all is processed by the plugin as part of the Jmol application. > 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". OK > 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). OK > 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... OK > 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. OK > 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). OK > The above two operations are the first ones, put also other options > could be added later (like molecular dynamics etc). OK >> 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. Good >> So, what do you want to do with all these 'energy' values? > > Please see above ; the plugin can show them directly to the user. Understood >> > 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. OK >> > 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. OK >> 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... I will put togther a simple form for you. > Tommi Miguel ------------------------------------------------------- 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
