## VMD-L Mailing List

**From:** Mayne, Christopher G (*cmayne2_at_illinois.edu*)

**Date:** Mon Aug 24 2015 - 10:49:46 CDT

**Next message:**Tristan Croll: "Re: VMD cannot display electron density map"**Previous message:**John Stone: "Re: nvidia cuda mismatch"**In reply to:**Francesco Pietra: "Re: ffTK and geometry optimization level"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Francesco,

Although I routinely use Gaussian for parameterization, I am certainly not a full fledged expert. My best guess regarding the message:

" Would need an additional 807073191 words for in-memory AO integral storage."

is a warning that Gaussian will use disk swapping since there is insufficient memory. Typically when I've tried to use fragments that are too large and result in disk swapping for geometry optimiations, I've found that the Hessian and dihedral scan calculations take far too long, and it is worthwhile stepping back and considering an alternative fragmentation scheme. This doesn't necessarily explain the process termination without any error messages, for which I don't have any advice based on the information at hand.

Regards,

Christopher Mayne

On Aug 23, 2015, at 4:09 AM, Francesco Pietra wrote:

Chris:

Recalling that initially I carried out a successful geometry optimization

%chk=....chk

%nproc=16

%mem=120GB

# RHF/6-31G* Stable=Opt SCF=Tight Geom=PrintInputOrient

where the Stable=Opt avoided crashing because of unstable wavefunction,

before trying SFC/single-point MP2, I have now tried MP2 geometry optimization by also writing on disk

%chk=....chk

%nproc=16

%mem=120GB

# MP2/6-31G* maxdisk=900GB MP2=SemiDirect guess=read geom=checkpoint

The procedure went on a lot, to nearly discarding MO integrals, crashing without error messages as shown below:

JobTyp=2 Pass 1: I= 1 to 85.

(rs|ai) integrals will be sorted in core.

SymMOI: orbitals are not symmetric.

Spin components of T(2) and E(2):

alpha-alpha T2 = 0.1952657779D+00 E2= -0.6186401423D+00

alpha-beta T2 = 0.9897063485D+00 E2= -0.3241890891D+01

beta-beta T2 = 0.1941391244D+00 E2= -0.6171858226D+00

ANorm= 0.1542436790D+01

E2 = -0.4477716856D+01 EUMP2 = -0.18915535514164D+04

(S**2,0)= 0.49577D+00 (S**2,1)= 0.39665D+00

E(PUHF)= -0.18871168171D+04 E(PMP2)= -0.18915915926D+04

Would need an additional 807073191 words for in-memory AO integral storage.

DD1Dir will call FoFJK 6 times, MxPair= 3600

NAB= 7225 NAA= 3570 NBB= 3570 NumPrc= 16.

FoFJK: IHMeth= 1 ICntrl= 200 DoSepK=F KAlg= 0 I1Cent= 0 FoldK=F

IRaf= 990000000 NMat=3600 IRICut= 1297 DoRegI=F DoRafI=T ISym2E= 2.

E(PMP3)= -0.18916618537D+04

MP4(D)= -0.93363445D-01

MP4(S)= -0.58146163D-01

MP4(R+Q)= 0.84912525D-01

I do not understand whether " Would need an additional 807073191 words for in-memory AO integral storage." is a normal messages or it implies that the scratch disk could not be used to this purpose for these few words (ca 6GB). Or crashing occurred for a different reason. I did not repear :Stable=Opt" for the MP2 procedure.

Although not a good excuse, I know Gaussian little, having always used gamess-us (in this case I could have used many nodes with OpenMPI compiled gamess-us)

thanks a lot

francesco

On Thu, Aug 20, 2015 at 8:09 PM, Mayne, Christopher G <cmayne2_at_illinois.edu<mailto:cmayne2_at_illinois.edu>> wrote:

Francesco,

There are two places in the workflow where substituting MP2 geometry optimization with SCP opt + MP2 single point would matter: determining a low energy conformation of the molecule, and as input for the Hessian calculation, which I'll deal with in order. Technically speaking, the ffTK parser should handle the change in theory without a problem. You can check this by loading the optimization log and checking that VMD reads in multiple conformations into the OpenGL window. From a theoretical perspective, as long as the resulting geometry is of sufficient energy it should suffice for use in subsequent steps in the workflow, e.g., water interaction profiles. Whether this works with the Hessian calculation is less clear to me a priori, and may work for some cases but not others. The input file for the Hessian calculations tells Gaussian to read the initial coordinates from the checkpoint file output during the geometry optimization. I could imagine that an SCP-computed geometry minimum may differ from MP2 such that you would end up with problems in the frequencies. I would have to run test cases to say much more. Alternatively, if you think you have sufficient justification, you could perform all calculations as the SCP level of theory, and the ffTK parsers should continue to work (fingers crossed!).

Regards,

Christopher Mayne

On Aug 20, 2015, at 12:50 PM, Francesco Pietra wrote:

Hi Chris:

Sorry for having missed your answer. I also came across those suggestions by Gaussian, but that was not the reason. As I said it was lack of sufficient memory.

I still have to become comfortable with "divide and conquer". As it is implied in your answer that it is of such accuracy as to demand OPT/MP2, I'll try to learn how to do.

At any event, would ffTK accept the Gaussian log file from geometry optimization at SCF level, followed by single-point MP2? Or is ffTK expecting a log for geometry optimization at MP2 level?

Thanks a lot

francesco

On Thu, Aug 20, 2015 at 7:23 PM, Mayne, Christopher G <cmayne2_at_illinois.edu<mailto:cmayne2_at_illinois.edu>> wrote:

Francesco,

I responded here: http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/26205.html

On Aug 20, 2015, at 10:13 AM, Francesco Pietra wrote:

Thanks a lot for advice on strategy.

**Next message:**Tristan Croll: "Re: VMD cannot display electron density map"**Previous message:**John Stone: "Re: nvidia cuda mismatch"**In reply to:**Francesco Pietra: "Re: ffTK and geometry optimization level"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]