Re: Re: Charm++ fatal error with QM-MM MOPAC

From: Marcelo C. R. Melo (melomcr_at_gmail.com)
Date: Tue Jan 17 2017 - 15:52:04 CST

Hi,

MOPAC output always contains the input parsing, and your output file tells
me that 75 atoms were sent to MOPAC and all were recognized from the input
file NAMD wrote (with their element names and positions).
This doesn't seem to be a problem with NAMD's interface. MOPAC itself
cannot calculate the energies and gradients, so there must be an issue with
the MOPAC keyword selection and/or the system selection.

Regarding keywords, you should try separating the portion of the system you
want in the QM region (the ~75 atoms) and run it directly in MOPAC to fine
tune the method and parameter selection.

Regarding the system, if the QM/MM example ran correctly (as you previously
mentioned), you should be using the same provided tcl script (adapted to
your atom selection, of course) to make sure that any QM-MM bonds are
assigned correctly, and that element types are written in the PDB file (as
they seem to be, since MOPAC read all of them correctly).

Best,
Marcelo

---
Marcelo Cardoso dos Reis Melo
PhD Candidate
Luthey-Schulten Group
University of Illinois at Urbana-Champaign
crdsdsr2_at_illinois.edu
+1 (217) 244-5983
On 17 January 2017 at 09:16, Francesco Pietra <chiendarret_at_gmail.com> wrote:
> Hi Marcelo:
>
> Answering previous remarks:
> --- Same qmBaseDir with my runs relates to runs on different computers or
> at different times.
> ---For all these QM-MM simulations I use for Fe(II) the simple topology
> and parameters provided by charmm36. Otherwise, for MD I use a much more
> complex model. There are other topologies and patches with these runs, they
> are OK for MD.
>
> As to present case: it was run again following your indications (at least
> I tried so). A third type of error came out:  FATAL ERROR: Error reading QM
> forces file.
>
> qmConfigLine    "PM7 XYZ T=2M 1SCF UHF SEPTET CUTOFF=9.0 AUX LET GRAD QMMM
> GEO-OK"
> qmConfigLine    "4UHX"
>
> The .aux file in attachment (I had to delete cc to namd because it did not
> accept the attachment)
>
> Thanks a lot for your advice
>
> francesco pietra
>
>
>
>
> On Mon, Jan 16, 2017 at 10:52 PM, Marcelo C. R. Melo <melomcr_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> The first point I want to make is that, when executing independent NAMD
>> QM/MM runs, make sure each one is using a different qmBaseDir, otherwise
>> different runs will read and write on the same folder, which could cause
>> all the issues you are experiencing right now. If you are not using
>> different folders in your simultaneous NAMD runs, try that now to see if it
>> solves your problem.
>>
>> To answer your questions, we have not tried open shell systems with
>> mopac. NAMD reads the gradient output that is written in the *.aux file
>> when MOPAC is selected. The keywords "GRAD" and "1SCF" should be placed in
>> the qmConfigLine so that one SCF calculation is done and so that the
>> gradients are always printed. The keyword "QMMM" will tell MOPAC to read
>> point charges from the classical system (which are written by NAMD) and the
>> keyword "AUX" makes sure the file *.aux is used to print the gradient
>> information. Make sure these keywords are always used. As for MOZYME, this
>> is indicated for biomolecules, along with "XYZ". There are several ways to
>> fine-tune and speed up your calculations with MOPAC, but you should refer
>> to their documentation <http://openmopac.net/manual/allkeys.html>for
>> that.
>>
>> The error NAMD is returning indicates that it either cannot find the
>> *.aux file (ERROR: Could not find QM output file!) or that the
>> calculation did not end properly and gradients were not written ( Not
>> all data could be read!).
>>
>> If the problem persists, could you provide the qmConfigLine you are
>> using? Also, the full output of your *.aux file?
>>
>> Best,
>> Marcelo
>>
>> ---
>> Marcelo Cardoso dos Reis Melo
>> PhD Candidate
>> Luthey-Schulten Group
>> University of Illinois at Urbana-Champaign
>> crdsdsr2_at_illinois.edu
>> +1 (217) 244-5983 <(217)%20244-5983>
>>
>> On 15 January 2017 at 01:55, Francesco Pietra <chiendarret_at_gmail.com>
>> wrote:
>>
>>> Hi Marcelo:
>>>
>>> As I wrote, MOPAC halted because MOZYME can't be used for open shell
>>> systems. Removing the key word MOZYME lets MOPAC2016 working correctly with
>>> open shell systems. Following the complex case of my first mail, I have now
>>> run a simpler system at either multiplicit 3 or 7. In both cases MOPAC
>>> ended without error messages. In the following read please abou the mult 7
>>> case from the /0 folder:
>>>
>>> From qmmm_0.input.ou
>>>>
>>>>  *                    *
>>>>  * JOB ENDED NORMALLY *
>>>>  *                    *
>>>>  **********************
>>>>
>>>>  TOTAL JOB TIME:            10.40 SECONDS
>>>>
>>>>  == MOPAC DONE ==
>>>>
>>>>
>>>
>>> From qmmm_0.input.aux:
>>> BETA_M.O.SYMMETRY_LABELS[0020]=
>>>  109A    110A    111A    112A    113A    114A    115A    116A    117A
>>> 118A
>>>  119A    120A    121A    122A    123A    124A    125A    126A    127A
>>> 128A
>>>  ALPHA_M.O.SYMMETRY_LABELS[0020]=
>>>  109A    110A    111A    112A    113A    114A    115A    116A    117A
>>> 118A
>>>  119A    120A    121A    122A    123A    124A    125A    126A    127A
>>> 128A
>>>  ALPHA_EIGENVALUES[0020]=
>>>     0.000    0.000    0.000    0.000    0.000    0.000    0.000
>>> 0.000    0.000    0.000
>>>     0.000    0.000    0.000    0.000    0.000    0.000    0.000
>>> 0.000    0.000    0.000
>>>  BETA_EIGENVALUES[0020]=
>>>       NaN      NaN      NaN      NaN      NaN      NaN      NaN
>>> NaN      NaN      NaN
>>>       NaN      NaN      NaN      NaN      NaN      NaN      NaN
>>> NaN      NaN      NaN
>>>  ALPHA_MOLECULAR_ORBITAL_OCCUPANCIES[00020]=
>>>  1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
>>>  BETA_MOLECULAR_ORBITAL_OCCUPANCIES[00020]=
>>>  1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>  CPU_TIME:SECONDS[1]=       10.40
>>>  CPU_TIME:ARBITRARY_UNITS[1]=       14.79
>>>  END OF MOPAC FILE
>>>
>>>
>>>  However, NAMD12 procedure stopped with error message
>>>
>>> TCL: Minimizing for 100 steps
>>>> Info: List of ranks running QM simulations: 0.
>>>>           Sat Jan 14 23:09:08 2017  Job: '/dev/shm/NAMD_4IEV/0/qmmm_0.input'
>>>> started successfully
>>>>
>>>>
>>>>           MOPAC Job: "/dev/shm/NAMD_4IEV/0/qmmm_0.input" ended
>>>> normally on Jan 14, 2017, at 23:09.
>>>>
>>>> FATAL ERROR: Error reading QM forces file. Not all data could be read!
>>>> ------------- Processor 0 Exiting: Called CmiAbort ------------
>>>> Reason: FATAL ERROR: Error reading QM forces file. Not all data could
>>>> be read!
>>>>
>>>
>>> May I ask whether you already applied NAM12-MOPAC to open shell system
>>> (probably not because of MOZYME). At any event, could you suggest how to
>>> set the system to have QM-MM running? As I asked initially, what does
>>> charmm++ expects to read? Forces in which format? Or the above charmm++
>>> message is a fake error message and the problem lies elsewhere?
>>>
>>> Thanks
>>>
>>> francesco pietra
>>>
>>> On Tue, Jan 10, 2017 at 3:11 PM, Marcelo C. R. Melo <melomcr_at_gmail.com>
>>> wrote:
>>>
>>>> Hello!
>>>>
>>>> In NAMD, the keyword qmMult is only used when building the input for
>>>> ORCA. When using MOPAC, all options and keywords are to be passed using the
>>>> qmConfigLine keyword.
>>>>
>>>> Without more information, it seems that MOPAC is not accepting the
>>>> requested spin-state. You could find more info in the output file inside
>>>> the execution folder:  "/dev/shm/NAMD_4ztt_C/0/"
>>>> MOPAC will print its standard output and errors in the file:
>>>> qmmm_0.input.aux
>>>>
>>>> There is nothing in NAMD that would check the options you passed in
>>>> qmConfigLine and prevent you from using UHF or RHF, so there must be a
>>>> conflict somewhere between the keywords and your specific system.
>>>>
>>>> I hope this could be of help,
>>>> Marcelo
>>>>
>>>> ---
>>>> Marcelo Cardoso dos Reis Melo
>>>> PhD Candidate
>>>> Luthey-Schulten Group
>>>> University of Illinois at Urbana-Champaign
>>>> crdsdsr2_at_illinois.edu
>>>> +1 (217) 244-5983 <(217)%20244-5983>
>>>>
>>>> On 10 January 2017 at 01:56, Francesco Pietra <chiendarret_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Hello:
>>>>>
>>>>> PROBLEM:
>>>>> I am trying to apply QM-MM with MOPAC2016 to a protein system with
>>>>> electron unpaired QM part. The procedure ends without errors by using the
>>>>> default configuration
>>>>>
>>>>> qmMult          "1 x"
>>>>>
>>>>>
>>>>> qmConfigLine    "PM7 XYZ T=2M 1SCF MOZYME CUTOFF=9.0 AUX LET GRAD QMMM
>>>>> GEO-OK"
>>>>>
>>>>> with "x" as the supposed total multiplicity (guessed in various modes,
>>>>> even by supposing that electrons from different unpaired species will get
>>>>> mixed). However any output from such a configugaration is highly suspicious
>>>>> to my eyes.
>>>>>
>>>>> I tried by inserting either "UHF" alone or "UHF MS=y" (with "y"
>>>>> representing the supposed multiplicity in MOPAC mode, commenting out, or
>>>>> not, the  "qmMult  "1 x"" line. UHF was made to replace 1SCF, or
>>>>> follow it .
>>>>>
>>>>> In all cases, I got the error
>>>>>
>>>>> MOPAC Job: "/dev/shm/NAMD_4ztt_C/0/qmmm_0.input" ended normally on
>>>>>> Jan  9, 2017, at 22:21.
>>>>>>
>>>>>> FATAL ERROR: Error reading QM forces file. Not all data could be read!
>>>>>> ------------- Processor 0 Exiting: Called CmiAbort ------------
>>>>>> Reason: FATAL ERROR: Error reading QM forces file. Not all data could
>>>>>> be read!
>>>>>>
>>>>>> Charm++ fatal error:
>>>>>> FATAL ERROR: Error reading QM forces file. Not all data could be read!
>>>>>>
>>>>>
>>>>> QUESTION:
>>>>> I would appreciate any indication where to look for  the QM forces
>>>>> file that CHARMM++ expects. Or any other suggestion that could allow
>>>>> running QM-MM/MOPAC under UHF.
>>>>>
>>>>> thanks
>>>>>
>>>>> francesco pietra
>>>>>
>>>>>
>>>>
>>>
>>
>

This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:01 CST