<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Rolf,<div class=""><br class=""></div><div class="">the point is that the QM part is - strictly speaking - not translational invariant for arbitrary translation vectors. This means that if you re-center at every step for an arbitrary translation vector you will see a drift, given by the fact that an atom - depending on its relative position w.r.t. grid points - may experience numerically different forces (with a deviation, hopefully lower than the norm). Moreover, the situation is even more dramatic because the recenter vector will not be random, but rather subject to a constant direction bias, which will cause a pretty visible drift. </div><div class="">Your combination: 300 and CENTER_GRID are both going in the direction of: 1) minimising the error in the atomic forces by increasing cutoff 2)Re-center using a translation vectors which is commensurate to grid spacing. Both should help minimise drift.</div><div class=""><br class=""></div><div class="">CENTER_GRID has no computational overhead. </div><div class="">300 Ryd cutoff instead should marginally increase the cost.</div><div class=""><br class=""></div><div class="">Teo</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Mar 2015, at 08:23, Rolf David <<a href="mailto:rolf.d...@gmail.com" class="">rolf.d...@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I've done test on my systems and reach out some conclusions.<div class=""><br class=""></div><div class="">GAPW / B3LYP / 280/40 cutoff / CENTER_EVERY_STEP gave me a slow drift and some fluctuations (for 2ps)</div><div class=""><br class=""></div><div class="">GAPW / B3LYP / 300/50 cutoff / CENTER_EVERY_STEP and with CENTER_GRID TRUE, almost no drift/fluctuations (for 2ps)</div><div class=""><br class=""></div><div class="">I don't know if it's the cutoff of the center_grid true which made an ompatch, but the computational cost is negligible (don't see a difference). I'll see next month what of it when i reach 15/20ps.<br class=""><div class=""><br class=""></div><div class=""><br class=""><br class="">On Thursday, March 19, 2015 at 12:48:29 PM UTC+1, Jonggu Jeon wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr" class=""><p style="text-align:left;clear:both" class="">Thank you for the suggestion.<br class=""><br class="">In fact, I'm currently running a new job with MGRID/CUTOFF=480 and CENTER EVERY_STEP. As you can see in the following figure, the early result indicates a very good energy conservation at the same level as the previous best example (CUTOFF=280 and CENTER SETUP_ONLY). <br class="">What troubles me is the fact that computation time increases rapidly with larger CUTOFF and the same level of energy conservation is already possible with smaller cutoff if no centering is used.</p><p style="text-align:left;clear:both" class="">However, given the circumstances, I agree that using centering and larger cutoff is the best way to go.</p><p style="text-align:left;clear:both" class="">Regards,</p><p style="text-align:left;clear:both" class="">Jonggu<br class=""></p><p style="text-align:center;clear:both" class=""><a style="margin-left:1em;margin-right:1em" href="https://lh6.googleusercontent.com/-P0Moyh0OT5k/VQq0qY--uYI/AAAAAAAAA3w/6xnksES21jA/s1600/te.png" target="_blank" rel="nofollow" onmousedown="this.href='https://lh6.googleusercontent.com/-P0Moyh0OT5k/VQq0qY--uYI/AAAAAAAAA3w/6xnksES21jA/s1600/te.png';return true;" onclick="this.href='https://lh6.googleusercontent.com/-P0Moyh0OT5k/VQq0qY--uYI/AAAAAAAAA3w/6xnksES21jA/s1600/te.png';return true;" class=""><img src="https://lh6.googleusercontent.com/-P0Moyh0OT5k/VQq0qY--uYI/AAAAAAAAA3w/6xnksES21jA/s320/te.png" border="0" height="233" width="320" class=""></a></p><br class=""><br class=""><br class="">2015년 3월 19일 목요일 오후 8시 17분 54초 UTC+9, Matt W 님의 말:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Try increasing the cutoff to 600-800 Ry? BLYP functional is known to be noisy.<div class=""><br class=""></div><div class=""><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I have repeated the QM/MM MD using MULTIPOLE OFF using the latest CP2K trunk binary (svn:15171). The total energy from this new run is *identical* to the previous one using MULTIPOLE section. The only difference is that the decoupling/recoupling energies and the warning messages about QM atoms close to the boundary are not printed in the output file any more.<br class=""><br class=""></div></blockquote><div class="">Dorothea pointed out that, _if_ your QM box is the same size as the QMMM box (as you have in the input above), you don't need the de/recoupling - it _should_ give identical results. It just slows the calculation a little.</div><div class=""><br class=""></div><div class="">HTH</div><div class=""><br class=""></div><div class="">Matt</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I have also tried the "CENTER_GRID T" keyword together with CENTER EVERY_STEP as Matt suggested above and its short time energy profile up to 100 fs is nearly the same as the one without CENTER_GRID. I guess the total energy is still adversely affected by the centering even with the CENTER_GRID.<br class=""><br class="">From these observations, I'm afraid it's likely that the current CP2K cannot handle gracefully the QM atoms crossing boundary. <br class="">I'd appreciate any comment or suggestion.<br class=""><br class="">Jonggu<br class=""><br class=""><br class="">2015년 3월 18일 수요일 오후 9시 13분 29초 UTC+9, Matt W 님의 말:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div>there is also the CENTER_GRID that has been introduced quite recently. I don't know how much it has been tested, maybe someone else can comment? But for my simple test water system it seems to improve the energy conservation considerably. The idea is, I think, to only center the QM molecule in a "quantized" manner on equivalent grid points of the (fine DFT?) grid.<div class=""><br class=""></div><div class="">To get really good energy conservation you might need to increase your cutoff/rel_cutoff too.<br class=""><div class=""><br class=""></div><div class="">Matt<br class=""><br class="">On Wednesday, March 18, 2015 at 11:22:10 AM UTC, Jonggu Jeon wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Dear Dorothea,<br class=""><br class="">Thank you for the invaluable suggestion. <br class="">While your answer makes perfect sense to me, I just found out that CP2K 2.5.1 does not have option to turn off QMMM/PERIODIC/MULTIPOLE using the section parameter OFF.<br class="">Therefore, CP2K 2.5.1 produces the same (diverging) energy profile whether I set &MULTIPOLE OFF or not.<br class=""><br class="">I will install version 2.6 and try it again.<br class=""><br class="">Best regards,<br class=""><br class="">Jonggu<br class=""><br class=""><br class="">2015년 3월 18일 수요일 오후 6시 22분 40초 UTC+9, Dorothea Golze 님의 말:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi,<br class=""><br class=""></div>if you have a fully periodic setup where the QM and MM boxes are equal, you do not need the decoupling/recoupling stuff, i.e. switch off explicitly the MULTIPOLE section like that<br class="">&MULTIPOLE OFF<br class=""></div>&END<br class=""><br class=""></div>Also set in the QMMM section<br class=""><br class=""> &WALLS<br class=""> TYPE NONE<br class=""> &END WALLS<br class=""><br class=""></div>That should address your first question...<br class=""><br class=""></div>Cheers,<br class=""></div>Dorothea<br class=""><div class=""><div class=""><div class=""><div class=""><div class=""> <br class=""></div></div></div></div></div></div><div class=""><br class=""><div class="gmail_quote">2015-03-18 8:46 GMT+01:00 Jonggu Jeon <span dir="ltr" class=""><<a rel="nofollow" class="">jeon...@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Dear CP2K users,<br class=""><br class="">I'd like to ask some questions on the capabilities of the QM/MM part of CP2K (I'm using version 2.5.1, svn:13632).<br class=""><br class="">I've been attempting a QM/MM MD simulation with CP2K. My system consists of one NMA molecule (TZV2P/BLYP DFT) and 48 methanol molecules (OPLS MM force field).<br class="">The relevant parts of my input file are attached at the end of the message. Basically, I'm following all the advices from this group for a fully periodic QM/MM setup and set the cell sizes for the QM (in QMMM/CELL) and MM (in SUBSYS/CELL) parts equal.<br class=""><br class="">The following is the summary of my findings.<br class=""><br class="">1. With FORCE_EVAL/QMMM/CENTER EVERY_STEP, the total energy is not conserved, as pointed out by Dr. Laino in this group before.<br class="">2. With FORCE_EVAL/QMMM/CENTER SETUP_ONLY, the total energy is very well conserved within 0.1 kcal/mol for a few ps until the QM molecule eventually crosses the cell boundary. At this point system energy shoots up by several kcal/mol and the output begins to produce the following messages:<br class=""><br class=""> *** 16:11:03 WARNING in qmmm_util:apply_qmmm_walls_<wbr class="">reflective :: One or ***<br class=""> *** few QM atoms are within the SKIN of the quantum box. Check your run ***<br class=""> *** and you may possibly consider: the activation of the QMMM WALLS ***<br class=""> *** around the QM box, switching ON the centering of the QM box or ***<br class=""> *** increase the size of the QM cell. CP2K CONTINUE but results could be ***<br class=""> *** meaningless. qmmm_util.F line 206 <wbr class=""> ***<br class=""><br class="">My questions are as follows:<br class=""><br class="">1. Is it possible to achieve the energy conservation in a fully periodic DFT/MM MD without worrying about the QM molecule crossing the cell boundary? I believe this is possible in full DFT MD but my experience on CP2K QM/MM so far indicates otherwise. I'd appreciate if someone can provide an answer and keywords to achieve it.<br class=""><br class="">2. The QMMM/CENTER option affects energy conservation a lot. When CENTER EVERY_STEP is used, would it improve energy conservation if I use finer grids by increasing DFT/MGRID/CUTOFF value?<br class=""><br class="">The skeletal form of my input file is attached below.<br class="">Thank you.<br class=""><br class="">Jonggu Jeon<br class=""><br class=""><br class=""><br class=""> &MOTION<br class=""> &MD<br class=""> ENSEMBLE NVE<br class=""> STEPS 40000<br class=""> TIMESTEP 0.5<br class=""> STEP_START_VAL 0<br class=""> TIME_START_VAL 0<br class=""> &END MD<br class=""> &END MOTION<br class=""> &FORCE_EVAL<br class=""> METHOD QMMM<br class=""> &DFT<br class=""> BASIS_SET_FILE_NAME /opt/cp2k/2.5.1/tests/QS/GTH_<wbr class="">BASIS_SETS<br class=""> POTENTIAL_FILE_NAME /opt/cp2k/2.5.1/tests/QS/<wbr class="">POTENTIAL<br class=""> WFN_RESTART_FILE_NAME wfn.rst<br class=""> CHARGE 0<br class=""> &SCF<br class=""> MAX_SCF 30<br class=""> EPS_SCF 9.9999999999999995E-07<br class=""> SCF_GUESS RESTART<br class=""> &OT T<br class=""> MINIMIZER DIIS<br class=""> PRECONDITIONER FULL_ALL<br class=""> ENERGY_GAP 1.0000000000000000E-03<br class=""> &END OT<br class=""> &OUTER_SCF T<br class=""> EPS_SCF 9.9999999999999995E-07<br class=""> MAX_SCF 1<br class=""> &END OUTER_SCF<br class=""> &END SCF<br class=""> &QS<br class=""> EPS_DEFAULT 1.0000000000000000E-10<br class=""> MAP_CONSISTENT T<br class=""> EXTRAPOLATION ASPC<br class=""> EXTRAPOLATION_ORDER 3<br class=""> METHOD GPW<br class=""> &END QS<br class=""> &MGRID<br class=""> CUTOFF 2.8000000000000000E+02<br class=""> COMMENSURATE T<br class=""> &END MGRID<br class=""> &XC<br class=""> &XC_GRID<br class=""> XC_SMOOTH_RHO NN50<br class=""> XC_DERIV SPLINE2_SMOOTH<br class=""> &END XC_GRID<br class=""> &XC_FUNCTIONAL NO_SHORTCUT<br class=""> &BECKE88 T<br class=""> &END BECKE88<br class=""> &LYP T<br class=""> &END LYP<br class=""> &END XC_FUNCTIONAL<br class=""> &VDW_POTENTIAL<br class=""> POTENTIAL_TYPE PAIR_POTENTIAL<br class=""> &PAIR_POTENTIAL<br class=""> TYPE DFTD3<br class=""> PARAMETER_FILE_NAME /opt/cp2k/2.5.1/tests/QS/<wbr class="">dftd3.dat<br class=""> REFERENCE_FUNCTIONAL BLYP<br class=""> CALCULATE_C9_TERM F<br class=""> REFERENCE_C9_TERM F<br class=""> LONG_RANGE_CORRECTION F<br class=""> &END PAIR_POTENTIAL<br class=""> &END VDW_POTENTIAL<br class=""> &END XC<br class=""> &END DFT<br class=""> &MM<br class=""> &FORCEFIELD<br class=""> PARMTYPE AMBER<br class=""> PARM_FILE_NAME ndmd48.ao.prmtop<br class=""> &SPLINE<br class=""> EMAX_SPLINE 1.0000000000000000E+00<br class=""> &END SPLINE<br class=""> &END FORCEFIELD<br class=""> &POISSON<br class=""> &EWALD<br class=""> EWALD_TYPE SPME<br class=""> ALPHA 3.4999999999999998E-01<br class=""> GMAX 18<br class=""> &END EWALD<br class=""> &END POISSON<br class=""> &END MM<br class=""> &QMMM<br class=""> E_COUPL GAUSS<br class=""> USE_GEEP_LIB 7<br class=""> NOCOMPATIBILITY T<br class=""> CENTER SETUP_ONLY<br class=""> INITIAL_TRANSLATION_VECTOR -1.0888775605157457E+01 -2.9066675351256084E+00 7.3922596274008097E+00<br class=""> &CELL<br class=""> ABC 1.5084868700000001E+01 1.5084868700000001E+01 1.5084868700000001E+01<br class=""> PERIODIC XYZ<br class=""> &END CELL<br class=""> &PERIODIC<br class=""> GMAX 5.0000000000000000E-01<br class=""> &MULTIPOLE<br class=""> RCUT 1.2000000000000000E+01<br class=""> EWALD_PRECISION 4.9999999999999998E-07<br class=""> ANALYTICAL_GTERM T<br class=""> NGRIDS 50 50 50<br class=""> &END MULTIPOLE<br class=""> &END PERIODIC<br class=""> &END QMMM<br class=""> &SUBSYS<br class=""> &CELL<br class=""> A 1.5084868700000001E+01 0.0000000000000000E+00 0.0000000000000000E+00<br class=""> B 0.0000000000000000E+00 1.5084868700000001E+01 0.0000000000000000E+00<br class=""> C 0.0000000000000000E+00 0.0000000000000000E+00 1.5084868700000001E+01<br class=""> MULTIPLE_UNIT_CELL 1 1 1<br class=""> &END CELL<br class=""> &TOPOLOGY<br class=""> NUMBER_OF_ATOMS 156<br class=""> CONN_FILE_NAME ndmd48.ao.prmtop<br class=""> CONN_FILE_FORMAT AMBER<br class=""> MULTIPLE_UNIT_CELL 1 1 1<br class=""> &END TOPOLOGY<br class=""> &END SUBSYS<br class=""> &END FORCE_EVAL<span class=""><font color="#888888" class=""><br class=""><br class=""></font></span></div><span class=""><font color="#888888" class=""><div class=""><br class="webkit-block-placeholder"></div> -- <br class=""> You received this message because you are subscribed to the Google Groups "cp2k" group.<br class=""> To unsubscribe from this group and stop receiving emails from it, send an email to <a rel="nofollow" class="">cp2k+...@googlegroups.com</a>.<br class=""> To post to this group, send email to <a rel="nofollow" class="">cp...@googlegroups.com</a>.<br class=""> Visit this group at <a href="http://groups.google.com/group/cp2k" rel="nofollow" target="_blank" onmousedown="this.href='http://groups.google.com/group/cp2k';return true;" onclick="this.href='http://groups.google.com/group/cp2k';return true;" class="">http://groups.google.com/<wbr class="">group/cp2k</a>.<br class=""> For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" class="">https://groups.google.com/d/<wbr class="">optout</a>.<br class=""> </font></span></blockquote></div><br class=""></div> </blockquote></div></blockquote></div></div></div></blockquote></div></blockquote></div></div></blockquote></div></blockquote></div></div></div><div class=""><br class="webkit-block-placeholder"></div> -- <br class=""> You received this message because you are subscribed to the Google Groups "cp2k" group.<br class=""> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:cp2k+uns...@googlegroups.com" class="">cp2k+uns...@googlegroups.com</a>.<br class=""> To post to this group, send email to <a href="mailto:cp...@googlegroups.com" class="">cp...@googlegroups.com</a>.<br class=""> Visit this group at <a href="http://groups.google.com/group/cp2k" class="">http://groups.google.com/group/cp2k</a>.<br class=""> For more options, visit <a href="https://groups.google.com/d/optout" class="">https://groups.google.com/d/optout</a>.<br class=""> </div></blockquote></div><br class=""></div></body></html>