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

[Lee-Ping Wang]

Hi Berk,

I didn't know about Votca before - it looks like a good code and I can
probably learn some cool things from them. :)

Thanks,

- Lee-Ping

-----Original Message-----
From: gmx-developers-bounces at gromacs.org
[mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Berk Hess
Sent: 05 November 2012 00:22
To: Discussion list for GROMACS development
Subject: Re: [gmx-developers] Fluctuating charge code, Q-Chem interface,
force matching.

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.
>

--
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.