03 July 2013

472. Briefly: Iranian PhD students in Australia

I'm not going to leave much in the way of a comment, but this doesn't seem to have been publicised enough. Searching the web quickly didn't bring this up at all, and it's a shame since it's important, in particular if you are an Iranian national thinking about doing a PhD in Australia.

About a week ago the faculty in the chemistry department at my university were informed that heavy restrictions in terms of access to instrumentation has been put in place for students from North Korea, Syria and Iran via Federal legislation.


While I don't think there are any students from North Korea or Syria around, there are several Iranian students at different stages of their PhD. In fact, I would say around 50% of our applicants are from India, 25% are from Pakistan and 20 % are from Iran (in terms of accepted students the ratio is very different)


In practical terms, this means that Iranian students in the department are not allowed to use:
FT-IR
UV-Vis
NMR
Mass spectrometers
Raman
dosimeters
OES/AAS
etc.

All of which are standard instruments which most chemists would find necessary to do research. In addition, they can hardly be considered as being cutting edge, trade secrets or anything like that -- commercial NMR instruments have been around since the 1950s, infrared an UV/Visible spectroscopy go much further back. Mass spectrometry is a standard tool which, although many of the current designs only go back to the 1980s (e.g. ESI), is so conceptually simple and innocuous, that (to me) restrictions on it doesn't make sense. And so on.

In addition, supervisors of Iranian students have been asked to draw up a risk management plan to prevent student access to the above instruments, which is a particular problem given that they are used in teaching as well, and are available on a walk-in basis to undergraduate students doing projects in research labs.

Currently, any supervisor who has an Iranian student needing to use any of the instruments above will need to assign another student to do these measurements for the Iranian national.

While this doesn't formally preclude Iranians from coming to Australia to do a PhD, we have been advised that we should reject any applicants at this point. This may change once the university has figured out exactly where they must draw the line in terms of restricting access to Iranians to different facilities, but for now it's a blanket ban.

My personal opinion is that while you'd be led by the media to think of anyone from North Korea, Syria and Iran as potential spies, these are real people too. Many Iranians would either be completely disinterested in politics, or actively antipathetic to their regime. And the best thing about democracies -- we shouldn't have any issues with them supporting their government either. So I don't really agree with this as a security measure to prevent nuclear proliferation, which must surely be the stated goal.

And if the idea is to put in place sanctions to promote regime change, then why limit the type of instrumentation that students can access? Or are we trying to punish the children of the leadership in Iran? Then why not limit the sanctions to those specifically? Top students tend to come from all socioeconomic classes.

The timing is also very odd, given the recent election of a moderate.

And why Iran and not Belarus, China, Zimbabwe etc.?

Again, I don't like putting opinion pieces on this blog (other than as minor parts/rants of posts with actual content) but I think this should be publicized more.



02 July 2013

471. Debian Jessie -- gnome-shell bug

Update 3/7/2013:
there are now *gnome-bluetooth packages (3.8.1-2) in the jessie repos now. While I haven't looked closer at them, I presume that they fix this issue.

(on a different note: dist-upgrade currently removes gnome...)

Original post:
I've used debian testing since early 2011, and I've only had a few minor issues during that time.

However, sometimes things happen that reminds you that the Testing release is not meant for mission critical work (and makes me happy that I only use Jessie on my laptop, which I mainly use at home).

So...

Last night I did upgrade and dist-upgrade, which installed the following packages according to /var/log/apt/history:
Start-Date: 2013-07-01  22:03:17
Commandline: apt-get dist-upgrade
Install: p11-kit:amd64 (0.18.3-2, automatic), libgnome-bluetooth11:amd64 (3.8.1-1, automatic), libgcr-base-3-1:amd64 (3.8.2-3, automatic), libtasn1-6:amd64 (3.3-1, automatic), libgcr-ui-3-1:amd64 (3.8.2-3, automatic)
Upgrade: libnm-gtk0:amd64 (0.9.8.2-1, 0.9.8.2-1+b1), libgcr-3-1:amd64 (3.4.1-3, 3.8.2-3), gir1.2-gcr-3:amd64 (3.4.1-3, 3.8.2-3), network-manager-gnome:amd64 (0.9.8.2-1, 0.9.8.2-1+b1), gnome-keyring:amd64 (3.4.1-5, 3.8.2-2), gcr:amd64 (3.4.1-3, 3.8.2-3), gnome-bluetooth:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gnomebluetooth-1.0:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gck-1:amd64 (3.4.1-3, 3.8.2-3)
End-Date: 2013-07-01  22:03:29

Now what happens when I log in to gnome via gdm3 I get an empty desktop with no menus, no hot-spots or anything else indicating that things worked out. Alt+F2 doesn't work either, and conky doesn't start.

The only thing that does work is
* my keyboard shortcuts (I've mapped ctrl+shift+Down arrow to chromium)
* guake (which starts with gnome)

ps aux|grep gnome-shell
returns nothing, which might be a clue.

Looking at the debian forums the closest post seems to be (although erroneously labelled -- gdm3 DOES start): http://forums.debian.net/viewtopic.php?f=6&t=105393&p=504077&hilit=gnome+shell#p504077

That in turn led to this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712861

My gnome-shell version is 3.4.2-8,

I don't understand how gnome-bluetooth causes this, especially given that I've disabled bluetooth in rcconf, but whatever it takes...

I tried applying the patch but it failed:
mkdir ~/tmp
cd ~/tmp
wget "http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=66;filename=GnomeBluetooth.patch;att=1;bug=712861" -O blue.patch
sed -i 's_js/ui/status/bluetooth.js_/usr/share/gnome-shell/js/ui/status/bluetooth.js_g' blue.patch
sudo patch -p0 < blue.patch

Instead, I ended up making the changes to /usr/share/gnome-shell/js/ui/status/bluetooth.js by hand (remember that you can always use the ttys using ctrl+Fx):
  6 const Gio = imports.gi.Gio;
  7 const GnomeBluetoothApplet = imports.gi.GnomeBluetoothApplet;
  8 const GnomeBluetooth = imports.gi.GnomeBluetooth;
  9 const Gtk = imports.gi.Gtk;

and then delete the Applet part in GnomeBluetoothApplet so that it reads
 38         this._killswitch.connect('toggled', Lang.bind(this, function() {
 39             let current_state = this._applet.killswitch_state;
 40             if (current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED &&
 41                 current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER) {
 42                 this._applet.killswitch_state = this._killswitch.state ?
 43                     GnomeBluetooth.KillswitchState.UNBLOCKED:
 44                     GnomeBluetooth.KillswitchState.SOFT_BLOCKED;
 45             } else
 46                 this._killswitch.setToggleState(false);

Then do it again:
 96     _updateKillswitch: function() {
 97         let current_state = this._applet.killswitch_state;
 98         let on = current_state == GnomeBluetooth.KillswitchState.UNBLOCKED;
 99         let has_adapter = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER;
100         let can_toggle = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER &&
101                          current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED;
102 



At this point I rebooted and everything was back to normal (you can try simply doing 'sudo service gdm3 restart' instead of rebooting).
Anyway, done.

470. Very briefly: compiling nwchem 6.3 with ifort and mkl

This used to be part of http://verahill.blogspot.com.au/2013/07/469-intel-compiler-on-debian.html, but I think it makes more sense making it a separate post.

I did this on debian wheezy.

1. Installing mkl and the compiler
MKL: http://verahill.blogspot.com.au/2013/06/465-intel-mkl-math-kernel-library-on.html
Intel compiler collection: http://verahill.blogspot.com.au/2013/07/469-intel-compiler-on-debian.html

I will henceforth presume that you have put the files in the same location as shown in those posts, and that you have created /etc/ld.so.conf.d/intel.conf as shown in the second post.

2 Compiling nwchem 6.3
sudo apt-get install build-essential libopenmpi-dev openmpi-bin
sudo mkdir /opt/nwchem -p
sudo chown $USER:$USER /opt/nwchem
cd /opt/nwchem
wget http://www.nwchem-sw.org/download.php?f=Nwchem-6.3.revision1-src.2013-05-28.tar.gz -O Nwchem-6.3.revision1-src.2013-05-28.tar.gz
tar xvf Nwchem-6.3.revision1-src.2013-05-28.tar.gz
mv nwchem-6.3-src.2013-05-28 nwchem-6.3-src.2013-05-28.ifort

export NWCHEM_TOP=`pwd`
export LARGE_FILES=TRUE
export TCGRSH=/usr/bin/ssh
export NWCHEM_TOP=`pwd`
export NWCHEM_TARGET=LINUX64
export NWCHEM_MODULES="all"
export PYTHONVERSION=2.7
export PYTHONHOME=/usr

export BLASOPT="-L/opt/intel/composer_xe_2013.4.183/mkl/lib/intel64/ -lmkl_core -lmkl_sequential -lmkl_intel_ilp64"
export LIBRARY_PATH="$LIBRARY_PATH:/usr/lib/openmpi/lib:/opt/intel/composer_xe_2013.4.183/mkl/lib/intel64/"

export USE_MPI=y
export USE_MPIF=y
export USE_MPIF4=y
export MPI_LOC=/usr/lib/openmpi/lib
export MPI_INCLUDE=/usr/lib/openmpi/include


export LIBMPI="-lmpi -lopen-rte -lopen-pal -ldl -lmpi_f77 -lpthread"
export ARMCI_NETWORK=SOCKETS

cd $NWCHEM_TOP/src

make clean
make nwchem_config
make FC=ifort 1> make.log 2>make.err

cd $NWCHEM_TOP/contrib
export FC=ifort
./getmem.nwchem

And it works quite fine. See e.g. here if you want to patch to allow to compile with python, and to support gabedit.

3. Performance
This is always a bit contentious, and I want to be upfront with the fact that I haven't spent much time considering whether my test example is a good one. I simply did a geo-opt + vibrational analysis as shown in this post: http://verahill.blogspot.com.au/2013/05/430-briefly-crude-comparison-of.html

The jobs were run using all cores available on that node.
gnu= gfortran + acml 5.3.1 for the Phenom and FX8150, and openblas for the i5-2400 and the Athlon 3800+..
ifort= ifort + mkl for all architectures.

The times are in seconds and are CPU times, not wall times.

Arch|                   cores  gnu      ifort Instruction sets
-------------------------------------------------------------------------
AMD Athlon 64 X2 3800+:   2    10828*    12516  sse, sse2, sse3
AMD Phenom II X6 1055T:   6    2044       2048   sse, sse2, sse3
AMD FX8150            :   8    1611       1507   sse, sse2, sse3, AVX, FMA4
Intel i5-12400        :   4    1652*      1498   sse, sse2, sse3, sse4,AVX

In the last case I also compiled using gfortran but with mkl and got 1550s.

It's a fairly small sample set, but it does seem that there's a little bit of an advantage with mkl+ifort over gfortran+acml on the newest AMD core. One would need much more data though.

A clear downside of using mkl and ifort is the fact that they are not freely available though -- i.e. you can register and download them for free for non-commercial use, but there's no guarantee that your colleague, next-door-neighbour or distant-cousin will be able to use it.