tricks and treats..

Here are a few 'postit' type notes that will come in handy. I will keep adding to this list whenever I catch a fish or two to add :

NMRSim installation

• When you install TS1.3 or TS2.1 in a EL 5 or Fedora 10 like environment, you might get a complaint from NMRSim that it is not able to find : /usr/lib/X11/app-defaults.  Simply do this :
• ln -sf /usr/share/X11/app-defaults /usr/lib/X11/app-defaults
• Now reinstall NMRSim and the error will evaporate away.  

curdir and write permisssion :

• Whenever you install a newer version of TS or XWIN, it often happens that the write permissions for the tree is changed en masse to a given user like nmrsu. It important that many of the directories need to have write access for all users for normal operation, on one hand, but a global write is a bad choice from security viewpoint, on the other.  You can create a separate group for all the NMR users involved and chgrp the tree to that special group and provide write permission for the tree and this is an acceptable solution. 
• But, there is one directory, i.e. $TSHOME/prog/curdir/$nmruser, for which this does not work i.e. the respective nmruser needs to be the owner of this branch of the tree.  So, you must remember to chown the curdir/$nmruser to nmruser:nmruser for proper fucntioning of TS for that user's login. Also, don't forget the '-R' switch while you do this.

smoking out the port on which the CPRserver is running - the easy way..

• Let me add that this tip is relevant when you are not  sitting at 'the spectrometer' console. If you are, simply enter hist on command line and find out the port number from there. But, if your spectrometer is in planet Mars and if you are at your desk, travelling back and fro is a bit trying.  That is where this tip becomes quite useful.
• First of,  ssh into the remote host.
• Then,
• cd /opt/topspin/prog/curdir/current TS user
• cat CPR.ref
• The text output of CPR.ref will show a string such as :  corbaloc:iiop::5500/CPRMsg
•  5500 is the port number on which the cpr server is running, according to the above output.

restarting the dataserver 

• It might  happen that the data tree could not be opened sometimes (in the local TS session). If so, you can enter the command dataserver and this will launch another fresh dataserver thread. You can access the tree then on.

about remote connections 

• If you are connecting to a remote TS server with a client, you have to make sure that the port into which you are connecting on the server is indeed the port at which the server is listening. To find this out, refer to the "smoking out the port on which the CPRserver is running" above.  If your remote connection is disabled from within Topspin on the remote server, you should enable the same by going to the Preferences - Misc - remote connections section.  You must restart Topspin on the remote server for your connection from a client to succeed.  

to kill ...license

Here is a simple trick that will come in handy for testing purposes.  It starts with the question :  will I be able to mimic a running Topspin host's configuration on a testbed machine so that I can install and run Topspin on this testbed without the need for a seperate license file i.e. by spoofing the testbed to be the original host in question.  The answer is yes and there are three important points to take care of :

• You must copy over the license.dat of the TS host into the testbed to the relevant location. 
  
• You must have a valid 'hostname' in the license.dat.  Since it is legal to chage this entry, you can set this to the testbed's hostname, specifically, to the name that is returned by `hostname` on the shell.
  
• You change the MAC id of the NIC, usually eth0 to that of the TS host, like so: 
• ifdown eth0
• ifconfig hw ether AA:BB:CC:DD:EE:FF  (where the MAC Id typed is the same as that of TS host).
• ifup eth0

  You might get an error message about the fact that the true MAC id and the spoofed one are different and the NIC may not come up at all.   Also, the MAC id spoofing is temporary and if you restart the network daemon, it reverts to the original.   For these two reasons at least,  this shortcut to inheriting an existing TS license is only a temporary indulgence.  But, this will come in quite handy to test run Topspin on the testbed, without imposing any down time on a running spectrometer.

Ok, let us wrap up the protocol fully :

• /etc/init.d/bruker_lmgr stop
• /etc/init.d/brker_lmgr start
• Now you can check under /usr/local/flexlm/Bruker/licenses, that the flexlm.log does show the daemon starting without any errors. 
• If you start topspin now, you should be able to get to the interface without any errors. 

As a closing thought, I will say this. In principle  you can exploit /etc/rc.local  to switch the MAC id after boot up and then restart lmgr to mimic the whole thing said above, in an automated fashion. But, since the NIC functionality is not expected to be smooth (as per my understanding thus far), this may not be a solution you look for on a permanent basis, anyway.

Printing active Topspin window works...now

TS2.1 PL4 was not playing well with RHEL v5.3, when it came to printing an active spectrum window onto the default printer.  The workaround was to use the XWINPLOT equivalent, which is invoked by 'plot' on the command line.

I confess that, although I sing the praise of XWINPLOT's virtues to new users, which  the software does deserve, after I started using the window dump feature of Topspin for a Q&D (i.e. quick and dirty) hard copy output, I find XWINPLOT to be a bit heavy.

I was getting a 'null attribute' error when I tried to dump the active window using ctrl+P and Brukerland asked me to check if I defined the default printer correctly. Yes I did, indeed, but to no avail.

What worked finally was this.

• Install the latest jre i.e. jre-1.6.0-sun, to be precise, at the time of writing.
• Soft link the same i.e. /usr/bin/java, again to be precise, to /opt/topspin/jre/bin/
• Hold it ! Before you go gung-ho, backup the java binary under the topspin tree to something recognizable like java.original and then do the above. Sure, I did not do this the first time around. The soft link did not fire up TS and I realized too late that the orignal java binary is gone.  I had to reinstall TS because of this. Although this is only a precaution, you can save the effort of finding the TS DVD and installing it, in case something goes wrong. See next bullet.
  
• By the way,  don't be over-zealous and go and link up the binary of the installed jre, which resides as : /usr/lib/jvm/jre-1.6.0-sun/bin/java. (Obviously, I tried this and screwed things up).   If you query for whereis java, you get the answer as :  /usr/bin/java.  Although /usr/bin/java is a link to another symlink that eventually points to the binary, you simply link /usr/bin/java to $TSHOME/jre/bin/ 
• Everything should work fine after this. I am able to do a screen dump without issues. 

Problem solved...

AU program compilation issues

I dwelt earlier on the shared library issues with Topspin because of the 64 bit cyberworld in my workstation not able to emulate the 32 bit environment properly. The remedy was installing the 'needed' 32 bit libraries. The devil is indeed lurking in the 'needed' word. One of these days I will add the list of libraries I installed in another post (i.e. after FC10 crashes again,....:-{ ]

A related problem is compiling the AU programs from within Topspin. Since these are at the heart, C programs, they do need all your 'gcc' muscle to compile, which is what the command like 'cplbruk ' initiates by passing the appropriate call to the gcc.  Convenient yes, but we cannot switch on or off any extra options sent to gcc.  This means that, the compiler and all the libraries it needs (mostly the 32 variety) should be there.  There is no easy way to pass different path name, for instance, as you would do in a 'configure' step that typically precedes the 'make'.  


Ok, for Topspin this is what you do :

yum install glibc-devel.i386 

 AU program compilation works after this flawlessly  (...gulp....)  so far !

Lessons Learnt : Topspin Quirkies

Although Topspin need not be blamed for it, I can at least resent the fact that it is not 'forward looking' in that, out of the box the software cannot be installed on a 64 bit system and used.

The main problem, it turns out, is the fact that the software expects everyone on the planet to use only a 32-bit operating system with the shared libraries that come with it. This expectation is quickly getting outdated as 'quad core' technology is already showing up in personal computers.   Ok, back to the point.  What was needed to make Topspin work on my Intel 64 bit /Fedora 10 distro ?

1. After installing, start TS, which will dependably crash, complaining that such and such shared library is corrupt. You can identify a 'family' of the library from the error message like "libXsomething.so.2". 
2. With yum make sure that you can list a set of packages correponding to the above library family.  example : 
1. yum search libX
3. Once you confirm that the repository has what you need, simply install the .i386 version of the entire list of packages that yum displayed above for you: 
1. yum install libX*.i386 -y
4. Now, fireup TS again, expect it to crash again, look at the next set of libraries that are missing and loop through the steps 1 to 3 above. Do this, until, you can make Topspin stand on its two (perhaps wobbly) legs.   That's it.

I preferred to list this quick and dirty method instead of recording all the specific libraries I installed to make TS work, because, at the end, the former will turn out to be the more efficient approach if you were ever to resurrect your OS and install TS again (which, from my past experience, will certainly happen).