<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>
<div>Hi,</div>
<div><br>
</div>
<div>I believe I just hit onto two bugs/bugettes in Molpro</div>
<div><br>
</div>
<div>(a) the def2-QZVPP basis set in $MOLPRO/lib/def2-nzvpp-orb.libmol appears to have near-duplicate polarization exponents for iodine:</div>
<div><br>
</div>
<div>
<div>I f def2-QZVP def2-QZVPP : 6 0</div>
<div> F. Weigend, F. Furche, R. Ahlrichs: JCP 119, 12753 (2003); K. A. Peterson, D. Figgen, E. Goll, H. Stoll, M. Dolg: JCP 119, 11113 (2003)</div>
<div>6.42536136        2.178             <u>0.5878            0.5865</u>          
<b> 0.25              0.2494</b></div>
<div>I g def2-QZVP def2-QZVPP : 2 0</div>
<div> F. Weigend, F. Furche, R. Ahlrichs: JCP 119, 12753 (2003); K. A. Peterson, D. Figgen, E. Goll, H. Stoll, M. Dolg: JCP 119, 11113 (2003)</div>
<div><b>0.4739            0.473</b></div>
</div>
<div><br>
</div>
<div>This looks like the product of a wonky basis set format conversion filter? Fortunately this is pretty easy to fix by replacing the above lines  by </div>
<div><br>
</div>
<div>
<div>
<div>I f def2-QZVP def2-QZVPP : 4 0</div>
<div> F. Weigend, F. Furche, R. Ahlrichs: JCP 119, 12753 (2003); K. A. Peterson, D. Figgen, E. Goll, H. Stoll, M. Dolg: JCP 119, 11113 (2003)</div>
<div>6.42536136        2.178             <u>0.5878            </u><b>0.25</b></div>
<div>I g def2-QZVP def2-QZVPP : 1 0</div>
<div> F. Weigend, F. Furche, R. Ahlrichs: JCP 119, 12753 (2003); K. A. Peterson, D. Figgen, E. Goll, H. Stoll, M. Dolg: JCP 119, 11113 (2003)</div>
<div><b>0.4739</b></div>
</div>
</div>
<div><b><br>
</b></div>
<div><br>
</div>
<div>(b) More seriously (but fairly easy to fix) the DFT-D3 module has an issue with ECPs. dftd3 calls subroutine rdcoord2 in $MOLPRO/sapt/dftd3 to read coordinates and elements. Unfortunately, rdcoord2 pulls the charges from array "charg" in common/cgeom rather
 than converting atname to atomic numbers. This makes no difference in all-electron calculations, but obviously creates problems if using something ECP-based, such as (say) cc-pVTZ-PP or def2-QZVP.  Somehow, substituting dispersion parameters of manganese for
 bromine or iodine doesn't yield terribly sensible dispersion corrections ;-)</div>
<div><br>
</div>
<div>The solution is, instead of reading the charges verbatim from "charg", to change rdcoord2 in $MOLPRO/sapt/dftd3 to instead feed the element names in array atname in common/cgeom to the subroutine elem(key1,natomnum) for conversion.</div>
<div><br>
</div>
<div>Best regards</div>
<div>Jan Martin</div>
<div><br>
</div>
</div>
</div>
</body>
</html>