Tommi wrote: >> A few small fields for your parameters ... plus one BIG field for the >> data file. > > Ok, I see. We in have two possibilities: > > 1) pass the extra parameters in extra fields (see above). > 2) pass the extra parameters as a part of the data file.
Good point. > Actually these are quite the same thing, just the parsing would be a bit > different. The strength of 1) could be that it is not tied into any > specific file format, which is good. On the other hand, if several file > formats were accepted, it would be not only flexible but also more > error-prone, unfortunately. The choice 2) would be that the input file > would be more specific to the task, less flexible but less error-prone. > > What comes to input, I think either of the 2 above ways would work. I feel more comfortable with #1. As a general rule, it is a good idea to separate your control from your data. However, I am saying that without knowing anything about the data that you want to pass. > 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 ... :-) 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. 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. So, what do you want to do with all these 'energy' values? > 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. > 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? 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. I assume that you also want a 'data' field. Miguel > 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
