Open Babel is a convenient tool for converting between chemistry-related file formats. Sadly, it's not included in ROCKS 5.4.3 from what I can see and I could only install a severely outdated rpm package which doesn't support gaussian 09 and nwchem well.
The easiest way to compile openbabel is by using cmake.
Cmake:
wget http://www.cmake.org/files/v2.8/cmake-2.8.8.tar.gz
tar -xvf cmake-2.8.8.tar.gz
cd cmake-2.8.8.8/
./configure --prefix=/home/me/.cmake
make
make install
Add the following to your ~/.bashrc and source it:
export PATH=$PATH:/home/me/.cmake/bin
Note: this works in Scientific Linux (Boron) 5.4 as well
Openbabel
wget http://downloads.sourceforge.net/project/openbabel/openbabel/2.3.1/openbabel-2.3.1.tar.gz?r=http%3A%2F%2Fopenbabel.org%2Fwiki%2FGet_Open_Babel&ts=1336048328&use_mirror=aarnet
tar -xvf openbabel-2.3.1.tar.gz
cd openbabel-2.3.1/
cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/me/.babel
make
make install
Add the following to your ~/.bashrc and source it:
export PATH=$PATH:/home/me/.babel/bin
Note: this works in Scientific Linux (Boron) 5.4 as well
Do
babel -L formats
to get a list of formats.
03 May 2012
132. Ecce v 6.2 -- minor bug: nosymm in g09 input
Ecce 6.2 doesn't officially support Gaussian 09 as far as I know. However, they are compatible enough for a wide range of tasks.
However, if you use nosymm you will not be able to see orbital occupancy:
#P rb3lyp/6-31++g** 5D 7F Opt=() Freq=() Punch=(MO) Pop=() scrf=(pcm, solvent=dichloromethane)
vs
#P rB3LYP/6-31++g** 5D 7F Opt=() Freq=() Punch=(MO) Pop=() scrf=(pcm, solvent=Dichloromethane) nosymm
However, if you use nosymm you will not be able to see orbital occupancy:
#P rb3lyp/6-31++g** 5D 7F Opt=() Freq=() Punch=(MO) Pop=() scrf=(pcm, solvent=dichloromethane)
vs
#P rB3LYP/6-31++g** 5D 7F Opt=() Freq=() Punch=(MO) Pop=() scrf=(pcm, solvent=Dichloromethane) nosymm
131. Sort of Fixed: Gnome-screenshot (3.4.1) broken in debian testing -- how to fix it
UPDATE 9/6/2012: It's becoming incrasingly difficult to revert back to the old version of gnome-screenshot, hence the changed title of the post. I can't believe the gnome-screenshot hasn't been reverted back to a more sane behaviour -- any behaviour that leads to a score of bug reports (remember that there's a lot of self-censorship as few people submit bug reports even if they encounter a bug) is highly undesirable. I would not include screenshot in my posts if I hadn't already put a hold on my gnome-screenshot package. Anyway, keep an eye on this one for (a lack of) updates: https://bugzilla.gnome.org/show_bug.cgi?id=669629
Original post
Something weird happened after the updates today (http://verahill.blogspot.com.au/2012/05/todays-3rd-of-may-2012-debian.html). When taking screenshots I didn't get a save dialogue.
I naturally presumed this to be a crippling bug:
gnome-screenshot
Here's the source of it all: http://git.gnome.org/browse/gnome-screenshot/commit/?id=3bbc1e158fd58ec7f4f984f6d3c15ec95e65a035
Links to this post:
http://qfox.nl/notes/153
Original post
Something weird happened after the updates today (http://verahill.blogspot.com.au/2012/05/todays-3rd-of-may-2012-debian.html). When taking screenshots I didn't get a save dialogue.
I naturally presumed this to be a crippling bug:
gnome-screenshot
** (gnome-screenshot:8520): WARNING **: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11. Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Error: Expected type utf8 for Argument 'filename' but got type 'boolean' (nil)
After reading bug reports I noticed that a new screenshot shows up in the ~/Pictures folder -- but you get no dialogue re saving and name etc, so I might be forgiven for thinking that it didn't work at all. Yet, something was clearly out of whack.
A bit of googling led me here https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/929536
which pointed me to this: https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/927952 and this: https://bugzilla.gnome.org/show_bug.cgi?id=669629
Here's the source of it all: http://git.gnome.org/browse/gnome-screenshot/commit/?id=3bbc1e158fd58ec7f4f984f6d3c15ec95e65a035
Yes. The broken behaviour is a design feature. It's idiotic.
I like gnome-shell now that I've customized it. But seriously, what the gnome devs want as default behaviour can only be considered as broken behaviour by any long term desktop user. This new behaviour is idiotic and will only benefit those who don't use screenshot very often -- those who do will definitely want control over where screenshots are saved and under what names.
The worst, intended 'solution':
If I would guess at the intentions of the gnome dev/s, they'd suggest you map your print scrn key to gnome-screenshot -i. This brings up a dialogue. Asking you to select full screen, window or area. You can then click on take screen shot, and you then get the save dialogue. Suddenly it got a lot less convenient. Something that was quick and easy now has become clunky.
The better solution:
I used the snapshot archive:
1. Download the previous version, e.g.
wget http://snapshot.debian.org/archive/debian/20120313T034114Z/pool/main/g/gnome-utils/gnome-screenshot_3.2.1-3_amd64.deb
2. And install
sudo dpkg -i gnome-screenshot_3.2.1-3_amd64.deb
dpkg: warning: downgrading gnome-screenshot from 3.4.1-1 to 3.2.1-3.
3. Prevent the package from being upgraded again:
sudo su
echo "gnome-screenshot hold"|dpkg --set-selections
The behaviour should now be back to usable.
This post contained no screenshots. For obvious reasons.
This post contained no screenshots. For obvious reasons.
Links to this post:
http://qfox.nl/notes/153
Subscribe to:
Posts (Atom)