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