VMD-L Mailing List
From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Sun Aug 23 2015 - 04:09:15 CDT
Recalling that initially I carried out a successful geometry optimization
# 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
# 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
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)=
Would need an additional 807073191 words for in-memory AO integral
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.
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
thanks a lot
On Thu, Aug 20, 2015 at 8:09 PM, Mayne, Christopher G <cmayne2_at_illinois.edu>
> 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!).
> 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
> On Thu, Aug 20, 2015 at 7:23 PM, Mayne, Christopher G <
> cmayne2_at_illinois.edu> wrote:
>> I responded here:
>> MP2 is the level of theory prescribed by the CHARM General Force Field to
>> accurately describe the internal dynamics of molecule. Further, it is
>> generally accepted practice to take a "divide and conquer" approach to
>> parameterize large ligands.
>> Christopher Mayne
>> On Aug 20, 2015, at 10:13 AM, Francesco Pietra wrote:
>> I posted recently about ffTK OPT MP2 problems, no answer, however it
>> became clear that the shared memory on a node (120GB) was not enough, and
>> could not be increased. On the other hand, Gaussian is threaded, so that I
>> can't exploit the enormous resources of the cluster.
>> Therefore, my question is, is OPT at MP2 really needed for getting a good
>> ff for ligands along ffTK in the realm of classical MD? OPT at SCF level,
>> followed by single-point MP2 is not enough? I understand that it depends on
>> what one is looking for, from simple docking to normal mode calculations,
>> so that my question covers all situations.
>> If SCF followed by single-point MP2 is not enough, the only alternative
>> that I can see is to break the ligand into pieces and carry out OPT/MP2 on
>> each piece, allowing for the approximations in reforming the whole ligand.
>> Thanks a lot for advice on strategy.
>> francesco pietra