[MMTK] Triple bonds?
rcrehuet at gmail.com
Wed Jul 13 15:27:58 UTC 2011
Yes, MMTK is much more complex than a pure QM software. But handling a
system with hudreds of atoms, with inputs that can have or not have H atoms,
that can be parameterized in different ways, not only with different
parameters but with different buidling units, such as c-alpha atoms vs.
all-atoms, all that is complex. It is also probably true that commercial
software designers spend more time making it user-friendly than scientists
But if your molecules have 54 atoms (including hydrogens?), you can run
decent QM calculations in a PC. I don't know what you want to do. If you
have the starting geometries, and only want to optimize them or do single
point calculations, go for MOPAC. It's free and very fast. You can do
single-point calculations with DFT and a decent basis with ORCA or GAMESS or
FIREFLY. Be ready to leave the computer on during night time :-) All of
them free and efficient.
If you need to run MD or MC then, you could try pDynamo. It's also based on
Python and has builtin support of semi-empirical methods. It also has DFT,
but rather slow. The setup of a pure QM system is easy. pDynamo is focussed
on QM/MM calculation on biomolecules. If you need to do that, you'll face
the same problems than with MMTK. The organization of the setup and the
energy terms is pretty complex.
Hope this helps,
2011/7/13 Christopher Drost <chris.drostie at gmail.com>
> On Thu, Jul 7, 2011 at 10:27 AM, Ramon Crehuet <rcrehuet at gmail.com> wrote:
> > Dear Christopher,
> > Considering the amount of human time vs. computer time, and if the
> > are smallish as you said, why don't you go for a QM method?
> > methods can treat prettly large molecules and you will not need to
> > parameterize anything.
> I might be able to get a friend who has access to the more-expensive
> software to do this for me, since MMTK is getting to be absurdly
> difficult to debug. I have also contemplated spending a week to learn
> some of the languages of the non-Python programs. I also have a copy
> of GAMESS that I might install and peek around. Still, I'm surprised
> that what seems like the most basic molecular-mechanics tasks are
> impossible for open-source projects. PyQuante's energy minimization
> system is buggy to the point of nonfunctional and would take several
> days to debug; MMTK does not believe in error handling and instead
> throws Segmentation Faults which I must trace with gdb. The one thing
> that has kind-of worked for some purposes is GPAW, but unfortunately
> it seems to take ages with 3-atom systems; my 54-atom system would
> probably tax it beyond all recognition.
> 2011/7/7 Konrad Hinsen <research at khinsen.fastmail.net>
> > Amber doesn't have the notion of a double or triple bond. The molecule
> > topology specifies just a bond, without any parameters. The interactions
> > then specified in terms of atom types. To get a triple bond, you thus
> > to introduce new atom types for the atoms on either side of the bond, and
> > then define an appropriate force constant for a bond between the atoms of
> > the corresponding types. This would typically be done in the form of a
> > "modification file" (in Amber terminology), i.e. an extension to the list
> > standard Amber parameters. MMTK uses standard Amber modification files,
> > you can follow the Amber documentation for the details:
> > http://ambermd.org/#ff
> When I tried this advice, I obtained another outside-of-Python
> segmentation fault. This one is beyond my abilities to debug. The
> segmentation fault is issued by line 202 of nonbonded.c, which reads:
> The problem is that 'box' is at this time set to -2147483648 (= 0x8000
> For the sake of context, this is the second time that nblist_update is
> called from MMTK. The first time it appears to run through the entire
> loop perfectly successfully. Both times when it enters the loop n_sub
> is 0 and n is 54.
> One potential cause of the error is that loop variable 'ai' gets
> similarly set to -2147483648 for reasons which I cannot properly
> comprehend. (C isn't really my thing, and whenever someone has to type
> 'gdb python' an angel loses its wings.)
> I can send the parameter files and code, etc. that I have constructed
> to anybody who is perhaps interested in debugging the problem, but I
> don't really have the time, resources, or energy to join MMTK as a
> proper contributor. This was supposed to be a quick calculation, not a
> code audit.
> -- Chris
> mmtk maillist - mmtk at starship.python.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mmtk