Excuse my absence from the mailing list for a while.
For 'maxcyc=0' or 'nstlim=0', a single point energy calculations without gradients will be done.
All the best,
Andy
On May 15, 2012, at 2:03 AM, Marc van der Kamp wrote:
> OK, I got fort.7 to be written now, when using g09.
>
> There was an issue with my environment setup, which caused executing "g09 "
> on the command-line to actually run g03 (/share/apps//g03/l1.exe).
>
> After solving that, it turned out that when I ran g09 (properly), fort.7
> was written.
> So *I think* this issue is solved now.
>
> My question about a 'true' single-point QM/MM energy calculation still
> stands, though. But this may be difficult with the current sander-code, as
> I think people typically do a minimization with maxcyc=1 to get
> single-point energies. In this case, one would be calculating gradients as
> well, of course.
>
> Thanks,
> Marc
>
> On 15 May 2012 09:36, Marc van der Kamp <marcvanderkamp.gmail.com> wrote:
>
>> Hi again,
>>
>> Thanks for the reply.
>> I ran gaussian (g03 and g09) with the gau_job.inp input file in
>> $AMBERHOME/test/qmmm_EXTERN/pure_QM_MD_GAUSSIAN
>> The only files that are created are gau_job.log and gau_job.chk, with
>> gau_job.log terminating normally.
>> fort.7 is not created.
>>
>> Should the gau_job.log say anything about dumping the gradients?
>>
>> In my standard environment, GAUSS_SCRDIR=/tmp
>> I changed this to the working directory
>> ($AMBERHOME//test/qmmm_EXTERN/pure_QM_MD_GAUSSIAN), in case the fort.7 file
>> would be written to GAUSS_SCRDIR, but this didn't make a difference.
>>
>> I've also verified with our sysadmin that our g03 and g09 binaries are
>> standard binaries.
>>
>> Any further thoughts on what may be happening / how to fix this?
>>
>> As a side-question: would it be possible to do a true single-point energy
>> calculation with AMBER/Gaussian, i.e. without needing to get the gradients?
>> If so, how?
>>
>> Thanks,
>> Marc
>>
>>
>> On 14 May 2012 20:52, Andreas Goetz <agoetz.sdsc.edu> wrote:
>>
>>> I have relied on Gaussian's manual when implementing this:
>>> http://www.gaussian.com/g_tech/g_ur/k_punch.htm
>>>
>>> The input file that the interface to Gaussian creates (gau_job.inp)
>>> contains "Punch=Derivatives" in the route section. According to Gaussian
>>> this should dump gradients to fort.7. Can you run Gaussian with this input
>>> file and check any files that are created? Are you aware of any
>>> modifications during the Gaussian installation?
>>>
>>> All the best,
>>> Andy
>>>
>>> PS: I am on travel this week and might not respond immediately to email.
>>>
>>> On May 14, 2012, at 12:41 PM, Jason Swails wrote:
>>>
>>>> So what is happening here is that fort.7 is not being written but
>>> sander expects it there.
>>>>
>>>> The implementors will have to look into this now, but any info you can
>>> give to help them reproduce the issue would probably help them.
>>>>
>>>> --
>>>> Jason M. Swails
>>>> Quantum Theory Project,
>>>> University of Florida
>>>> Ph.D. Candidate
>>>> 352-392-4032
>>>>
>>>> On May 14, 2012, at 9:39 AM, Marc van der Kamp <
>>> marcvanderkamp.gmail.com> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> Thanks for the reply - I made the change and recompiled.
>>>>> I don't get an error message about fort.7 not existing, but the job
>>> stops
>>>>> (abruptly) after writing:
>>>>>
>>> --------------------------------------------------------------------------------
>>>>> 4. RESULTS
>>>>>
>>> --------------------------------------------------------------------------------
>>>>>
>>>>> Again, gau_job.log is present and shows that Gaussian
>>>>> has successfully finished.
>>>>> The fort.7 file is not present this time (which makes sense), but the
>>>>> underlying problem still persists, it appears.
>>>>> Again, this is the case for tests in:
>>>>> AMBERHOME/test/qmmm_EXTERN/QMMM_MD_GAUSSIAN
>>>>> AMBERHOME/test/qmmm_EXTERN/pure_QM_MD_GAUSSIAN/
>>>>>
>>>>> Thanks,
>>>>> Marc
>>>>>
>>>>>
>>>>> On 14 May 2012 14:12, Jason Swails <jason.swails.gmail.com> wrote:
>>>>>
>>>>>> The problem seems to be that the Amber/Gaussian interface depends on
>>> all of
>>>>>> the gradient information being dumped to the file "fort.7", which it
>>> claims
>>>>>> will always exist. However, I'm skeptical that this is always true.
>>>>>>
>>>>>> Can you modify the source code and change line 600 of the file
>>>>>> qm2_extern_gau_module.F90 (in $AMBERHOME/src/sander) from
>>>>>>
>>>>>> open(iunit, file=fortfile) !Will always exist
>>>>>>
>>>>>> to
>>>>>>
>>>>>> open(iunit, file=fortfile, status='old') !Will always exist
>>>>>>
>>>>>> This way, if the file doesn't exist, it will bomb out rather than
>>> create
>>>>>> the file and then immediately fail to parse it. (Really, I think all
>>> of
>>>>>> the file opening in the external module should use the amopen()
>>> wrapper
>>>>>> rather than calling "open" directly, since it standardizes most of
>>> this
>>>>>> behavior).
>>>>>>
>>>>>> After you do this (and recompile), do you get an error message about
>>> fort.7
>>>>>> not existing?
>>>>>>
>>>>>> Thanks!
>>>>>> Jason
>>>>>>
>>>>>> On Mon, May 14, 2012 at 12:58 AM, Marc van der Kamp <
>>>>>> marcvanderkamp.gmail.com> wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I have installed AMBER12 a little while ago, with gnu compilers gcc
>>> 4.1.2
>>>>>>> and gfortran 4.1.2 (on a cluster running Rocks 5.3, equivalent to
>>> Red Hat
>>>>>>> 4.1.2-50).
>>>>>>>
>>>>>>> I would like to try out AMBER/Gaussian, and we have g09 as well as
>>> g03.
>>>>>>> I run into problems when running the tests in
>>>>>>> $AMBERHOME/test/qmmm_EXTERN/QMMM_MD_GAUSSIAN.
>>>>>>> According to the mdout, Gaussian is found (in this case g09), but
>>> sander
>>>>>>> fails with the following:
>>>>>>>
>>>>>>> SANDER BOMB in subroutine read_results (qm2_extern_gau_module)
>>>>>>> Error reading file fort.7
>>>>>>> Will quit now
>>>>>>>
>>>>>>> gau_job.log is present and shows that Gaussian has successfully
>>> finished.
>>>>>>> The fort.7 file in the directory is empty, so it is not a surprise
>>> that
>>>>>> the
>>>>>>> job fails.
>>>>>>> But I don't know how to proceed to fix this. Any help is appreciated!
>>>>>>>
>>>>>>> BTW, the same error occurs when using g03 and in the
>>> pure_QM_MD_GAUSSIAN/
>>>>>>> tests.
>>>>>>>
>>>>>>> Many thanks,
>>>>>>> Marc
>>>>>>> _______________________________________________
>>>>>>> AMBER mailing list
>>>>>>> AMBER.ambermd.org
>>>>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason M. Swails
>>>>>> Quantum Theory Project,
>>>>>> University of Florida
>>>>>> Ph.D. Candidate
>>>>>> 352-392-4032
>>>>>> _______________________________________________
>>>>>> AMBER mailing list
>>>>>> AMBER.ambermd.org
>>>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>>>
>>>>> _______________________________________________
>>>>> AMBER mailing list
>>>>> AMBER.ambermd.org
>>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>> --
>>> Dr. Andreas W. Goetz
>>> Assistant Project Scientist
>>> San Diego Supercomputer Center
>>> Tel : +1-858-822-4771
>>> Email: agoetz.sdsc.edu
>>> Web : www.awgoetz.de
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
Dr. Andreas W. Goetz
Assistant Project Scientist
San Diego Supercomputer Center
Tel : +1-858-822-4771
Email: agoetz.sdsc.edu
Web : www.awgoetz.de
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Jul 22 2012 - 14:30:02 PDT
