[XtalOpt-devel] restarting xtalopt run on another computer
Cohen, Ron
rcohen at carnegiescience.edu
Fri Jul 19 06:59:49 PDT 2013
It works fine with obabel:
cohen at edison:~$ obabel -i pwscf
/home/rcohen/XtalOpt/PT/x20d/out//00001x00001//xtal.out -o cif -Oxtal.cif
==============================
*** Open Babel Error in RegisterOptionParam
The number of parameters needed by option "a" in API differs from an
earlier registration.
1 molecule converted
rcohen at edison:~$ less xtal.cif
And also works with avogadro.
Ron
On Fri, Jul 19, 2013 at 9:46 AM, David Lonie <loniedavid at gmail.com> wrote:
> cc'ing the list....
>
> On Fri, Jul 19, 2013 at 9:45 AM, David Lonie <loniedavid at gmail.com> wrote:
> > Hmm, does the referenced xtal.out file open ok in Avogadro? It looks
> > like there's an issue converting the OpenBabel data structure into the
> > XtalOpt structure (maybe the new computer has a different version of
> > OpenBabel?). It's failing at the line 497 in
> > src/globalsearch/optimizer.cpp:
> >
> > while (structure->numAtoms() < obmol.NumAtoms())
> > structure->addAtom();
> > while (structure->numAtoms() > obmol.NumAtoms())
> > structure->removeAtom(structure->atoms().last()); // Failing here
> >
> > Try changing the second loop from
> >
> > while (structure->numAtoms() > obmol.NumAtoms())
> >
> > to
> >
> > while (structure->numAtoms() > obmol.NumAtoms() &&
> > !structure->atoms.empty())
> >
> > and see if that fixes it. My guess is that is won't crash, but you'll
> > end up with an empty structure.
> >
> > Dave
> >
> > On Fri, Jul 19, 2013 at 9:00 AM, Cohen, Ron <rcohen at carnegiescience.edu>
> wrote:
> >> Here is the full trace. The filename for the structure file mentioned
> exists
> >> and seems OK.
> >> rw-r--r-- 1 rcohen users 241207 Jun 20 15:55
> >> /home/rcohen/XtalOpt/PT/x20d/out//00001x00001//xtal.out
> >>
> >>
> >>
> >>
> >> On Fri, Jul 19, 2013 at 8:51 AM, Cohen, Ron <rcohen at carnegiescience.edu
> >
> >> wrote:
> >>>
> >>> SOrry that had a lot of garbage. Here it is again. Ron
> >>>
> >>>
> >>>
> >>> On Fri, Jul 19, 2013 at 8:49 AM, Cohen, Ron <
> rcohen at carnegiescience.edu>
> >>> wrote:
> >>>>
> >>>> OK--thanks! Here it is:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jul 19, 2013 at 7:40 AM, David Lonie <loniedavid at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Oops -- my mistake. The command I'm thinking of is 'thread apply all
> >>>>> backtrace' :)
> >>>>>
> >>>>> Dave
> >>>>>
> >>>>> On Thu, Jul 18, 2013 at 4:59 PM, Cohen, Ron <
> rcohen at carnegiescience.edu>
> >>>>> wrote:
> >>>>> > Dear David,
> >>>>> >
> >>>>> > I must have a different gdb--doesn't have that command. According
> to
> >>>>> > the
> >>>>> > help, backtrace I used gives for all open threads:
> >>>>> >
> >>>>> > (gdb) apply all thread backtrace'
> >>>>> > Undefined command: "apply". Try "help".
> >>>>> >
> >>>>> >
> >>>>> > gdb) help backtrace
> >>>>> > Print backtrace of all stack frames, or innermost COUNT frames.
> >>>>> > With a negative argument, print outermost -COUNT frames.
> >>>>> > Use of the 'full' qualifier also prints the values of the local
> >>>>> > variables.
> >>>>> >
> >>>>> > I am running out now and then traveling- -probably won't get back
> >>>>> > online
> >>>>> > until tomorrow.
> >>>>> >
> >>>>> > Thanks!
> >>>>> >
> >>>>> > Ron
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > On Thu, Jul 18, 2013 at 4:53 PM, David Lonie <loniedavid at gmail.com
> >
> >>>>> > wrote:
> >>>>> >>
> >>>>> >> Can you send the 'apply all thread backtrace' output? That will
> give
> >>>>> >> backtraces for all open threads. It does look like it's crashing
> in a
> >>>>> >> background thread...
> >>>>> >>
> >>>>> >> On Thu, Jul 18, 2013 at 4:21 PM, Cohen, Ron
> >>>>> >> <rcohen at carnegiescience.edu>
> >>>>> >> wrote:
> >>>>> >> > Not sure. Here is info threads. Could it be the node_copy?
> >>>>> >> >
> >>>>> >> > Ron
> >>>>> >> >
> >>>>> >> > info threads
> >>>>> >> > Id Target Id Frame
> >>>>> >> > 8 Thread 0x7fffb37fe700 (LWP 19854) "avogadro"
> >>>>> >> > 0x00007ffff7b03313
> >>>>> >> > in
> >>>>> >> > poll
> >>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> > 7 Thread 0x7fffb3fff700 (LWP 19853) "avogadro"
> >>>>> >> > 0x00007fffd10d5f7c in QList<Avogadro::Atom*>::node_copy (
> >>>>> >> > this=0x7fffb3ffe330, from=0x7fffac16f7d0, to=0x7ffff661697b,
> >>>>> >> > src=0x0)
> >>>>> >> > at /usr/include/qt4/QtCore/qlist.h:393
> >>>>> >> > 4 Thread 0x7fffc246c700 (LWP 19850) "avogadro"
> >>>>> >> > 0x00007ffff7b03313
> >>>>> >> > in
> >>>>> >> > poll
> >>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> > 3 Thread 0x7fffe710c700 (LWP 19841) "gdbus"
> 0x00007ffff7b03313
> >>>>> >> > in
> >>>>> >> > poll
> >>>>> >> > ()
> >>>>> >> > from /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> > 2 Thread 0x7fffe790d700 (LWP 19839) "dconf worker"
> >>>>> >> > 0x00007ffff7b03313
> >>>>> >> > in poll () from /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> > * 1 Thread 0x7ffff7fc87c0 (LWP 19835) "avogadro"
> >>>>> >> > 0x00007ffff7b03313
> >>>>> >> > in
> >>>>> >> > poll
> >>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> > (gdb)
> >>>>> >> >
> >>>>> >> >
> >>>>> >> >
> >>>>> >> > On Thu, Jul 18, 2013 at 4:20 PM, Cohen, Ron
> >>>>> >> > <rcohen at carnegiescience.edu>
> >>>>> >> > wrote:
> >>>>> >> >>
> >>>>> >> >> Sorry it took me so long to do this (been having other
> problems!)
> >>>>> >> >> This
> >>>>> >> >> is
> >>>>> >> >> the backtrace:
> >>>>> >> >>
> >>>>> >> >> gdb) backtrace
> >>>>> >> >> #0 0x00007ffff7b03313 in poll () from
> >>>>> >> >> /lib/x86_64-linux-gnu/libc.so.6
> >>>>> >> >> #1 0x00007ffff400d036 in ?? () from
> >>>>> >> >> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> >>>>> >> >> #2 0x00007ffff400d164 in g_main_context_iteration ()
> >>>>> >> >> from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> >>>>> >> >> #3 0x00007ffff67273bf in
> >>>>> >> >>
> >>>>> >> >>
> >>>>> >> >>
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> >>>>> >> >> () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> >>>>> >> >> #4 0x00007ffff6cc2d5e in ?? () from
> >>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4
> >>>>> >> >> #5 0x00007ffff66f6c82 in
> >>>>> >> >>
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> >>>>> >> >> ()
> >>>>> >> >> from
> >>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> >>>>> >> >> #6 0x00007ffff66f6ed7 in
> >>>>> >> >> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> >>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> >>>>> >> >> #7 0x00007ffff66fbf67 in QCoreApplication::exec() ()
> >>>>> >> >> from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> >>>>> >> >> #8 0x000000000041f2bc in main (argc=1, argv=<optimized out>)
> >>>>> >> >> at /home/rcohen/SRC/avogadro/avogadro/src/main.cpp:251
> >>>>> >> >>
> >>>>> >> >> Seems like it is hung in Qt--is that what you wold say?
> >>>>> >> >>
> >>>>> >> >> Ron
> >>>>> >> >>
> >>>>> >> >>
> >>>>> >> >>
> >>>>> >> >> On Fri, Jun 21, 2013 at 12:58 PM, Cohen, Ron
> >>>>> >> >> <rcohen at carnegiescience.edu>
> >>>>> >> >> wrote:
> >>>>> >> >>>
> >>>>> >> >>> Thank you so much! Might not get to this until next week, but
> >>>>> >> >>> will do!
> >>>>> >> >>> Ron
> >>>>> >> >>>
> >>>>> >> >>>
> >>>>> >> >>>
> >>>>> >> >>> On Fri, Jun 21, 2013 at 12:56 PM, David Lonie
> >>>>> >> >>> <loniedavid at gmail.com>
> >>>>> >> >>> wrote:
> >>>>> >> >>>>
> >>>>> >> >>>> On Fri, Jun 21, 2013 at 12:46 PM, Cohen, Ron
> >>>>> >> >>>> <rcohen at carnegiescience.edu> wrote:
> >>>>> >> >>>> > Here is sample console output. It continues to make threads
> >>>>> >> >>>> > apparently
> >>>>> >> >>>> > but
> >>>>> >> >>>> > nothing else happens in the GUI:
> >>>>> >> >>>> >
> >>>>> >> >>>> > Debug: "Resuming XtalOpt session in
> >>>>> >> >>>> > '/home/rcohen/XtalOpt/PT/x20d/out/xtalopt.state' (PWscf)
> >>>>> >> >>>> > readOnly =
> >>>>> >> >>>> > false"
> >>>>> >> >>>> > Debug: "Loading structure
> >>>>> >> >>>> >
> /home/rcohen/XtalOpt/PT/x20d/out//00001x00001/structure.state"
> >>>>> >> >>>> > QObject: Cannot create children for a parent that is in a
> >>>>> >> >>>> > different
> >>>>> >> >>>> > thread.
> >>>>> >> >>>> > (Parent is XtalOpt::Xtal(0x7f0408054e60), parent's thread
> is
> >>>>> >> >>>> > QThread(0x9c4b90), current thread is QThread(0x1122110)
> >>>>> >> >>>> > QObject: Cannot create children for a parent that is in a
> >>>>> >> >>>> > different
> >>>>> >> >>>> > thread.
> >>>>> >> >>>> > (Parent is XtalOpt::Xtal(0x7f0408054e60), parent's thread
> is
> >>>>> >> >>>> > QThread(0x9c4b90), current thread is QThread(0x1122110)
> >>>>> >> >>>> > ...(many more of these)
> >>>>> >> >>>>
> >>>>> >> >>>> Strange...are you familiar with gdb? The next step to track
> this
> >>>>> >> >>>> down
> >>>>> >> >>>> would be to run avogadro in the gdb debugger and look at the
> >>>>> >> >>>> stack
> >>>>> >> >>>> when it hangs. Then we can figure out where things are going
> >>>>> >> >>>> wrong.
> >>>>> >> >>>>
> >>>>> >> >>>> In a nutshell:
> >>>>> >> >>>>
> >>>>> >> >>>> 0) Make sure XtalOpt is configured with
> CMAKE_BUILD_TYPE=Debug:
> >>>>> >> >>>>
> >>>>> >> >>>> cd /path/to/build/dir
> >>>>> >> >>>> cmake -DCMAKE_BUILD_TYPE=Debug .
> >>>>> >> >>>>
> >>>>> >> >>>> then build and install as usual.
> >>>>> >> >>>>
> >>>>> >> >>>> 1) Start gdb/avogadro
> >>>>> >> >>>>
> >>>>> >> >>>> gdb avogadro
> >>>>> >> >>>>
> >>>>> >> >>>> 2) Resume the session, wait for it to hang (avogadro may run
> >>>>> >> >>>> much
> >>>>> >> >>>> slower with gdb, this is normal).
> >>>>> >> >>>>
> >>>>> >> >>>> 3) Hit Ctrl-C in the terminal running gdb. This will
> interrupt
> >>>>> >> >>>> program
> >>>>> >> >>>> execution and let us poke around the execution state.
> >>>>> >> >>>>
> >>>>> >> >>>> 4) Type 'apply all thread backtrace' at the (gdb) prompt, hit
> >>>>> >> >>>> enter
> >>>>> >> >>>> to
> >>>>> >> >>>> page through the results if necessary.
> >>>>> >> >>>>
> >>>>> >> >>>> 5) Send me the output of the above command. That should help
> us
> >>>>> >> >>>> track
> >>>>> >> >>>> down where the issue lies.
> >>>>> >> >>>>
> >>>>> >> >>>> The gdb commands 'list' 's' (step into) 'n' (next/step over),
> >>>>> >> >>>> and 'c'
> >>>>> >> >>>> (continue execution) are helpful if you want to walk through
> the
> >>>>> >> >>>> instructions as they're executed. 'p' (print) is used to
> inspect
> >>>>> >> >>>> the
> >>>>> >> >>>> values of variables, which can be handy.
> >>>>> >> >>>>
> >>>>> >> >>>> Dae
> >>>>> >> >>>
> >>>>> >> >>>
> >>>>> >> >>
> >>>>> >> >
> >>>>> >
> >>>>> >
> >>>>
> >>>>
> >>>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmolecules.net/pipermail/xtalopt-devel-openmolecules.net/attachments/20130719/a5e7e991/attachment-0002.htm>
More information about the XtalOpt-Devel
mailing list