bgj get scf method: error reading rtdb
Clicked A Few Times
1:57:04 PM PST - Tue, Dec 20th 2011
Hi,

I'm getting the error in the subject line; will send log file with echoed input deck upon request (I don't know if it's possible to attach files through this interface). I see the same problem from another user here from ~ June 1 2011, but no resolution posted. Some salient facts:

  • Running on Hopper @ NERSC (Cray XE6)

  • NWChem 6.0 (don't know what microversion)

  • Reading in vectors as initial guess, ~ 300 MB

  • Fresh start (i.e., "start" in input deck, no *.db is present in PERMANENT_DIR), so it's not tripping over an old mismatched db file.


    • Resolution?

    Thanks,
    Chris

Clicked A Few Times
4:39:47 PM PST - Thu, Dec 22nd 2011
Please post more information about the error

Clicked A Few Times
2:07:54 PM PST - Fri, Dec 23rd 2011
Here's as much information as the application provides via print high in the qmmm block:
...{regular output}
 Nuclear repulsion energy =    116449.2515172895
 Bq nuclear interaction energy =    96.77135125975742
   Time after variat. SCF:     67.8
   Time prior to 1st pass:     70.1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
  current input line :
     0:
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 ------------------------------------------------------------------------
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
  current input line :
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
 bgj_get_scf_method: error reading rtdb        1
 bgj_get_scf_method: error reading rtdb        1
 ------------------------------------------------------------------------
...

 An error occured in the Runtime Database

...
12:12:bgj_get_scf_method: error reading rtdb:: 1
18:18:bgj_get_scf_method: error reading rtdb:: 1
Application 4856404 exit codes: 134
Application 4856404 exit signals: Killed
Application 4856404 resources: utime ~390s, stime ~15s


INPUT:
start CpI_OOR_OOO_QMMM
memory global 500 mb heap 10 mb stack 1500 mb
permanent_dir /scratch/scratchdirs/cchang/HRHERTFN8g6tWCqK_1/perm
scratch_dir /scratch/scratchdirs/cchang/HRHERTFN8g6tWCqK_1/scr
print medium
ECHO

title "QMMM of large-QM section including HYDHAB"

basis
   * library "Ahlrichs_pVDZ"
end

dft
ODFT; MULT 37; XC b3lyp
   iterations 200;
   vectors input e9reordered_to_QMMM.movecs output HRHERTFN8g6tWCqK_1.movecs
   incore noio nodisk
end

charge -5

md
   system CpI
   msa 5000
end

qmmm
   eref 0.0
   bqzone 9.0
   mm_charges linkbond
   link_atoms hydrogen
   link_ecp auto
   print high
end

task qmmm dft energy

Thanks

Clicked A Few Times
2:11:06 PM PST - Tue, Jan 3rd 2012
Marat--here is select octaldump output from the database that is produced, including flanking date delimiters:
2645400   s nul   u etx nul nul soh nul nul nul   T   u   e  sp   D   e
2645420   c  sp   2   0  sp   1   2   :   5   0   :   2   4  sp   2   0
2645440   1   1  nl nul del del  cr nul nul nul  bs nul nul nul soh nul
2645460 nul nul   b   g   j   :   s   c   f   _   t   y   p   e nul stx
2645500 nul nul nul nul nul nul nul dc3 nul nul nul   $ nul nul nul soh
2645520 nul nul nul   !   r   t   d   b   !   b   g   j   :   s   c   f
2645540   _   t   y   p   e nul   r etx nul nul soh nul nul nul   T   u
2645560   e  sp   D   e   c  sp   2   0  sp   1   2   :   5   0   :   2
2645600   4  sp   2   0   1   1  nl nul del del  ff nul nul nul eot nul

I see that later in the file, "scf:scf_type" is set to "UHF"; is bgj:scf_type supposed to carry a similar value? What does the "bgj" prefix signify?
Does "bgj_get_scf_method" pick up any information from the MO vector data that is read in? I reorder the MOs from a QM job to create the initial guess for the QMMM job, so it's possible that the input MO file is corrupted somewhere; however, reading them in seems to finish OK, but the (new, not from previous job) RTDB is corrupted:
 Loading old vectors from job with title :

HYDB, HYDHA, bound peptides, +LTTAMF

 Nuclear repulsion energy =    116449.2515172895
 Bq nuclear interaction energy =    96.77135125975742
   Time after variat. SCF:     65.9
   Time prior to 1st pass:     68.8
 bgj_get_scf_method: error reading rtdb        1

Clicked A Few Times
2:23:48 PM PST - Wed, Jan 4th 2012
It seems like the only values that get written into the RTDB for "bgj:scf_type" are "1" for HF, or "2" for DFT:
[cchang@rrlogin1 src]$ grep -R 'bgj:scf_type' *
ddscf/scf.F:      if (.not. rtdb_put(rtdb, 'bgj:scf_type', MT_INT, 1, 1))
ddscf/scf.F:     $     call errquit('scf: put of bgj:scf_type failed',0, RTDB_ERR)
etrans/et_fock.F:      if (.not. rtdb_put(rtdb,'bgj:scf_type',mt_int,1, itype)) then
mcscf/mcscf.F:      if (.not. rtdb_put(rtdb, 'bgj:scf_type', MT_INT, 1, 1))
mcscf/mcscf.F:     $     call errquit('mcscf: put of bgj:scf_type failed',0,
nwdft/scf_dft/dft_scf.F:      if (.not. rtdb_put(rtdb, 'bgj:scf_type', MT_INT, 1, 2))
nwdft/scf_dft/dft_scf.F:     $     call errquit('dft_scf: put of bgj:scf_type failed',0,
nwdft/so_dft/dft_scf_so.F:      if (.not. rtdb_put(rtdb, 'bgj:scf_type', MT_INT, 1, 2))
nwdft/so_dft/dft_scf_so.F:     $     call errquit('dft_scf_so: put of bgj:scf_type failed',0,
util/bgj.F:      if (.not. rtdb_get(bgj_rtdb, 'bgj:scf_type', mt_int,

I don't see either a 1-byte char or a 4-byte int for "1" or "2" in the RTDB for this key. Two quick questions:
  1. Are integer values written to the RTDB as strings (where I'd expect 1 byte with an octal 061 for ASCII "1"), or as 4-byte ints? The rtdb_put routine treats the value as an MT_INT, but I don't know how the database writes might convert types.

  2. If a hybrid functional is being used, util/bgj.F seems to allow for a RTDB entry of "3" for bgj:scf_type. However, there doesn't seem to be a routine in NWChem to put a "3", and the electron transfer code (which I'm working toward using) wouldn't work with it anyway. BUT, if I'm using a hybrid functional and wanted to try hacking the RTDB just to get past this error, should I try dropping a "2" or a "3" in?

Clicked A Few Times
5:07:21 PM PST - Wed, Jan 4th 2012
Debug output
...
4334       0.00026     0.00072     0.00007
4335       0.00001     0.00007     0.00011

     <<<<<<    Before call to fock_2e.    >>>>>>
     <<<<<< date:  Jan  4  time: 16:01:43 >>>>>>

 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 *** fock_2e: xc_active   F
 bgj_get_scf_method: error reading rtdb        1

Clicked A Few Times
3:52:31 PM PST - Fri, Jan 6th 2012
Unless you are generating "funny" structure from the definition of the QM region, the problem is not really in the QM/MM interface but likely to be in the QM part of the code. To narrow it down, I suggest that
1) you run pure gas phase calculation on your QM region and see if the problem persists
2) check if it is Hopper specific?
3) try default atomic guess instead of your MO data

  • Guest -
4:47:20 PM PST - Fri, Jan 6th 2012
Hi Marat,

Thanks for the guidance. To address the 3 points:
  1. This was how I generated the MO guess. The debug output does indeed suggest to me (naively, judging only by subroutine name) that whatever inconsistency is there first gets found in an QM routine; however, the QM with B3LYP runs fine, and the problem only crops up when I try to run the QMMM. So, the problem doesn't persist in the QM-only runs, so my suspicion was that something occurs in the QMMM setup that is incompatible with what I've tried to do in the QM, e.g., hybrid functionals can't be used or something like that.

  2. I'll give it a go on another machine.

  3. I see your point, for troubleshooting I'll give this a try. For production, though, the reason I needed to get an MO input guess from gas-phase QM calculations is that convergence from a simple guess is not going to happen. Lots of transition metals, I even had trouble getting the fragments to converge.

The structure is from a classical MM minimization of the protein. There's nothing funny in the sense of abnormal internal coordinates. The QM region comprises several disjoint peptides and 3 metalloclusters. To get fragment guessing to work, I did need to rearrange the atoms from the prepare order, get the MOs, arrange the atoms back to QMMM order and shuffle the MO coefficients to reflect this, but it doesn't seem the MO reading is a problem.
I'll let you know how tests 2 and 3 above go.

  • Guest -
10:41:07 AM PST - Mon, Jan 9th 2012
To follow up on #1. What I meant there was to take QM geometry as it is generated now in the failed run (it should be written out there somewhere) and run it through exactly the same input file but with QM/MM keywords removed. This is will ensure that we have near mirror copy of what you trying to run but with QM/MM layer removed. Perhaps, this is what you have already done.

Also at this point let us take this offline to direct email interaction. I will post back here once the problem is resolved

Marat


Forum >> NWChem's corner >> QMMM