Dear Chris,<br>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 do. <br>
<br>But if your molecules have 54 atoms (including hydrogens?), you can run decent QM calculations in a PC. I don&#39;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&#39;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.<br>
<br>If you need to run MD or MC then, you could try pDynamo. It&#39;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&#39;ll face the same problems than with MMTK. The organization of the setup and the energy terms is pretty complex. <br>
<br>Hope this helps,<br>Ramon<br><br><br><br><div class="gmail_quote">2011/7/13 Christopher Drost <span dir="ltr">&lt;<a href="mailto:chris.drostie@gmail.com">chris.drostie@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Jul 7, 2011 at 10:27 AM, Ramon Crehuet &lt;<a href="mailto:rcrehuet@gmail.com">rcrehuet@gmail.com</a>&gt; wrote:<br>
&gt; Dear Christopher,<br>
&gt; Considering the amount of human time vs. computer time, and if the molecules<br>
&gt; are smallish as you said, why don&#39;t you go for a QM method? Semi-empirical<br>
&gt; methods can treat prettly large molecules and you will not need to<br>
&gt; parameterize anything.<br>
<br>
</div>I might be able to get a friend who has access to the more-expensive<br>
software  to do this for me, since MMTK is getting to be absurdly<br>
difficult to debug.  I have also contemplated spending a week to learn<br>
some of the languages of the non-Python programs. I also have a copy<br>
of GAMESS that I might install and peek around. Still, I&#39;m surprised<br>
that what seems like the most basic molecular-mechanics tasks are<br>
impossible for open-source projects. PyQuante&#39;s energy minimization<br>
system is buggy to the point of nonfunctional and would take several<br>
days to debug; MMTK does not believe in error handling and instead<br>
throws Segmentation Faults which I must trace with gdb. The one thing<br>
that has kind-of worked for some purposes is GPAW, but unfortunately<br>
it seems to take ages with 3-atom systems; my 54-atom system would<br>
probably tax it beyond all recognition.<br>
<div class="im"><br>
2011/7/7 Konrad Hinsen &lt;<a href="mailto:research@khinsen.fastmail.net">research@khinsen.fastmail.net</a>&gt;<br>
</div><div class="im">&gt; Amber doesn&#39;t have the notion of a double or triple bond. The molecule<br>
&gt; topology specifies just a bond, without any parameters. The interactions are<br>
&gt; then specified in terms of atom types. To get a triple bond, you thus have<br>
&gt; to introduce new atom types for the atoms on either side of the bond, and<br>
&gt; then define an appropriate force constant for a bond between the atoms of<br>
&gt; the corresponding types. This would typically be done in the form of a<br>
&gt; &quot;modification file&quot; (in Amber terminology), i.e. an extension to the list of<br>
&gt; standard Amber parameters. MMTK uses standard Amber modification files, so<br>
&gt; you can follow the Amber documentation for the details:<br>
&gt;<br>
&gt;        <a href="http://ambermd.org/#ff" target="_blank">http://ambermd.org/#ff</a><br>
<br>
</div>When I tried this advice, I obtained another outside-of-Python<br>
segmentation fault. This one is beyond my abilities to debug. The<br>
segmentation fault is issued by line 202 of nonbonded.c, which reads:<br>
<br>
    nblist-&gt;boxes[box].n++;<br>
<br>
The problem is that &#39;box&#39; is at this time set to -2147483648 (= 0x8000 0000).<br>
<br>
For the sake of context, this is the second time that nblist_update is<br>
called from MMTK. The first time it appears to run through the entire<br>
loop perfectly successfully. Both times when it enters the loop n_sub<br>
is 0 and n is 54.<br>
<br>
One potential cause of the error is that loop variable &#39;ai&#39; gets<br>
similarly set to -2147483648 for reasons which I cannot properly<br>
comprehend. (C isn&#39;t really my thing, and whenever someone has to type<br>
&#39;gdb python&#39; an angel loses its wings.)<br>
<br>
I can send the parameter files and code, etc. that I have constructed<br>
to anybody who is perhaps interested in debugging the problem, but I<br>
don&#39;t really have the time, resources, or energy to join MMTK as a<br>
proper contributor. This was supposed to be a quick calculation, not a<br>
code audit.<br>
<br>
-- Chris<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
mmtk maillist  -  <a href="mailto:mmtk@starship.python.net">mmtk@starship.python.net</a><br>
<a href="http://starship.python.net/mailman/listinfo/mmtk" target="_blank">http://starship.python.net/mailman/listinfo/mmtk</a><br>
</div></div></blockquote></div><br>