Question on stability, feature suggestion

Development
#1

Hi,

I’ve used Avogadro here and there because of its great interface. But, I
can’t rely upon it because it crashes for me all the time. Originally I
thought it was only with large models, but recently I’ve been playing with
models of less than 1000 atoms and it still happens. This is on Windows
7. I’ve scanned some of the recent threads and it looks like stability
issues in 1.1.0 are known. Which leads me to 2 questions:

Are the Linux versions more stable?
Is another release planned any time soon to address stability?

I love the interface - just want to be able to use it without constant fear
of losing my most recent changes in a crash.

On an unrelated note, one suggestion I have is to improve atom choice for
bonding. I find that I bind to the wrong atom fairly often (maybe it’s just
me!). Normally I bind to something which is behind the atom I intended, and
if the angle is bad, it can even be hard to see you made a mistake. I think
there are several ways to address this, such as:

  1. Make the “from” and “to” atom highlighting very obvious. Rather than
    just snapping the bond to the atom (which is hard to interpret with many
    atoms, and when there are atoms in front of, or behind, the atom of
    interest), make the atom change color, glow, dance… :wink:

  2. Have a preference for atoms that are in front. For example, if one atom
    partially occludes another atom, the atom in front gets some preference in
    the snap-to algorithm. If one atom totally occludes another atom, it is
    almost a certainty that the user means the atom in front. (Maybe the ideal
    algorithm takes into account how much overlap there is - but since these
    are rendering rather than model details, I’m not sure how available this
    information is). Yes, this would make it harder to bind to
    partially-occluded atoms, but how often is that really the intent? I tend
    to spin or zoom my model to make the atom(s) of interest very visible - but
    perhaps other people do not.

Thanks for a nice piece of software!
Sincerely,
James

#2

Hi James,

Just to address your comment about the Avogadro crashing, it’s a known
problem and is a prime motivator for a major rewrite of Avogadro that the
developers are currently undertaking.

You can read Marcus’ announcement about Avogadro2 in his mail to this list
on the 11th April:

http://sourceforge.net/mailarchive/forum.php?thread_name=CAEZy%3DVEhD4OKEPWyWgHnGkRZ%2B_m3t31R-2zmdtV2MaNZgWy%3DAQ%40mail.gmail.com&forum_name=avogadro-devel

This will bring in a large number of improvements and changes to the code,
but a major one will be that the crashing (usually caused by bugs in the
openbabel library crashing the whole app), should be a thing of the past.

In my experience the Linux versions tend to be less prone to crashing then
the Windows ones, so you might try the latest Avogadro and see if that
improves things for you until enough of the functionality has been ported
to Avogadro2 to make it usable for you.

Best wishes,

Jens

On 28 June 2013 18:42, James james@ryley.com wrote:

Hi,

I’ve used Avogadro here and there because of its great interface. But, I
can’t rely upon it because it crashes for me all the time. Originally I
thought it was only with large models, but recently I’ve been playing with
models of less than 1000 atoms and it still happens. This is on Windows
7. I’ve scanned some of the recent threads and it looks like stability
issues in 1.1.0 are known. Which leads me to 2 questions:

Are the Linux versions more stable?
Is another release planned any time soon to address stability?

I love the interface - just want to be able to use it without constant
fear of losing my most recent changes in a crash.

On an unrelated note, one suggestion I have is to improve atom choice for
bonding. I find that I bind to the wrong atom fairly often (maybe it’s just
me!). Normally I bind to something which is behind the atom I intended, and
if the angle is bad, it can even be hard to see you made a mistake. I think
there are several ways to address this, such as:

  1. Make the “from” and “to” atom highlighting very obvious. Rather than
    just snapping the bond to the atom (which is hard to interpret with many
    atoms, and when there are atoms in front of, or behind, the atom of
    interest), make the atom change color, glow, dance… :wink:

  2. Have a preference for atoms that are in front. For example, if one atom
    partially occludes another atom, the atom in front gets some preference in
    the snap-to algorithm. If one atom totally occludes another atom, it is
    almost a certainty that the user means the atom in front. (Maybe the ideal
    algorithm takes into account how much overlap there is - but since these
    are rendering rather than model details, I’m not sure how available this
    information is). Yes, this would make it harder to bind to
    partially-occluded atoms, but how often is that really the intent? I tend
    to spin or zoom my model to make the atom(s) of interest very visible - but
    perhaps other people do not.

Thanks for a nice piece of software!
Sincerely,
James

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

#3

On Fri, Jun 28, 2013 at 1:42 PM, James james@ryley.com wrote:

Hi,

I’ve used Avogadro here and there because of its great interface. But, I
can’t rely upon it because it crashes for me all the time. Originally I
thought it was only with large models, but recently I’ve been playing with
models of less than 1000 atoms and it still happens. This is on Windows 7.
I’ve scanned some of the recent threads and it looks like stability issues
in 1.1.0 are known. Which leads me to 2 questions:

Are the Linux versions more stable?
Is another release planned any time soon to address stability?

I compiled the 1.1.0 release on Windows 7 using a more recent version
of Qt, which I had hoped would help reduce the number of crashes on
Windows. We are aware of issues crashing, and as Jens pointed out this
is part of the motivation for Avogadro 2, along with a wish to scale
to larger systems and provide a more flexible and robust platform for
the future. I have not spent that much time tracking down the causes
of the crashes in 1.1.0 recently, although I was hoping to put
together a new release soon I am not sure it will improve the number
of crashes as it has not received much active development time (that I
am aware of).

I love the interface - just want to be able to use it without constant fear
of losing my most recent changes in a crash.

I agree, and that is a major reason I want us to be better as a
community. We had a few attempts to get rid of all of the crashers in
Avogadro before releasing 1.0. I am not sure how much time I will have
to focus in 1.1, but can say 2 is more stable (but with many features
currently missing - something we are working to address).

On an unrelated note, one suggestion I have is to improve atom choice for
bonding. I find that I bind to the wrong atom fairly often (maybe it’s just
me!). Normally I bind to something which is behind the atom I intended, and
if the angle is bad, it can even be hard to see you made a mistake. I think
there are several ways to address this, such as:

  1. Make the “from” and “to” atom highlighting very obvious. Rather than just
    snapping the bond to the atom (which is hard to interpret with many atoms,
    and when there are atoms in front of, or behind, the atom of interest), make
    the atom change color, glow, dance… :wink:

That sounds like a great idea, I will try to come up with something.
You can already see which atom we will snap to, but highlighting the
from and to shouldn’t be that difficult and would provide a really
nice visual cue.

  1. Have a preference for atoms that are in front. For example, if one atom
    partially occludes another atom, the atom in front gets some preference in
    the snap-to algorithm. If one atom totally occludes another atom, it is
    almost a certainty that the user means the atom in front. (Maybe the ideal
    algorithm takes into account how much overlap there is - but since these are
    rendering rather than model details, I’m not sure how available this
    information is). Yes, this would make it harder to bind to
    partially-occluded atoms, but how often is that really the intent? I tend to
    spin or zoom my model to make the atom(s) of interest very visible - but
    perhaps other people do not.

This might be a little tougher to implement, but I will see if I can
come up with anything. Thanks for the suggestions.

Thanks for a nice piece of software!

Thanks for the comments, and we are honestly working on crashing less
(and I fully appreciate your frustration and anxiety with crashes).

Marcus