From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Mar 28 2019 - 09:51:27 CDT

Kelly,
  If you can send me both kinds of files, we should be able to make
the ORCA plugin tolerant of these minor variations in the output format.
The misbehavior you've seen is caused by bugs/limitations in the implementation
of the ORCA plugin that need to be fixed. Since the original author doesn't
have time to fix his code, we're trying to fix it ex post facto.

Not being an ORCA expert, it is helpful to me to have as many samples of
ORCA output to work with as possible, so if you can provide all of the inputs
that cause trouble, that'd be great!

Best,
  John Stone
  johns_at_ks.uiuc.edu

On Thu, Mar 21, 2019 at 10:34:38PM +0000, McGuire, Kelly wrote:
> Found the problem. Here is my input:
> !RI BP86 OPT def2-SVP def2/J NOSOSCF CPCM(Water) Grid5 NoFinalGrid EnGrad
> NormalSCF printbasis
> %output PrintLevel Mini Print[ P_Mulliken ] 1 Print[P_AtCharges_M] 1 end
> %output Print[ P_Basis ] 2 Print[ P_MOs ] 1 end
> %scf
> maxiter 2000
> shift shift 0.1 erroff 0 end
> damp fac 0.80 erroff 0.0001 end
> end
> Notice that I have printbasis in the input line and I have the output
> command (2nd line) with another print command. I think this was
> corrupting my output. After deleting printbasis from the input line, I
> can now open the ORCA output in VMD.
>
> Kelly L. McGuire
>
> PhD Candidate
>
> Biophysics
>
> Department of Physiology and Developmental Biology
>
> Brigham Young University
>
> LSB 3050
>
> Provo, UT 84602
>
> --------------------------------------------------------------------------
>
> From: Vermaas, Joshua <Joshua.Vermaas_at_nrel.gov>
> Sent: Thursday, March 21, 2019 3:41 PM
> To: McGuire, Kelly; vmd-l_at_ks.uiuc.edu
> Subject: RE: VMD OrcaPlugin Bug
>
> Oof. This isn't nessicarily a memory leak, but could just be memory being
> accessed before it is allocated. In any event, the stack trace seems to
> indicate that the offending code/input is somewhere in the close_orca_read
> function in the plugins/molfile_plugin/src directory. Its a new plugin, so
> I suspect that the range of attempted input didn't consider your input
> format.
>
> -Josh
>
>
>
> On 2019-03-21 14:10:50-06:00 owner-vmd-l_at_ks.uiuc.edu wrote:
>
> Sometimes, the console prints this out also:
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
> Abort
> So, it seems like a memory leak? The ORCA output is only 420 KB...
>
> Kelly L. McGuire
>
> PhD Candidate
>
> Biophysics
>
> Department of Physiology and Developmental Biology
>
> Brigham Young University
>
> LSB 3050
>
> Provo, UT 84602
>
> --------------------------------------------------------------------------
>
> From: owner-vmd-l_at_ks.uiuc.edu <owner-vmd-l_at_ks.uiuc.edu> on behalf of
> McGuire, Kelly <mcg05004_at_byui.edu>
> Sent: Thursday, March 21, 2019 12:49 PM
> To: vmd-l_at_ks.uiuc.edu
> Subject: vmd-l: VMD OrcaPlugin Bug
> I ran a QM (NOT QMMM) simulation on a small molecule, but tried to open
> the ORCA output in VMD 1.9.4a12 because I know this version of VMD can
> still open orbitals correctly. At least, I can open the ORACA orbitals
> from my QMMM simulations. But, with this QM simulation I get a
> segmentation fault and VMD crashes. I ran the debugger and then typed
> where. This is the result:
> (gdb) where
> #0 0x00007ffff05bd207 in raise () from /lib64/libc.so.6
> #1 0x00007ffff05be8f8 in abort () from /lib64/libc.so.6
> #2 0x00007ffff05ffd27 in __libc_message () from /lib64/libc.so.6
> #3 0x00007ffff0608489 in _int_free () from /lib64/libc.so.6
> #4 0x00007fff8d469cf5 in close_orca_read(void*) ()
> from
> /panfs/pan.fsl.byu.edu/scr/grp/busathlab/kmcguir2/m2drugsimulations/VMD194/vmd194a12/lib/vmd/plugins/LINUXAMD64/molfile/orcaplugin.so
> #5 0x0000000000839caf in MolFilePlugin::~MolFilePlugin() ()
> #6 0x000000000078875c in CoorPluginData::next(Molecule*) ()
> #7 0x000000000083013a in Molecule::prepare() ()
> #8 0x000000000078e6ec in Displayable::draw_prepare() ()
> #9 0x000000000078e716 in Displayable::draw_prepare() ()
> #10 0x000000000089d395 in Scene::prepare() ()
> #11 0x00000000008c8d71 in VMDApp::VMDupdate(int) ()
> #12 0x000000000
> I don't know what to make of this. I don't have the background to
> interpret the cause.
>
> Kelly L. McGuire
>
> PhD Candidate
>
> Biophysics
>
> Department of Physiology and Developmental Biology
>
> Brigham Young University
>
> LSB 3050
>
> Provo, UT 84602

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/