From: zoran (
Date: Mon Dec 15 2014 - 17:13:16 CST

I have tracked the source of the reported "bug" to bad input. Both the ffTK and QMtool code perform as expected, without error. The initial parameter file you provided contained many terms that don't match the provided PSF/PDB, and potentially have some other problems,

such as angles defined as:
CG321 HGA2 CG2O2 0.000 0.000
CG321 HGA2 HGA2 0.000 0.000

and dihedrals defined as:
CG321 CG321 HGA2 HGA2 0.0000 1 0.00
HGA2 HGA2 HGA2 CG321 0.0000 1 0.00

Assuming typical bonding topologies, hydrogens should only be found at terminal points of angles or dihedrals. This is indicative of a bad topology (PSF/PDB) generated by the user prior to entering the ffTK workflow. This input explains both observed errors. When performing the "guess" stage of the bond/angle optimization setup, ffTK matches the parameters pulled from the Hessian against the input parameter file. Here, most of the matches fail, which is why only four angles appear in the box. Since the parameter file doesn't match your PSF/PDB, the NAMD call generates the error during the actual optimization. In my hands, providing a corrected parameter file results in bond/angle optimization without error.

Yes, I followed the instructions from fftk and used molefracture for generating psf and pdb files. All the atom types were assigned according to _all36_cgenff.prm. The bonds were also build up as they should be. Probably I should inspect the angles and dihedrals but there was no advice to alter these within init-par file.

Anyway, thanks for trouble and finding that the error is on my side. That’s better than vice versa. One who is more experienced with this job would looked at the init-par file at the very beginning but the bad thing with novice users is that they strictly follow the manual.

Huh, now I wish to apologize for the badly written init-par file; thank you again and sorry for trouble.

With my best regards

Christopher Mayne

On Dec 15, 2014, at 2:28 PM, zoran wrote:

  I think it is important to clarify that there are two very distinct issues under discussion here:

  1) Zoran's usage of ffTK is throwing an error when NAMD is called as a background process

  This is what I reported as a bug isn’t it.

  2) Theoretical discussions regarding how to treat transition metals using CHARMM-compatible (i.e., fixed point charge MM model) force field, and if it is even appropriate to try.

  That’s why I’m here

  With regard to issue #1-- I have been able to reproduce the reported error from the provided input files, and I'm currently in the process of diagnosing the cause of the error. ffTK very clearly does support new atom types (although you do have to assign LJ terms by analogy); this does not appear to be the source of this particular error. Based on the traceback from NAMD and the behavior of the 'guess' function in the ffTK GUI, something appears to be amiss with the hessian parser. ffTK relies on the QMtool plugin to do this and it will take me some time to track down the specifics. I didn't write QMtool, so that adds a little bit of time to the debug process.

  I wrote “FFTK or some plugin (qmtool or ...)” and haven’t been specific

  With regard to issue #2-- I will have to sit this one out and let others with a more appropriate background in transition metal chemistry and experience with metalloproteins and/or chelates chime in for the theoretical discussion. However, it is important to separate this out from the syntactical error reported in the plugin.

  I just wanted an answers or indications about the problem

  With regard to the tone of "antagonism" in this thread--
  Parameterization is hard. It is hard for theoreticians. It is hard for practitioners. There are tricks, tips, pitfalls, solutions, and unresolved issues. The ffTK documentation site provides links to important papers, force field discussion forums, descriptions of the GUI, and tutorial screencasts. We try to provide useful tools for everyone from novice users to expert users. It is up to all participants to read the materials, inform themselves, assess their project, ask good/clear questions, give thoughtful/clear responses, and exercise a little bit of patience. When things just aren't adding up, it may be worth asking yourself whether you're missing something simple or really just in over your head. It's OK; parameterization is hard. But accusations and antagonism aren't a productive use of anyone's time or energy--especially on the weekend.

  I am sorry Christopher if You feel accused for anything from my side. My statement found in subject: “FFTK most probably doesn't work with molecules containing new atom types” shouldn’t be understood as an accusation but rather as state of the facts. Here we do not deal with my knowledge about parameterization (it is minor and I am I am well aware of that fact) but with the issues opposite to the procedure given in excellent descriptive fftk video manual. And You wrote that the error is most likely in qmtool plugin. However the qmtool plugin is now constitutive part of calculations proposed by fftk, so if we cannot finish the particular fftk session because of particular plugin that’s still an error that should concern fftk authors.
  Anyway, in the last posts I asked for answers why is that so. I did not asked from anyone to spend free time to solve my problems just to tell me “ OK here we have some plugin difficulties which cannot be solved in short time so be patient and when things appear to be fixed we’ll get back to you”. And, that’s it.
  I am a bit tired of this param. discussion so do you people, I believe, so Chris don’t bother yourself with this issue anymore please. Somehow I little bit regret I found here and made trouble to You and others.
  So if anyone felt hurt and insulted because of my posts I REALLY AND SINCERELY APOLOGIZE ESPECIALLY TO CHRISTOPHER AND ALL OTHERS.

  With my best regards

  and for the record--
  As the developer of ffTK, I have a strong and demonstrated interest in addressing user reported errors, feature requests, and other feedback. Both myself and JC (the coauthor of ffTK) spend many many hours responding to questions, frequently sent to our individual email accounts. I consistently encourage all users not to email me directly, but rather to send email to VMD-L, where there is a broad user community that can both aid in answering questions, as well as, benefit from the discussion. I follow VMD-L very closely, and provide support in a timely manner when at all possible. That said, like most other scientists, I am quite busy and sometimes I cannot respond immediately. Because discussions on VMD-L aid the larger community, I give them priority over direct email.

  Christopher Mayne

  On Dec 14, 2014, at 10:20 AM, zoran wrote:

    Now I wish to again point out the problem about fftk and optimization of bonding parameters what was original reason for me to place this post.

    I have already send all the files to Chris and You. However no answer may be because of previous useless debate.
    I really asked for Your help with respect to fftk.
    Josh, If You are right Is there any possibility to have valid answer or opinion on my questions and a subject of this post? I have no doubts about accuracy of the charges, bonds, angles and dihedrals optimizing by the automatism of fftk even in case of my complex just tell me how?
    I’ll repeat my original mail:
    I still cannot move further with optimization of bonds and angles in FFTK.
    This time I’ll try to formulate my problem in a clear manner:
      1.. First I have done all the things requested by fftk:
            a) I prepared PSF & PDB Files Using Molefacture without many troubles (I assigned type of different atoms using all36_cgenff topology)

            b) I went through BuildPar (obtained pdobap-int.par) and updated with vdw LJ parameters. As You can see I placed vdwLJ values for Pd(II) taking these from the most similar work.

            c) I went through Opt.Geometry fine (here is to mention that I replaced 6-31G with sdd bs because of Pd) ; Water Int. almost fine as fftk (or some interfaced plugin; maybe qmtool) wrote Gaussian input file with P (phosphorous) instead of Pd (palladium), so I had to correct it through all the files manually. Do You know why is that so?

            d) However after that Opt. Charges went fine so I succeeded to update psf file with charges.

            e)I calculated hessian without any trouble
            f) Now I have problem with Calc. Bonded. I put all the requested items into input (psf, opt, hess log and int-par files leaving AA Parameter files empty and determined path for namd2.exe. Then I’ve dialed with Parameters to optimize.

    Here is the problem: When I push ‘'Guess” button the program wrote all the bonds but only four angles (no palladium within them). Anyway I started “Run Optimization” and fftk (better to say namd) stopped with the warnings that some angle parameters are not present (here I red from Tk_console_log – attached- that Qmtools again transformed my Palladium into P).

    I added manually, step by step these angles after every warning with corresponding values of angles from optimized molecule and placed random force constants for these angles. At the end when no angles left more program started requesting torsions this time. Ehhh, that’s put the last drop into my glass.

    So You see I‘ve done everything requested but somewhere must be a bug that crash this for me so much wanted finalization.”

    Hi Zoran,
    What specific problems have you encountered? I don't see what is special about metals that they should result in problems for the methodology of FFTK. A blanket statement that it doesn't work isn't helpful, because as written FFTK DOES work for many atomtypes, including new chemistries not found in released force fields.
    -Josh Vermaas

    On 12/13/2014 06:50 AM, zoran wrote:

      I think that You actually never run fftk with molecule holding a new atom type. Is this true?
      Somewhere fftk has a bug while trying to optimize bonds and angles of molecules with new atom types. And I also think that this has not any matter with metals as a constituent (it could be let we say Boron or Phosphorous atom in diff. surroundings).

      I suppose You have no time and will to dig into fftk to correct it.

      However it is fair to say to the people that FFTK is not supposed to work with molecules containing new atom types. This does not represent anything that would diminish the importance of FFTK as a powerful tool.

      I say this accounting that I have done all requested tasks (including addition of vdwLJ values) and stacked into bonds and angles. I do not see any fault from my side so above is most probably true.

      I am very sorry that scientists making force fields for macromolecules forget on transition metals (in general) and that TM make a substantial part of biological processes.

      With my best regards to all of you