[gmx-developers] Fluctuating charge code, Q-Chem interface, force matching.

[Berk Hess]

Hi,

Don't worry too much about GPU stuff, we won't require that
for all contributions.

Force matching can be done with Gromacs using the Votca package:
http://www.votca.org/
I don't know if that covers all the functionality you have implemented.

Cheers,

Berk

On 11/05/2012 08:58 AM, Lee-Ping Wang wrote:
> Hi Gerrit and Michael,
>
> Thanks for the replies.  Here are some more details.
>
> - Concerning the interface with Q-Chem, we didn't have to make any changes
> to the Q-Chem source code.  The two programs communicate using a file-based
> interface; Gromacs writes two Q-Chem input files (qchem.in and ESPGrid) and
> Q-Chem produces a file with electric fields (efield.dat).  Out of the three
> features, this one is by far the easiest.  I'd be happy to provide some
> example files and documentation.
>
> I'm interested to hear about how you guys are planning to restructure the
> QM/MM interface, because having a framework that works with multiple codes
> is both challenging and an important problem.
>
> - Regarding the fluctuating charge force field, it is integrated as follows:
>
> a) All of the computation is done in a new file, qtpie.c .  Most of the
> computation is linear algebra because it involves solving for the
> fluctuating charges at each time step.
> b) The forces are computed in do_force_lowlevel right before do_nonbonded is
> executed.
> c) The extra data (electronegativities etc.) is stored in the "t_mdatoms"
> structure, but I can create a separate structure if desired.
> d) The fluctuating charge parameters are read using an extra section in the
> topology file ([ qtpie ], which fits between [ atoms ] and [ bonds ]).
> e) One extra neighbor list is required, which is coded into ns.c .
> f) Periodic boundary conditions are handled using shift functions where the
> force goes smoothly to zero (i.e. the second derivative of the energy is
> continuous).
> g) It's currently working in 4.0.7, but I'm working on porting it over to
> 4.5.5.
>
> I'm not an expert at GPU coding, but maybe there's a straightforward way to
> use the GPU to execute the calls to BLAS and LAPACK.
>
> I have a question about BLAS and LAPACK: Currently qtpie.c includes headers
> from the Intel MKL library, "mkl_lapack.h" and "mkl_cblas.h".  This probably
> needs to be changed.  What is the best way to call BLAS and LAPACK without
> causing trouble for the user in the build process?  Should I be using the
> Gromacs-provided libraries, and are there examples for how to do this?  (I
> can't find many instances of linear algebra calls in the code base.)  Also,
> how do I give users the option to link to external BLAS and LAPACK
> libraries?
>
> - Regarding the energy and force derivatives, I've been thinking about it
> some more and I should probably discard this code.  I don't think it's
> possible to have them as an external tool because they require changing a
> lot of low-level subroutines in bondfree.c and the nonbonded inner loops.
> It facilitates force field parameterization but it isn't required;
> furthermore, it requires too many changes to the code base and can be very
> cumbersome to maintain.
>
> My force field parameterization methods are a different from Greg Voth's
> methods although I learned a lot from his work.  My goal is to create a
> general framework where a variety of reference data can be incorporated into
> the objective function, so that force field parameters can be simultaneously
> optimized to fit experimental and theoretical data in a systematic way.  I'm
> implementing these methods into a software package for parameterization
> called ForceBalance (https://simtk.org/home/forcebalance).  It works using
> file-based interfaces with Gromacs and several other codes, and I might like
> to submit it as a "user contribution" at some point.
>
> Thanks,
>
> - Lee-Ping
>
> -----Original Message-----
> From: gmx-developers-bounces at gromacs.org
> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Gerrit Groenhof
> Sent: 04 November 2012 23:05
> To: Discussion list for GROMACS development
> Subject: Re: [gmx-developers] Fluctuating charge code, Q-Chem interface,
> force matching.
>
> Dear Lee-Ping,
>
> On 1 and 2 we already had some exchange in the past, and I am pleased to see
> that you got it done.
>
> Concerning the interface with Q-chem, if it is documented, and works without
> too much coding on the Q-chem part (in contrast to gaussian!!), I'd be happy
> to have it. There is an initiative to restructure the complete qmmm setup,
> as we now are getting too many program-specific interfaces.
>
> On 1, I think it will be interesting to have, but I think it also depends on
> how well it is integrated (and integratable). I suppose it would also have
> to work on GPU now?
>
> Concerning the forcematching. Is this the same procedure as that of Voth and
> co-workers. We used that, but as a seperate tool. Unless it is something
> else, I'd think such code would be more suitable as a gmxtool?
>
> Best,
> Gerrit
>
>
> On Nov 4, 2012, at 9:43 PM, Lee-Ping Wang wrote:
>
>> Dear developers,
>>
>> I'm a postdoctoral fellow in the Stanford Chemistry department working
>> with Vijay Pande and Todd Martinez.  I earned my Ph.D. from the MIT
>> Chemistry department under the supervision of Troy Van Voorhis.  I've
>> been using MD software as a central part of my research for over five
>> years, and I am definitely a big fan of GROMACS. :)
>>
>> Over the course of my Ph.D. I did a lot of method development in Gromacs.
> I'm writing to find out whether there's interest in integrating any of my
> contributed code into the Gromacs code base.
>> My contributions are in three main categories:
>>
>> 1) A fluctuating charge code following the work of Steve Rick and Bruce
> Berne, with further improvements following the work of Jiahao Chen and Todd
> Martinez.
>> 2) A QM/MM interface with Q-Chem, mainly following the existing QM/MM
> interface with Gaussian.
>> 3) Energy and force matching code for force field optimization.  This
> consists mainly of adding analytic first and second parametric derivatives
> for the energy and force terms into the low-level subroutines that compute
> the force field contributions.
>> Items (1) and (3) are incorporated into an upcoming publication which was
> just accepted to JCTC.
>> These methods have been implemented into version 4.0.7.  Most of the code
> (perhaps 95%) is in separate files with as little modification to the
> original code as possible.  All of the functionality is controlled through
> the input files and command line arguments.  There is no performance impact
> for normal MD runs because the parametric derivatives are only switched on
> when requested.
>> If there is interest on your side, I'd be happy to do all of the work.  I
> think the work involved is mainly (1) updating the code to be compatible
> with the latest development branch, (2) writing unit tests, and (3) creating
> documentation.
>> Please let me know and I'll do my best to follow the directions on the
> Gromacs website and stay in touch.
>> Thanks,
>>
>> - Lee-Ping--
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www
>> interface or send it to gmx-developers-request at gromacs.org.
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the www interface
> or send it to gmx-developers-request at gromacs.org.
>