Hi all
Can Avogadro program build Gamess input files for ions?
Thanks very much
Best regards
Nagat
—254712680-811878827-1332781762=:95135
Content-Type: text/html; charset=us-ascii
| Thanks Geoff for fast reply. This information benefit me a lot. Thanks again Best regards Nagat --- On Mon, 3/26/12, Nagat Mohammed <nagat_mhd@yahoo.com> wrote:
|
Bugs item #1864085, was opened at 2008-01-04 09:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=1864085&group_id=165310
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Draw tool. Other atoms, several atoms wrong, no gold
Initial Comment:
In the table to select other atoms for the draw tool, there are several bugs. For example when gold is pressed the wrong atom is displayed.
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=835077&aid=1864085&group_id=165310
Hello!
I’ve committed my variant of cartesian editor to github.
Features:
It uses sophisticated algorithm to determine, in which columns of input data is stored. E.g, it can parse fragment of Molpro log file (in bohrs)
1 C1 6.00 -7.690050414 -1.478989491 -2.512493475
2 C2 6.00 -4.807343108 -1.405456059 -2.501667122
3 C3 6.00 -3.781056421 1.289135296 -2.503809792
4 H1 1.00 -8.395622720 -3.416268156 -2.511402816
5 H2 1.00 -8.445045121 -0.531800688 -4.183687642
6 H3 1.00 -8.458790097 -0.524291871 -0.852110061
7 H4 1.00 -4.084965041 -2.419982107 -4.149916634
8 H5 1.00 -4.097786164 -2.412407580 -0.843143812
9 H6 1.00 -4.418015134 2.319989776 -4.174375935
10 H7 1.00 -1.719515067 1.310225440 -2.496223226
11 H8 1.00 -4.430706296 2.327457980 -0.842706296
or this fragment of Gamess input, generated by Chemcraft program:
SELENIUM 34.0 0.000000000 0.000000000 -0.372797199
CARBON 6.0 0.000000000 1.444111800 0.933023896
CARBON 6.0 0.000000000 -1.444111800 0.933023896
HYDROGEN 1.0 0.894053954 1.389153226 1.552272006
HYDROGEN 1.0 0.894053954 -1.389153226 1.552272006
HYDROGEN 1.0 -0.894053954 1.389153226 1.552272006
HYDROGEN 1.0 -0.894053954 -1.389153226 1.552272006
HYDROGEN 1.0 0.000000000 2.381715250 0.379277826
HYDROGEN 1.0 0.000000000 -2.381715250 0.379277826
or fragment of mdl mol file:
0.6941 0.9985 0.8681 C 0 0 0 0 0 0 0 0 0
1.7568 1.9782 1.1864 C 0 0 0 0 0 0 0 0 0
3.0508 1.6797 1.1820 C 0 0 0 0 0 0 0 0 0
0.0000 0.8944 1.7128 H 0 0 0 0 0 0 0 0 0
0.1099 1.3323 0.0000 H 0 0 0 0 0 0 0 0 0
1.0889 0.0000 0.6381 H 0 0 0 0 0 0 0 0 0
1.4145 2.9905 1.4321 H 0 0 0 0 0 0 0 0 0
3.8210 2.4077 1.4170 H 0 0 0 0 0 0 0 0 0
3.4325 0.6904 0.9445 H 0 0 0 0 0 0 0 0 0
–
Regards,
Konstantin
Hi Konstantin,
That looks very nice! Can you reply with your git repos address?
Thanks,
Dave
Hi all,
I’m trying to include spglib space group identification in my xtalopt
extension, but there seem to be problems with linking libsymspg.so in.
I’ve attached both my CMakeList.txt and FindSpgLib061.cmake. I’m not
sure if this is a bug in the plugin code, or if I’m doing something
wrong (though it’s probably the latter 
).
After compiling a clean build with this cmake configuration, the code
executes until it reaches a call to spg_find_primitive(), at which
point I get the error:
symbol lookup error: /usr/lib/avogadro/contrib/xtalopt.so: undefined symbol: _Z18spg_find_primitivePA3_dS0_Piid
A couple notes about the CMake module:
Am I correct in thinking that this is a linking error? Does anyone see
any problems with my set up? I’ve had to make the xtalopt repo private
for the time being, but if anyone needs to see the full code let me know
and I’ll post a tarball somewhere.
As an aside, is it possible to display the full g++/gcc commands
during the make step (like with autotools)? I’d like to see if -lsymspg is even making it
into the compiler…
Thanks,
Dave
As an aside, is it possible to display the full g++/gcc commands
during the make step (like with autotools)? I’d like to see if -
lsymspg is even making it
into the compiler…
make VERBOSE=1
This is the first thing I’d do. It’s otherwise really hard to offer
you advice, since it seems like it should work, but you’ve got a
private repo.
Hope that helps,
-Geoff
David C. Lonie wrote:
From: Geoffrey Hutchison geoff.hutchison@gmail.com
Subject: Re: [Avogadro-devel] Linking problems in external plugins
Date: Sat, 31 Oct 2009 10:06:22 -0400As an aside, is it possible to display the full g++/gcc commands
during the make step (like with autotools)? I’d like to see if
-lsymspg is even making it
into the compiler…make VERBOSE=1
This is the first thing I’d do.
Ah, thanks
I can confirm that no, libsymspg.so is not getting
linked in. In my FindSpgLib061.cmake file I’ve set the LINK_LIBS
variable as Tim suggested, which should ensure that -lsymspg gets
added, AIUI.
It would be good to see the files, if you can get a copy of the build
files I will certainly take a quick look at them. Adding verbosity to
the make output is always a great first step, as they are the actual
commands being run to build/link.
It’s otherwise really hard to offer
you advice, since it seems like it should work, but you’ve got a
private repo.I know, it’s not my first choice, but there are reasons for it at the
moment. I can put a tarball up if anyone wants to see the rest of the
code, but it seems to me that the error would be isolated to these
cmake files.I’ve added target_link_libraries(xtalopt “symspg”) (shouldn’t setting
LINK_LIBS make this unnecessary?) after calling avogadro_plugin and it
is now getting linked in, but I’m still seeing the same error. Hrm…
Can you paste the errors here? Can you show me the relevant snippets of
the CMake files you have changed? It is possible the library is not
exporting its symbols correctly, I should be able to take a quick look
at it today (or more likely tomorrow).
Marcus
I apologize I didn’t reply to the earlier thread about “what should go
in each release.”
I respectfully disagree with the idea that 1.0.x is "just bug-fixes."
I think we have to be careful, but pragmatic. Introducing new plugins
(particularly new extensions) is not necessarily a bad thing. I think
it should be done on a case-by-case basis.
First off, just attempting to fix translations creates a large number
of new strings. And I just performed the obvious thing – removing
source files like pocketdialog and wiitrackextension which were being
picked up for string translation, but just aren’t used.
Secondly, we need to be pragmatic about timing. I think we made
releases too frequently in the beta series (i.e., monthly). So IMHO,
in the absence of a truly horrific bug (e.g., data loss, nasty crash,
security), we’ll probably make 1.0.x releases, every ~2 months?
So where does that leave 1.1.x and 1.2? Maybe 6-8 months from now?
We need a mechanism to incorporate new, stable plugins. As I said,
let’s discuss these on a case-by-case basis. They don’t break the
library API or ABI, but they can add nice feature for users.
Let’s take a few obvious cases:
So that leaves the Cartesian editor. Personally, I’d like to see some
improvements – can’t it still be a table embedded in a QDialog? I
like being able to sort by z-axis. I can imagine all the copy/paste
buttons would still work.
But even if the Cartesian editor is less of a “clear win,” I think
it’s something we should contemplate for 1.0.x. Otherwise, it might
not be incorporated until … March?
-Geoff
Hi,
04.11.09, 09:10, “Geoffrey Hutchison” geoff.hutchison@gmail.com:
So that leaves the Cartesian editor. Personally, I’d like to see some
improvements – can’t it still be a table embedded in a QDialog? I
like being able to sort by z-axis. I can imagine all the copy/paste
buttons would still work.
Regards,
Konstantin
I apologize I didn’t reply to the earlier thread about “what should go
in each release.”I respectfully disagree with the idea that 1.0.x is “just bug-fixes.”
I think we have to be careful, but pragmatic. Introducing new plugins
(particularly new extensions) is not necessarily a bad thing. I think
it should be done on a case-by-case basis.
I disagree with this approach, and do not see many other projects using
it. New extensions introduce new strings, and break any notion of a string
freeze to improve translation coverage. They also risk introducing new
compilation bugs, portability issues and UI changes that affect any
documentation for a given release. This creates headaches for packages,
and means that our patch releases are not just bug fix and so need to be
treated more carefully.
First off, just attempting to fix translations creates a large number
of new strings. And I just performed the obvious thing – removing
source files like pocketdialog and wiitrackextension which were being
picked up for string translation, but just aren’t used.
I am not sure what you mean here. If no new strings are introduced in a
stable branch, then the translation coverage will improve over time as
translators get time to work on it. There are numerous examples of
projects that support i18n and freeze their strings.
Secondly, we need to be pragmatic about timing. I think we made
releases too frequently in the beta series (i.e., monthly). So IMHO,
in the absence of a truly horrific bug (e.g., data loss, nasty crash,
security), we’ll probably make 1.0.x releases, every ~2 months?
In this case I think a 1.0.1 is called for, there are some compilation
bugs caused by the CMake file I mistakenly removed, several bugs that
caused crashes. In general I would be happy with a bug fix release every
2-3 months though.
So where does that leave 1.1.x and 1.2? Maybe 6-8 months from now?
We need a mechanism to incorporate new, stable plugins. As I said,
let’s discuss these on a case-by-case basis. They don’t break the
library API or ABI, but they can add nice feature for users.
Why not do this with parallel beta releases? I.e. we make a 1.1.y release
every 3-4 months (or whatever time period people are happiest with), it is
a beta version for users that want to try new features. More cautious
users can stick to the 1.0 release, or wait for 1.2. This seems like a
nice middle ground to me, and people seemed to like the idea when we
discussed this last (or were busy and did not respond).
Let’s take a few obvious cases:
- Make the update checker default – I noticed the Mac 1.0 builds
default to off. That’s fixed now for 1.0.1 and nightly builds
Should probably be default on Windows and Mac, likely not on Linux. I
disabled this by default due to changes made in Qt 4.5.3 that were causing
crashes. I fixed those before the release, but neglected to change the
default.
- What about the z-matrix editor? This is technically in 1.0, but not
enabled (or very functional).- What about the Dalton generator? These sorts of plugins seem like
obvious additions – they add nice functionality for users of Dalton,
and don’t break things for others.
Again, what is wrong with an unstable release series or nightly builds
that track head development. Move bug fixes to the branches as and when
they make sense. This should allow the best of both worlds, and if we find
no one uses the stable branch because it is boring then stop supporting
that.
The introduction of new features risks the introduction of new bugs. Every
new feature can cause bugs, and so I guess it depends on how stable a
stable branch should be. There is lots of precedent for the approach I
suggested (KDE, Qt, Linux Kernel, Gwyddion, Gnome), but if our community
is not interested in that level of stability then I will stop pushing for
it.
So that leaves the Cartesian editor. Personally, I’d like to see some
improvements – can’t it still be a table embedded in a QDialog? I
like being able to sort by z-axis. I can imagine all the copy/paste
buttons would still work.But even if the Cartesian editor is less of a “clear win,” I think
it’s something we should contemplate for 1.0.x. Otherwise, it might
not be incorporated until … March?
Why not make a 1.1.0 release in December to get wider testing on some new
features we are playing with? Label it beta, don’t worry about
translation. Give packagers the option to package stable Avogadro, or a
more experimental development branch.
I know from a packaging point of view I always hate upstreams that add new
features in patch releases, as they are not really patch releases. That
being said, if we want to do that then we should be explicit about what
our policy is and stick to it. Make it clear to translators, users and
packagers that new features may be added in patch releases.
These are just my honest opinions. I thought we had already agreed up on
the release methodology I proposed, it is the one I would prefer we adopt.
Do others have opinions on this?
Marcus
From: Konstantin Tokarev annulen@yandex.ru
04.11.09, 09:10, “Geoffrey Hutchison” geoff.hutchison@gmail.com:
So that leaves the Cartesian editor. Personally, I’d like to see some
improvements – can’t it still be a table embedded in a QDialog? I
like being able to sort by z-axis. I can imagine all the copy/paste
buttons would still work.Killer feature of new editor is a possibility to paste coordinates
from external source. Also it doesn’t require double clicking to
edit every field, and can display in different useful formats, that
could be easily copied to clipboard. If you need sorting by axes,
old version can also be enabled (but I’m not shure how to call it
now). Another way is to add fields X,Y and Z to Atom properties
dialog.
I too find the table a bit easier work with and look at, but the new
functionality is great. What about putting in a toggle button to
switch between a text edit and a table widget, or have the text edit
live in another dialog that pops up when the copy/paste buttons are
clicked?
Dave
On Wed, Nov 4, 2009 at 11:04 AM, mhanwell@gmail.com wrote:
I know from a packaging point of view I always hate upstreams that add new
features in patch releases, as they are not really patch releases. That
being said, if we want to do that then we should be explicit about what
our policy is and stick to it. Make it clear to translators, users and
packagers that new features may be added in patch releases.
Speaking in terms of Ubuntu support, it makes a rather big difference
if new upstream releases are bug-fix only or include new features.
During the Ubuntu development cycle new bug-fix-only upstream releases
can be upload at almost any time, but there is a Freeze on new
upstream releases with features about 1/2 to 3/4 the way through the
cycle. Additionally, in stable Ubuntu releases there is a possibility
of putting bug-fix-only microreleases (like what Marcus has proposed)
into the -updates repositories. Otherwise updates must be done a
cherry-picks of patches for specific reported bugs.
These are just my honest opinions. I thought we had already agreed up on
the release methodology I proposed, it is the one I would prefer we adopt.
Do others have opinions on this?
I’ve personally seen this style of branching and release management
done in several open source projects and while it may seem a bit
overly formal now, I’ve seen a lot of long-term usefulness. It makes
the software much more likely for Linux distributions to incorporate
and track for sure. It also allows the users more flexibility in how
much risk they want to take. If I’m using Avogadro in say a teaching
environment and I have handouts with screenshots, I don’t want the UI
changing a lot. However, I am very eager to get bugs fixed. If I’m a
crackaholic and need my latest Avogadro fix but either can’t build
from source or don’t want to, it’s nice to have the development
release branches to track. It also gives defined points from which to
bisect bugs.
-Jordan
I too find the table a bit easier work with and look at,
As for me, I can’t understand why table is simplier to work with. Maybe you’ve meant it looks “cooler”, but I think current state of properties table-based dialogs doesn’t look “cool”: if Molecule contains several atoms, rows are too high, if many - too low. Resize don’t work with lightweight window managers (probably Qt bug) and there’s no place for sizeGrip to override it.
If you need sorting, there is no problem to include it into text based editor. Or keep existing editor on another menu item.
Also, I didn’t invented this type of UI, it was inspired by integrated editor of Chemcraft program which is used by me and my colleagues
What about putting in a toggle button to
switch between a text edit and a table widget
Good idea, but user needs a possibility to store defult look of editor - table or text edit, or it’ll be inconvenient
or have the text edit
live in another dialog that pops up when the copy/paste buttons are
clicked?
I think such behaviour may surprise user. UI must be as logical as it’s possible
–
Regards,
Konstantin
To me, it seems the best approach would be to take advantage of the
plugin structure. Have the Avogadro 1.0 branch and “official” releases
as Marcus would like: no new strings, strictly bug fixes, etc. But,
then make an additional package that contains the new plugins that can
be installed alongside the main release. I anticipate that most of the
new functionality we see will be in the form of new/changed plugins,
and this would allow users to have a stable avogadro install, as well
as any of the “new” plugins that they may need.
If it’s not too much trouble, each new plugin could be available as a
separate package, so users can just pick the ones they want.
Anyone else in favor of an avogadro and avogadro-experimental-plugins
system? It seems to me that using any other approach makes having a
plugin system pointless…
Regards,
Konstantin
From: mhanwell@gmail.com
Subject: Re: [Avogadro-devel] Releases & Schedules
Date: Wed, 4 Nov 2009 11:04:33 -0500 (EST)So where does that leave 1.1.x and 1.2? Maybe 6-8 months from now?
We need a mechanism to incorporate new, stable plugins. As I said,
let’s discuss these on a case-by-case basis. They don’t break the
library API or ABI, but they can add nice feature for users.Why not do this with parallel beta releases? I.e. we make a 1.1.y
release
every 3-4 months (or whatever time period people are happiest with), it
is
a beta version for users that want to try new features. More cautious
users can stick to the 1.0 release, or wait for 1.2. This seems like a
nice middle ground to me, and people seemed to like the idea when we
discussed this last (or were busy and did not respond).To me, it seems the best approach would be to take advantage of the
plugin structure. Have the Avogadro 1.0 branch and “official” releases
as Marcus would like: no new strings, strictly bug fixes, etc. But,
then make an additional package that contains the new plugins that can
be installed alongside the main release. I anticipate that most of the
new functionality we see will be in the form of new/changed plugins,
and this would allow users to have a stable avogadro install, as well
as any of the “new” plugins that they may need.If it’s not too much trouble, each new plugin could be available as a
separate package, so users can just pick the ones they want.Anyone else in favor of an avogadro and avogadro-experimental-plugins
system? It seems to me that using any other approach makes having a
plugin system pointless…
That sounds like an excellent proposal to me. The contrib directory could
take all experimental plugins and a binary package could install there.
Linux distros can choose whether to package these experimental plugins or
not.
Marcus
On Nov 4, 2009, at 12:10 PM, Marcus D. Hanwell wrote:
Anyone else in favor of an avogadro and avogadro-experimental-plugins
system? It seems to me that using any other approach makes having a
plugin system pointless…
…
That sounds like an excellent proposal to me. The contrib directory
could
take all experimental plugins and a binary package could install
there.
Linux distros can choose whether to package these experimental
plugins or
not.
Well, in that case, we should have a separate repository, maybe
organized by category as suggested by Konstantin.
I do think it’s important in the next major release to have a “New
Stuff” extension, that can let you find and install new plugins or
scripts. On Linux, this might be limited to new Python scripts, but on
Mac and Windows, others could contribute binaries.
For example, Q-Chem has a “QUI” extension, which is currently outside
the source tree.
-Geoff