On Tue, 1 Mar 2005, Geoff Hutchison wrote: > A few questions so I can get slightly better code into Open Babel... > > > !Info 1 allmm 241 > > ^^^^^^^^^^^ a "setup" class name and an "engine" class ID > > for QM. valid "setups" are allmm and allqm. > > So for translating from some other format (i.e., PDB) to Ghemical 1.5x, > this should go default to: > > !Info 1 allmm -1 Yes, this is the best way to write files. The current version in CVS will check the value and show a message box "did not find a matching engid"; if this is annoying it can be changed/removed in future. When reading the files, just skip the rest of the line starting form allmm/allqm/etc. > > !Atoms 3 > > 0 8 +0 0 > > Again, so the above line would be a default from another format? Do you Yes, this is the default setting. > think it would be useful to assign atom types using the OB atom typing > code? For example, it'd be possible to translate from Sybyl Mol2 types, > which would save some time for the user. Of course if you think the > Ghemical MM types are going to change a lot, this wouldn't be worth the > effort. I think I could not effectively utilize atom types form other sources, because the atom typings and the rest of the mol.mech. force field parameters "fit together", or trying to say it otherwise, the way how atom types are assigned will determine the contents of the rest of the force field parameter tables, and those parameter tables must be "tailor-made" for each atom type set. If the atom typing and the parameter tables are not built to "fit together" it is often found that the tables lack parameters for some combination of types (the "missing parameters" problem). The strength of the !Section idea in the file format is that we could easily include the atom typing into the file format, but I'm not sure how I could utilize it now. > One further request... > I'd *really* like to access the periodic boundaries for file types with > unit cell information. Is the periodic engine working in the 1.5 tree? > I don't see a dialogue for setting the boundary parameters. The old code for box-shaped boundaries still exist, but it seems that the GUI is still incomplete for this. About periodic boundary calculations generally, it seems that gromacs http://www.gromacs.org/ has a very advanced support for that. So I have thought that instead of duplicating the work done for gromacs it would make more sense to just run the gromacs MD engine from (lib)ghemical, in one way or another. But this is just an idea so far, I have not had time to work on gromacs yet. Regards, Tommi