|
|
Bioinformatics.org
|
![[?]](https://www.bioinformatics.org/images/icons/info.png)
|
|
Research
|
Online databases
Online analysis tools
Online education tools
|
|
Development
|
|
|
Forums
|
News & Commentary
Jobs Forum
(Career Center)
|
|
|
Ghemical: Molecular modelling - Message forums
|
         
|
 |
|
Expanded view | Monitor forum | Save place
|
|
Welcome to Open Discussion
|
|
|
|
|
|
I'd add several GUI suggestions:
- Cut, Copy, Paste (and ultimately a "library" of preset molecules and groups for pasting directly
- A "lasso" tool for selecting a region
- A "measure" tool for measuring distances, angles, torsions (or three separate tools, whichever is easier)
- Undo/Redo
- A "symmetrizer" for adjusting to a specific symmetry. I have some GPL'ed code to detect symmetry of a molecule with a tolerance adjustment, so it's adapting this...
- More complete documentation from GNOME
I'd also add some render suggestions:
- User prefs for colors, number of polygons, etc.
- Rendering modes for export to POVRay or "flat" circles and lines for black and white printing
In the near future, I will probably be working on:
- More file translators for OELib
- User prefs (as above)
- "Revert file" and "Save" features to use the last filename
|
|
|
|
|
|
Just to add to the wishlist--
Toolbars!
instead of a popupmenu item to change the current element/bondtype, have it be toolbar, a la gimp/spartan/etc.
More functionality to the select tool
ie delete selected, move selected/ in addition to cut/copy selected.
in the nearest future, i am working on rendering double/triple/conj. bonds in ball and stick and cylinder mode
comments/questions?
- James Schroeder
jschroeder@northwestern.edu
|
|
|
|
|
|
|
> More functionality to the select tool
Actually you can move/rotate/orbit selected if you hold down the shift key. As I said, documentation for the GNOME frontend is needed...
-Geoff
|
|
|
|
|
|
I would like to define what I expect we have in the v1.0, and then divide my wishlist/plan to "pre-1.0" and "post-1.0" parts.
I would like to promote the version number to 1.0 when we have all the "standard" QM and MM techniques properly implemented and easily available to the users. In this group I would take for MM geometry optimization and molecular dynamics, and for QM geometry optimization and some kind of transition-state search (if possible, I don't really know how difficult one this is).
Where are we now? In MM, we have the algorithms, but only a very simple and limited forcefield. The QM case is opposite: we don't have the algorithms yet, but we have the excelent MPQC program that we can use in calculations. I think it will take roughly a year for us to reach the v1.0 (using that my definition of v1.0).
The "pre-1.0" wishlist:
^^^^^^^^^^^^^^^^^^^^^
- a better "treelist view"; this will probably wait for the next GNOME version.
- graphical input-file generators for programs like MPQC and ammp (or other programs???), implemented as gnome "druids"; currently we have under directory "small-utilities" a program "gp2mpqc" that inspired me to this.
- improved documentation, for both developers and users.
- and of course, those standard MM and QM techniques I mentioned above.
The "post-1.0" wishlist:
^^^^^^^^^^^^^^^^^^^^^
- there are many smaller tweaks that I have thought, but I think I will leave most of them at this stage.
- data exportation in CSV (comma separated values?) format. Some time ago I planned spreadsheet-like properties and plotting, but I believe we can use external programs for all that if we have good data export properties.
In the near future, I will probably be working on:
- suggest a way how to implement data exchange between mm1_mdl <=> OELib.
- suggest a way how to implement quick "mode changes" mm-model <=> qm-model, and how to implement "layered" models.
- I'm actually quite happy with the GUI at the moment, so I expect to spend more time working with those "engine" classes in future...
Ok, as I'm responsible for the largest part of the current class framework, I think I'm also responsible for all that stuff where co-operation with other programs and libraries are needed. So please just throw me some questions if you have any. When we plan some new features, I might cough up some example code to show how we might do that (in my opinion) easily. On the other hand, I might start yelling if you propose some (dramatic) changes to the core part of the current framework; unfortunately I'm quite dependent on all that at the moment...
|
|
|
|
|
|
Hello.
I just added a "preview" version of my reduced protein modelling system to the CVS. There is nothing functional yet; you can just open some example files from the "examples" directory. The system is almost ready, and I will release it ASAP, but I have to wait for blessing from the referees before I can do it (takes a few months I suppose).
The reason why I added the model now, is that we are planning new features to the user interface right now, and I wish that you see an example of a model which differs quite much from traditional "all atoms" MM and QM models.
The new model has for example the following (peculiar) features:
- in the model, there is no "atoms" or "bonds", at least in the same sense as in "all atoms" models (I would call them virtual atoms and virtual bonds).
- unlike in an "all atoms" model, it makes no sense to "draw" or "erase" those bonds; instead, we will "mutate" the amino acid residues directly here.
- there is no quick and simple way to convert this model, say to an all atoms MM model. But the conversion in reverse direction is quite easy.
So, I have had quite cautious views what comes to the user interface, and I hope you now understand better why is that so. There truly are many kinds of models, and I hope the user interface would fit for all of them.
TH
|
|
|
|
|
|
Hummm... Or maybe this is not a problem after all; maybe we just have to make the user interface flexible and, especially, configurable enough so that it fits for all purposes.
Let's take toolbar buttons like "select element", "select bondtype", "add hydrogens" and "remove hydrogens" as an example. These would be very convenient when working with all atoms models, but useless when working with these "strange" models.
So, maybe we just set this set of buttons configurable (among many other things), and set the default settings according to estimated "typical" use (in this case, "enabled").
TH
|
|
|
|
|
|
|
Yes!
This is why I suggested having one set of menus... For example, bond types are meaningless to QM models (or your "reduced" model), but are still useful to see in rendering!
It's also why I placed "Add hydrogens" and "Remove hydrogens" as separate menu items directly under "build" because they're more convenient that way.
And I imagine there's some way of "greying out" buttons that are currently disabled.
-Geoff
|
|
|
|
|
|
Originally I thought about toolbar buttons here, but maybe we can apply it to the menu as well.
I thought that someone might want a complete toolbar, with a truckload of buttons (takes much screen real estate), or a lighter one with most important buttons (maybe just those element/bondtype/hydrogens buttons), or a minimal one with just the current mouse tool buttons. With toolbar this is easy; we just read the user's "settings" file when the program starts, and create the toolbar buttons according to those instructions (we just create those buttons (or button sets) that user has selected). I guess nothing else is needed.
But the code for buttons must be generic. The buttons are visible all the time, and the user might have any of the models (or no model at all) active when the button is pressed.
If we have a single menu, we must use similar generic code also there. Currently each model has it's own menu, and no checking is necessary. In a single menu we would like to grey out (or even make invisible if possible) some items depending on the situation.
Both menu types are OK to me, I will just support that alternative that turns out to be more easier and convenient to handle (that is, for developers, since I am a lazy man by nature). We could make some of those new toolbar buttons and see what kind of code we need there.
BTW, we have already now quite many graphics settings in the menu. Would it be easier to convert them into a single dialog box?
TH
|
|
|
|
|
|
All of the popup menus that we have can also be effectively used as toolbars just by 'undocking' that menu from the popup. If we could only figure out how to save the settings of these windows/toolbar from session to session then these could be effective toolbars...
is this a window-manager specific function (turnung popup menu items into windows/toolbars) or a gnome feature?
- James
|
|
|
|
|
|
Still forgot to mention one idea about popup menus.
Soon I'm trying to improve the "treelist view", and I believe we could add some small popup-menus to the "treelist view" items. For example, in the section where the lights or objects are listed, we could add a small popup menu with items like "select" and "delete" to each "treelist view" item.
This way, I'm afraid we will still have many different popup menus in the program, even if we choose to make a single popup-menu for each model.
TH
|
|
|
|
|
|
|
I'm going to start, maybe this week by adding settings for the periodic table. I'm going to add a GNOME color selector and a few text entry boxes to the bottom of the PT dialogue to set these using gnome-config.
If this goes well, we can perhaps begin adding defaults/preferences for other graphics options.
|
|
|
|
|
|
Maybe this is an obvious remark, but I hope we could save the settings in a file
$HOME/.ghemical
TH
|
|
|
|
|
|
|
I don't think there's any problem with having many different popup menus. (Here on the Mac, they're called "contextual menus" and thus refer to the "context" of the user.)
But as you say, we're all a bit lazy. So I worry when there's several copies of nearly-identical code for the modes. I expect I'll probably forget to update one or the other. (e.g. I don't think there's import/export for the QM mode.)
-Geoff
|
|
|
|
|
|
I think that we could do import/export in QM mode using logic
"import in QM" ==
"import in MM + convert MM to QM"
I will have a few busy weeks here, but then I will start working with these mode changes and things like that...
TH
|
|
|
|
|
|
During the first make, of installation process, ghemical calls for:
/home/name/mpqc-target/lib/
and looks for specific files, with extension .a
Nothing is mentioned about this in the install file. I believe that it would be appropiate to indicate the user that s/he has to make a copy of:
/home/name/mpqc-x.y.z/lib
and paste it in:
home/name/mpqc-target
|
|
|
|
|
|
Or perhaps just use 'sc-config --libs' !?!
|
|
|
|
|
|
Yep, it would be better to use headers/libs produced by MPQC directly. I'll try to study & fix this later.
|
|
|
|
|
|
Hi.
I just started to build an user's manual under "bin/user-docs". Any ideas about topics and/or organization?
|
|
|
|
|
|
|
There should definitely be some topics on manipulating the molecules using selections, etc. and using the mouse.
I'll think about it more... -Geoff
|
|
|
|
|
|
Hi there, I'm having troubles building ghemical with the gcc 3.0.1 (I could be more verbose on the type of error, but I would just like to make sure that someone _has_ been building ghemical whit this version of gcc.
Thanks in advance and sorry to post anonymously
-- jose
(venceslau@mailandnews.com)
|
|
|
|
|
|
Hi,
I tried it some time ago with gcc-3.0.0, and there were some problems. I don't remember if it finally worked or not, but at least I added those
using namespace std;
lines here and there, so please at least use the CVS version if you try gcc-3. gcc-2.96.2 has worked for me so far...
TH
|
|
|
|
|
|
I've gotten the cvs, but the problem remains, in parsmart.cpp in oelib. I've commented the ofending function (yes, I will get back to it to figure what is wrong with it, but my years of cpp are long gone :-) and I'm proceding in the compilation just to check what other tools/libs are needed.
I've fetched the fortran to c header files (f2c.h needed in src/common), but now I'm having problems in src/graphics now.
So, it has been a bumpy but nice ride :-)
|
|
|
|
|
|
Yes, you definitely need f2c libs and headers now because the MOPAC7 stuff is included.
Today I was able to compile the CVS version with the RedHat 7.1 compiler (one of those "doped" 2.96 compilers). So why hurry to gcc-3 anyway? :-)
TH
(anon because I just forgot to login)
|
|
|
|
|
|
ghemical build with(sort off ;-)
weel, after some tweaking (changing -mpentium to -march=pentium in makefiles, removing -I/usr/include from makefiles because it drives gcc #next_include mad and some other incantations that I cant no longer remember, I've built ghemical and it even runs)
Well, not for long, cause it takes just a bit of fussing for it to dump core :-)
I had to comment a funtion in oelib/parsmart.cpp in order to compile and it must be driving the rest of the code nuts :-)
[yes, I know that it's not The Right Way to compile and I do understand the impications of such a stupid fix :-)]
I had gcc 2.9.1.something on my system and some app told me it needed gcc > 2.9.5, so I just tought, what the weck, lets go for the bledding edge - ouch, it's hurting :^)
So, I'm im reading on STL,doing some mumbo jumbo to parsmart.cpp whenever I've a free time. (no, I will not ask a friend to build it for me nor will I downgrade my super-sharp ginksu gcc :-)
|
|
|
|
|
|
Ok. :-) We will try gcc-3 more seriously after it has become a bit more mainstream than today (read: debian and/or redhat uses it).
BTW, at the moment file import/export and "add hydrogens" use OELib code; so if there are problems also with other features than these you have hit with an another problem...
TH
|
|
|
|
|
|
> We will try gcc-3 more seriously after it has become a bit more mainstream than today (read: debian and/or redhat uses it).
FYI: Debian uses gcc-3 already on ia-64 at least.
|
|
|
|
|
|
|
The catch is that while the Ghemical code seems to be fine with gcc3, the OELib code for file import/export and other functions is not.
I'm working with the OELib developers to get a new version of OELib, hopefully "Real Soon Now."
-Geoff
|
|
|
|
|
|
Good to know. I asked the oelib developer about it and he told me he was doing a closed source rewrite of it, pointing out that open-oelib won't be developped much in the future. Do you know anything about this?
Michael
|
|
|
|
|
|
Hello,
I'm having trouble building ghemical with mpqc-2.0.0. It could be my weird setup - mpqc include files under /usr/include/mpqc/ and the libraries under /usr/lib/mpqc, but perhaps ghemical needs to be ported to 2.0.0?
Anyway, here is the error output:
make[1]: Entering directory `/home/mbanck/src/ghemical-0.80/src/common'
g++ -DPRIMARY_PATH=\"/usr/local/share/ghemical/\" -DFORMAT_PATH=\"/usr/local/share/ghemical/0.80\" -c -g -O2 -I/usr/include/mpqc -I/usr/lib/mpqc -I../../src/graphics -I../../src/common -I../../oelib -I/home/mbanck/src/ghemical-0.80/src ./qm1mdl.cpp
In file included from ./qm1mdl.cpp:15:
qm1e_mpqc.h:56: syntax error before `;'
qm1e_mpqc.h:57: syntax error before `;'
qm1e_mpqc.h:59: syntax error before `;'
qm1e_mpqc.h:60: syntax error before `;'
qm1e_mpqc.h:62: syntax error before `;'
qm1e_mpqc.h:64: syntax error before `;'
qm1e_mpqc.h:65: syntax error before `;'
make[1]: *** [qm1mdl.o] Error 1
make[1]: Leaving directory `/home/mbanck/src/ghemical-0.80/src/common'
I patched ghemical so that it doesn't look for $(MPQC_SRC_DIR)/src/lib but directly in $(MPQC_SRC_DIR) and configured it like
./configure --with-mpqc-src=/usr/include/mpqc --with-mpqc-target=/usr/lib/mpqc
(Some information on which files are actually needed would be appreciated)
So I'm not sure if this is because I configured ghemical the wrong way or because mpqc-2.0.0 doesn't play nicely with ghemical-0.80 (or current CVS, as there seem to be no related changes since the release)
thanks,
Michael Banck
|
|
|
|
|
|
Hello,
I just found out 5 minutes ago that MPQC-2.0.0 is released... Thanks! So, specific porting to version 2.0.0 is needed, and Ghemical 0.80 won't work with this new version.
In the meantime, could you keep using the older version 1.2.5 of MPQC until we can fix this?
Tommi
|
|
|
|
|
|
Actually, I tried building ghemical with mpqc-2.0.0 again and, strangly enough, this time I got some more informative error messages:
/usr/include/mpqc/util/ref/ref.h: In method `Ref<SCMatrixKit>::Ref<DescribedClas
s>(const Ref<DescribedClass> &)':
./qm1e_mpqc.cpp:68: instantiated from here
/usr/include/mpqc/util/ref/ref.h:347: type `SCMatrixKit' is not a base type for
type `DescribedClass'
/usr/include/mpqc/util/ref/ref.h: In method `class Ref<MolecularEnergy> & Ref<Mo
lecularEnergy>::operator =<DescribedClass>(const Ref<DescribedClass> &)':
./qm1e_mpqc.cpp:71: instantiated from here
/usr/include/mpqc/util/ref/ref.h:435: type `MolecularEnergy' is not a base type
for type `DescribedClass'
/usr/include/mpqc/util/ref/ref.h: In method `class Ref<OneBodyWavefunction> & Re
f<OneBodyWavefunction>::operator =<MolecularEnergy>(const Ref<MolecularEnergy> &
)':
./qm1e_mpqc.cpp:72: instantiated from here
/usr/include/mpqc/util/ref/ref.h:435: type `OneBodyWavefunction' is not a base t
ype for type `MolecularEnergy'
/usr/include/mpqc/util/ref/ref.h: In method `class Ref<Wavefunction> & Ref<Wavef
unction>::operator =<MolecularEnergy>(const Ref<MolecularEnergy> &)':
./qm1e_mpqc.cpp:72: instantiated from here
/usr/include/mpqc/util/ref/ref.h:435: type `Wavefunction' is not a base type for
type `MolecularEnergy'
./qm1e_mpqc.cpp: In method `fGL qm1_eng_mpqc::GetESP(fGL *, fGL *)':
./qm1e_mpqc.cpp:271: `RefPointChargeData' undeclared (first use this function)
./qm1e_mpqc.cpp:271: (Each undeclared identifier is reported only once
./qm1e_mpqc.cpp:271: for each function it appears in.)
./qm1e_mpqc.cpp:271: parse error before `='
./qm1e_mpqc.cpp:273: `RefOneBodyInt' undeclared (first use this function)
./qm1e_mpqc.cpp:274: `RefSCElementOp' undeclared (first use this function)
./qm1e_mpqc.cpp:281: `RefSCElementScalarProduct' undeclared (first use this func
tion)
./qm1e_mpqc.cpp:281: parse error before `='
./qm1e_mpqc.cpp:282: `RefSCElementOp2' undeclared (first use this function)
./qm1e_mpqc.cpp:284: `pc_op' undeclared (first use this function)
./qm1e_mpqc.cpp:285: `sp' undeclared (first use this function)
./qm1e_mpqc.cpp:286: `generic_sp' undeclared (first use this function)
make[1]: *** [qm1e_mpqc.o] Error 1
make: *** [all] Error 1
Don't know if this is of any help...
|
|
|
|
|
|
Hello,
I still haven't had a chance to look at the new 2.0.0 version of MPQC yet, and it might take some time (read: probably several months) until I can seriously start this job.
I looked at the source briefly, and from the errors I would conclude that some classes (or class names) are simply changed that much in v2 so that the old code won't work anymore. I don't believe that porting to v2 is very difficult, and at some point it will certainly be done.
But it will take some time and unfortunately I don't have this time right now. :(
Tommi
|
|
|
|
|
|
Hi there,
Compiling ghemical, I get the following error at the linking stage:
g++ -o /export/home/sucher/ghemical-0.81/bin/ghemical t3main.o t3docv.o t3views.o t3errutil.o t3dialog.o glade_callbacks.o glade_interface.o glade_support.o t3qm1docv.o t3qm2docv.o t3mm1docv.o t3mm2docv.o t3prefs.o /export/home/sucher/ghemical-0.81/src/graphics/libgraphics.a /export/home/sucher/ghemical-0.81/src/common/libcommon.a /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a /export/home/sucher/ghemical-0.81/oelib/liboe.a -lglut -lXmu -lg2c -lm -lgtkgl -lGLU -lGL -L/opt/sfw/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lsocket -lnsl -lm -lg2c -lm -lgtkgl -lGLU -lGL -L/opt/sfw/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lsocket -lnsl -lm -lgnomeui -lart_lgpl -lgdk_imlib -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -lresolv -lrt -lnsl -lsocket -laudiofile -lm -ldb-3 -lglib -ldl
ld: fatal: symbol `work1_' has differing sizes:
(file /export/home/sucher/ghemical-0.81/src/common/libcommon.a(qm1e_mopac.o) value=0x2ab980; file /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(dernvo.o) value=0x73bdb0);
tentative symbol cannot override defined symbol of smaller size
ld: warning: symbol `geom_' has differing sizes:
(file /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(compfg.o) value=0x1680; file /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(esp.o) value=0xb40);
/export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(compfg.o) definition taken
ld: fatal: symbol `work1_' has differing sizes:
(file /export/home/sucher/ghemical-0.81/src/common/libcommon.a(qm1e_mopac.o) value=0x2ab980; file /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(iter.o) value=0x73bdb0);
tentative symbol cannot override defined symbol of smaller size
ld: fatal: symbol `work1_' has differing sizes:
(file /export/home/sucher/ghemical-0.81/src/common/libcommon.a(qm1e_mopac.o) value=0x2ab980; file /export/home/sucher/ghemical-0.81/miniMOPAC/libminiMOPAC.a(deri22.o) value=0x73bdb0);
tentative symbol cannot override defined symbol of smaller size
ld: fatal: File processing errors. No output written to /export/home/sucher/ghemical-0.81/bin/ghemical
collect2: ld returned 1 exit status
gmake[1]: *** [/export/home/sucher/ghemical-0.81/bin/ghemical] Error 1
gmake[1]: Leaving directory `/export/home/sucher/ghemical-0.81/src/target3'
gmake: *** [all] Error 1
Can anyone help me?
Tx,
Nikolaus
Please reply to sucher@ust.hk
|
|
|
|
|
|
Hi all,
we were able to solve this problem with Nikolaus, and just to inform other Solaris users, we solved it by using the GNU linker (gnuld) instead of the Solaris linker. The compiler used was gcc-2.95.2.
|
|
|
|
|
|
|
This is just a thread for potential feature requests. Post ideas, suggestions, etc. here.
|
|
|
|
|
|
|
Need a preferences dialog box and the ability to save settings to project files as well.
(Easy way of setting rendering detail, etc.)
|
|
|
|
|
|
|
We need a way of allowing plugins written in scripting languages like Perl or Python. These could interface with other programs, perform various changes on the molecules, etc.
Suggestions for an "All Atoms" API:
GetCurrentCRD()
SetCurrentCRD()
AddAtom()
AddBond()
DeleteAtom()
DeleteBond()
...
This probably also needs some sort of "global hook" for putting in a menu item and then calling main() for the plugin.
|
|
|
|
|
|
|
The "Save As" menu item should also have a "Save" for just saving the file to the current filename/path (if it exists.) If no path exists, this should work like the Save As.
|
|
|
|
|
|
|
A revert menu item would be nice--silently close the current buffer and open it again from disk.
This should probably include a question to be sure the user wants to discard the changes!
|
|
|
|
|
|
|
Ideally, the engine should allow exporting the graphics--e.g. create an offscreen buffer that's potentially larger than the screen and then save it to a file.
This would allow high-res JPEG or PNG files for presentations.
|
|
|
|
|
|
Yep. At least the MESA opengl variant supports off-screen rendering directly.
Then we have had that idea of coverting the current view to commands for a ray-tracing program; a nice idea but I guess I don't have time for that very soon.... :(
|
|
|
|
|
|
|
This is a bit complicated, but it would be fantastic to have an undo/redo feature to undo the last action. (This is especially a big deal if the geometry optimization screws up.)
I don't know a good way of dealing with this--though an easy (but memory intensive) solution would be to keep a copy of the current coordinate set and camera as the "undo" buffer.
|
|
|
|
|
|
|
It would be great if the current selection could be copied/pasted. (Cut is probably not quite as useful.)
This should work across files, so this needs to be some sort of global buffer.
|
|
|
|
|
|
|
Ideally you should be able to drag the select tool around and select a region of space. This would be a bit like the "lasso" or "rectangle" tool in GIMP, etc.
|
|
|
|
|
|
|
Here's an idea for the "library" feature.
Have a user-definable folder for the library--default to the same path as the parameters, etc. The user could set this in the prefs.
The library/ directory could have one level of directories, then a bunch of Ghemical files. So a menu could contain items for each of the directories and these would list the files. Choosing a file would Open/Insert it into the current project.
This allows the user to easily file and modify items in the library. (And it's not too hard to code.)
|
|
|
|
|
|
|
This is done, though we'll need to make up some example molecules and change the installation portion of the Makefile.in.
|
|
|
|
|
|
|
Not much to say. These need to work--maybe through an "all atoms" interface class.
|
|
|
|
|
|
Yep.
We haven't really specified a file format for QM files, but it looks like the MM file format would be just fine.
There we have those !Sections, and for QM models we might have some different !Sections present,
but we can always ignore those !Sections that we don't need...
|
|
|
|
|
|
|
New sections for the file format (previous versions would just ignore them)
!Unit Cell
a= b= c= alpha= beta= gamma=
!Charge
!Hamiltonian or !Basis
|
|
|
|
|
|
|
It would be nice to animate vibrational modes based on QM output from other programs.
|
|
|
|
|
|
I think we could even compute the vibrations ourselves... For all models, we can calculate the 1st derivatives, and using those I think we could calculate 2nd derivatives numerically. Then from 2nd derivatives it is possible to solve the vibrations somehow... I guess :)
Anyways, when we have the displacement vectors, it would be very easy to animate them!
|
|
|
|
|
|
|
Ideally, the QM mode should be able to read output from other popular programs (e.g. Gaussian, Q-Chem, Jaguar, HyperChem...) -- maybe this could work by translating the eigenvectors to MPQC format?
|
|
|
|
|
|
|
Trajectory format should allow importing trajectories from other programs (VMD pops to mind).
|
|
|
|
|
|
|
Like in Spartan, which has a dialog with:
formula
molecular weight
surface area
volume
total energy
HOMO energyLUMO energy
Dipole
...
|
|
|
|
|
|
|
For measuring, it's sometimes useful to define a temporary dummy atom as a centroid. (Either cartesian or mass-weighted)
This would obviously not necessarily be updated by other actions, but at the least it would make some measurements easier.
|
|
|
|
|
|
|
Some tools to set bond lengths, angles, torsions, etc. to particular values would be helpful.
Along the same line, it might be helpful sometimes to have "alignment" tools to set the position to a particular X, Y, Z, etc. (Yes, you can edit the file, but it's sometimes nice to do this in the editor.)
|
|
|
|
|
|
|
Maybe a "Draw Vector" object that illustrates the dipole vector including scaling to the appropriate magnitude.
|
|
|
|
|
|
I think the MOPAC code can calculate both partial charges for atoms, and the dipole moment.
This could be done, if we could take the dipole componenets from MOPAC...
|
|
|
|
|
|
|
I think it can be done for MM-calculated charges as well--it just won't be as accurate as MOPAC or MPQC-dervied dipoles.
|
|
|
|
|
|
|
It would be nice to "erase" bonds as possible. One way would be to have a "No Bond" bond order as a choice in the Bondtype dialog--this would just delete the bond when it's redrawn.
|
|
|
|
|
|
humm... I think the "erase" mouse tool can do this pretty well?
|
|
|
|
|
|
|
No, it always seems to "grab" the nearest atom too. So it doesn't just erase the bond, it erases an atom and usually more than one bond.
Try it--make a nice giant bond and click right in the middle!
|
|
|
|
|
|
I think this actually works, in a way... :)
You see, you have to use in "erase" exactly same logic as in "draw" when you add a bond. So, erasing is an "un-adding" operation: to remove a bond, press MB down at 1st atom, move mouse to 2nd atom, and release MB.
The reason why it works this way is, that the OpenGL selection code can detect only atoms, and no bonds. So we just select the atoms, and later figure out what bond the user meant.
|
|
|
|
|
|
|
This sounds like something that should be added to the OpenGL selection code, at least for the erase tool. Granted, you're correct that this works, but it seems more intuitive to click on the middle of a bond to see it disappear.
|
|
|
|
|
|
|
Currently the file import doesn't attempt to determine double bonds, etc. This would be useful.
Beyond that, the same code might be useful for "retyping" after a QM calculation or in a trajectory--recognizing aromatics, etc.
|
|
|
|
|
|
I'm currently working for some improvements for molecular mechanics force field and it's parameters. So, I expect that some improvements could appear there during 2002.
|
|
|
|
|
|
|
I actually have code to do this--calculate the symmetry of any given set of coords. Need to import and "tie in."
|
|
|
|
|
|
This might be an addition to oelib/openbabel as well...
Michael
|
|
|
|
|
|
|
Yes, it's certainly a nice idea to add it to the base OpenBabel library. However, the code is not strictly under the GPL--but the author gave me an OK to include it in Ghemical.
I'm not sure how he would feel about including it in a library where the source is more exposed. But I'll contact him about it. Obviously it would be nice to put in symmetry elements for filetypes that support it.
-Geoff
|
|
|
|
|
|
|
Spartan calculates the volume and surface area of a model--this would be very useful for comparing solvent properties, crystal packing, etc.
|
|
|
|
|
|
|
The file format currently supports having multiple coordinate sets in the same project. Ideally, the interface should support this as well--it might make copy/paste and other features easier.
|
|
|
|
|
|
Hello,
Just to let you know, ghemical is now officially part of Debian. Well, unstable at least. If no serious problems show up, it will advance into testing in ten days and be part of the next release.
Keep up the good work...
Michael
PS: I would like to post with my new bioinformatics account, but it does not let me log in.
PPS: mpqc-2.0.0 packages hopefully enter unstable soon, too.
|
|
|
|
|
|
Hi, I just wanted to know if you plan another release anytime soon. Debian will freeze soon and ghemical did not make it into testing yet and won't be included in the next release if I don't fix it. The current problem is oelib and its problems with gcc-3.0. Two of Debians supported architectures need 3.0 and therefore don't compile .
First question: Is openbabel in ghemical already fixed WRT gcc-3.0 like openbabel proper?
second question: Will you release soon? If not, don't worry, I'll package the current CVS version, if you don't mind.
thanks,
Michael
|
|
|
|
|
|
I think we could make a new minor release almost anytime now; the biggest change seems to be the switch to OpenBabel, so I think Geoff knows best
how that transition is going and when it's ready. I have added some conformational search tools and they are ready with an initial (text-based) user interface.
If it seems that we can't make it soon enough, I think it's fine to package the CVS version.
Regards,
Tommi
(sorry to post as anonymous, but my Mozilla refused to log in :)
|
|
|
|
|
|
I've found it difficult to orient the molecule so that when I generate a plane object the plane is parallel to the plane of the molecule. A simple solution would be to check if there are 3 atoms selected when calculating the plane. If there are, the xdir and ydir variables of the plane could be calculated using the coordinates of the selected atoms. I made an unsuccessful attempt to do this, but it seems to be possible without making too many changes.
|
|
|
|
|
|
Hello!
Sorry to answer a bit late (it's easier to reach me using the mailing list).
About the question then; I think you will find it easier to orient the plane instead of the molecule! First you have to select the plane object (it's selected by default when you have just created it, or you can use the "project view" to select it from the list of objects). Then take one of the orbit/rotate/translate mouse tools, and before using the tool, press and hold the SHIFT key down at the keyboard. This will affect so that the operation is applied to the plane (the selected object) instead of the "camera" object.
You also can manipulate the atoms or molecules that are selected in the same way.
Regards,
TH (posted as anon in a hurry...)
|
|
|
|
|
|
Cool. I'll add this to the documentation for this feature. Please let me know of any other hidden features like that.
|
|
|
|
|
|
I was wondering if someone could help me with deciding on the best way to break into a bioinformatics career. I have a BS in microbiology right now but intend on going back to school. I have heard of a program called a certified bioinformatics specialist but I am not sure if that is the best way to go. Would it be better to get a MS in bioinformatics and then get certified in programing languages like PERL and SQL?
|
|
|
|
|
|
Someone please provide some suggestions on this. I've got a BS in Molecular and Cell Biology and am currently the Team Lead of 46 Level 2 Unix and AIX Operators. A local university offers both MS in Bioinformatics and the National Bioinformatics Institute's Certified Bioinformatics Specialist certification (for US$6k). I'm a bit concerned that the bioinformatics certification isn't worth the $6000, but it's faster than the grad degree. What's really important to employers?
|
|
|
|
|
|
I foud this, it doesn't look good for the NBI CBS course: http://bioinformatics.org/pipermail/bio_bulletin_board/2002-October/000895.html
|
|
|
|
|
|
I have successfully compiled and used with pleasure ghemical on Intel machines. However, I have been getting the "memory exhausted" error upon the last link step of the compilation on an AMD Athlon based machine. Is this error specific to AMD? I am using Debian 3.0 with the 2.2.20 kernel. Has anyone else seen this problem?
Thank you,
Roy Little
|
|
|
|
|
|
Hi, and sorry for the late answer; the mailing list usually gives much better response...
No, I haven't seen such errors myself. I'm using Debian "testing" and "unstable" distributions and those have worked fine.
Regards,
TH
|
|
|
|
|
|
This is almost too embarrassing to ask but I looked far and wide and still could not figure out how to center a molecule on the center-of-gravity. Can someone help me out here ? Sorry if this is too trivial...
|
|
|
|
|
|
Hi,
there is no such tool yet, even though it's a simple operation as you mentioned. Unfortunately I have no time to improve the GUI right now, I try to remember it next time I work with the GUI.
Regards,
TH
|
|
|
|
|
|
Hello all!
How can I get the numeric output for ghemical (1.00 and 1.50) results? Something like *.log in gamess!
Thanks,
mihai
|
|
|
|
|
|
Hi all,
I was wondering if anyone tried to use PC-Gamess
with ghemical-gms? I modifie the rungms script by replacing all instances of wingamess by PCGAMESS, but still no luck.
This is the output I get from running gtk-gamess:
rm: cannot remove `temp/gamess-input-anchor-thiol.*': No such file or directory
Any comments or help will be useful.
Thanks.
|
|
|
|
|
|
I have looked around to find the method that Ghemical uses to do a "simple" geometry optimization but havent found anything yet. Can someone tell me which gradient method is used to optimized the structures, and how it fairs with semi-empirical methods. - Thanks -
|
|
|
|
|
|
Anyone knows how to get a complete manual of ghemical?
What is the best way to proceed geometry optimization? delta cutoff or gradient?
No limited steps?
Regards,
Felipe
|
|
|
|
|
|
I have looked around to find the method that Ghemical uses to do a "simple" geometry optimization but havent found anything yet. Can someone tell me which gradient method is used to optimized the structures, and how it fairs with semi-empirical methods. - Thanks -
|
|
|
|
|
|
My current installation of Ghemical/Mopac was performed through Fedora Core 14 packages. Presently installed packages are (but problems arose also with previous versions):
ghemical-2.99.2-16.fc14.x86_64
libghemical-2.99.1-17.fc14.x86_64
libghemical-devel-2.99.1-17.fc14.x86_64
mopac7-1.15-9.fc14.x86_64
mopac7-devel-1.15-9.fc14.x86_64
mopac7-libs-1.15-9.fc14.x86_64
Optimizations run flawlessly in MM or QM/MPQC setups. However, when using any MOPAC parametrization, structures are heavily and increasingly distorted from the first opt. step.
Nevertheless, if the MOPAC input file FOR005 produced by ghemical is used for a standalone (i.e. command-line) run of MOPAC, the output looks quite reasonable and also the symmetry of the initial structure is correctly recognized and assigned.
Best,
Pietro
|
|
|
|
|
|
My current installation of Ghemical/Mopac was performed through Fedora Core 14 packages. Presently installed packages are (but problems arose also with previous versions):
ghemical-2.99.2-16.fc14.x86_64
libghemical-2.99.1-17.fc14.x86_64
libghemical-devel-2.99.1-17.fc14.x86_64
mopac7-1.15-9.fc14.x86_64
mopac7-devel-1.15-9.fc14.x86_64
mopac7-libs-1.15-9.fc14.x86_64
Optimizations run flawlessly in MM or QM/MPQC setups. However, when using any MOPAC parametrization, structures are heavily and increasingly distorted from the first opt. step.
Nevertheless, if the MOPAC input file FOR005 produced by ghemical is used for a standalone (i.e. command-line) run of MOPAC, the output looks quite reasonable and also the symmetry of the initial structure is correctly recognized and assigned.
Best,
Pietro
|
|
|
|
|
|
Hi, I have ghemical 2.99 2-1 installed for a class.
Everyone else is using gauss view, and when I tried to follow along, I noticed that I was missing a log of basis sets. One of the 1st examples we wanted to find the energy for was methane, and we were using CI method, I could not find it in ghemical. Is there a more up to date library? or those methods currently installed are the only ones it will preform?
|
|
|
Start a new thread:
You have to be to post a reply.
|
|
![[University of Birmingham]](https://www.bioinformatics.org/images/ack_banners/Birmingham-728x90.gif)
![[Patsnap]](https://www.bioinformatics.org/images/ack_banners/Patsnap-728x90.png)