Keeping old data alive, building CERNLIB

Updated 28/4/1016 with additional link and clarification

Analysis of the data from the ZEUS experiment was performed using Fortran programs. These used the CERNLIB software libraries and data was stored in structures known as Ntuples.
I used Column-wise Ntuples, which are saved in a binary format. So when at the end of my Ph.D. analysis, I saved the old Ntuples to 11 CDs these became largely useless immediately I left Physics.
The Digital dark age therefore came to me sooner than I anticipated.
Fortunately with the source being made freely available and the necessary compilers being included in gcc I thought I'd have a try at building these on my Linux laptop.
At the time of this exercise I was running version 11.10 of Ubuntu.
Here are the steps I took, based on instructions from this page. One major issue I had with Lubuntu was that many of the dependency packages were not installed and I had to discover and apt-get them all. For this reason it's better not to try this on a cut down Linux.

• Install gfortran (this is part of gcc, I have version 4.6.3)
• Copy and unpack the CERNLIB binaries
• Because I had a cut down Linux, I needed to build LessTif
• Get xutils-dev package for imake
• Set up the  build environment
   cd to the cern folder
   ~$ export CERN_ROOT=CERN_PATH/VERSION
   ~$export CVSCOSRC=$CERN_ROOT/src
   ~$mkdir$CERN_ROOT/build
   ~$cd$CERN_ROOT/build
   ~$export PATH=$CERN_ROOT/bin;$PATH

• Update $CVSCOSRC/config/linuc.cf This file has some operating system specific information, I changed the following
  • #define hasgfortran
  • Change CcCmd to gcc
  • Check #define X11Includes
    This needs to point to the location of the X Window headers, these can be installed using

    sudo apt-get install xserver-xorg-dev

• Run $CVSCOSRC/config/imake_boot to create the Makefile from the imake files
• Run gmake bin/kuipc to build kuipc – this is built to /cern/new/bin
• Add kuipc to path because this is required for the next build
• Run gmake 

When I finally succeeded I was able to write a simple Fortran program that was able to load my old ntuple files.

A couple of other tips

link gmake to make using sudo ln -s /usr/bin/make /usr/bin/gmake

 

Problems and errors

There were a couple of errors in the main build that needed fixing:

#1

Conflicting types for _XmDrawShadow /usr/local/include/xm/DrawP/h Previous declaration is obsolete

Fix: Remove _XmDrawShadow(); from iconwidget.c

 
#2

Pawlib/paw/cpaw/bugrep.c L_cuserid undeclared.

Fix: It should be in <stdio.h> but add #define L_cuserid 9 in the file

Finally, Liblapack3.a is required for PawX11

Fix: Download and build BLAS & LAPAC

Of course now in 2015, CERNLIB is available from the Ubuntu software manager.

Linux on a new Dell Laptop

I've now got a new Dell Inspiron Laptop (Woo hoo!) and decided to set it up to dual boot Linux and Windows 10.

This post is really for my own reference and benefit, although lessons learnt may well be more widely useful.

Installation

I decided to install Linux Mint with Cinnamon. This was really quite painless.

The drive has approx 1.8 TB of useable space, so I shrunk the Windows C: drive to just over 1TB leaving about 750GB for Mint.

To do this, I entered Disk Management into the windows search box which matched with "Create and Format hard disk partitions" as best match.

Open up this tool, right click on the C:\ drive and select Shrink Volume...

I also needed to disable secure boot in the BIOS. This was easy, simply restart the machine hit F2 on start-up. Then when the BIOS configuration screen appears, navigate to Secure Boot and check disable.

I'd previously created a Linux Mint DVD from the Linux mint downloads page. To boot the Linux disk, restart and hit F12 on start-up.

This should start the LiveCD version which has a desktop icon to install. Double click on this and start the installation.

The important point comes when you are prompted to select the Installation type. At this point check "Something else"

You now enter the screen to manage partitions, select the free space from the earlier shrink and click on +
You will be presented with a dialog to configure the partitions, I created 3 (Repeat the process in this order)

• 50GB Logical for the Linux core, Root : '/'
• 690 GB Logical for Root: 'home/'
• The remainder for Swap, about 7GB

Then run the install. This asked for a few configuration settings, for example Wifi login and language settings. Wait about 15 minutes and finally reboot.

The last thing I did was to run sudo-apt get update and sudo apt-get upgrade to bring the packages up to date.

Video driver

My graphics card is an AMD Radeon R5 M335. This seems to have been released in October 2015 and at the time of writing there were no proprietary Linux drivers for this.

The open source AMD driver doesn't seem to handle the card either. I get the following pop-up on the desktop and errors are shown in the logs (obtained using the dmesg command)



dmesg | grep drm

returns the following

[    1.759698] [drm] Radeon Display Connectors
[    1.759763] [drm] Cannot find any crtc or sizes - going 1024x768
[    1.761755] [drm] fb mappable at 0xC0242000
[    1.761756] [drm] vram apper at 0xC0000000
[    1.761757] [drm] size 3145728
[    1.761758] [drm] fb depth is 24
[    1.761758] [drm]    pitch is 4096
[    1.761942] radeon 0000:01:00.0: fb1: radeondrmfb frame buffer device
[    1.796379] [drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed
[    1.796420] [drm] Initialized radeon 2.39.0 20080528 for 0000:01:00.0 on minor 0
[   21.908902] [drm] probing gen 2 caps for device 8086:9d10 = 1724843/e
[   21.908908] [drm] PCIE gen 3 link speeds already enabled
[   21.911907] [drm] PCIE GART of 1024M enabled (table at 0x0000000000040000).
[   22.488470] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
[   22.488474] [drm:si_resume] *ERROR* si startup failed on resume
[   22.489091] [drm:si_dpm_set_power_state] *ERROR* si_upload_sw_state failed

But Linux is reverting to Intel graphics

lspci  | grep VGA returns  00:02.0 VGA compatible controller: Intel Corporation Device 1916 (rev 07)

The machine seems to be working well at the moment so I'm not too worried about this. (I'm not interested in heavy graphics work on this machine) I'll keep a look out for news and will post any updates I see to this page.

Robot Arm - Full Control

Last time on the Robot Arm project, I was able to control two of the motors on the arm from a Raspberry Pi using a single Arduino and motor shield.

The arm however has 5 motors so this does limit what I can do with it. I decided to get a new Arduino and Motor shield and add them to the project.

The new motor shield is a cheap build of the old Adafruit motor shield. This requires different code to control from the previous post. A more detailed description can be found here.

The new Arduino is a standard Uno board.

I got lucky here, because when I plugged it into the USB hub it is recognised at /dev/ttyACM0, the old board was recognised at /dev/ttyUSB0. (It also appears as Arduino Uno, instead of Arduino Diecimila or Duemilanove w/ ATmega168 in the Arduino IDE.)

This allowed me to use both easily with the following design:

No matter how I plug the Arduinos into the hub, or which order, I can still reliably address each one independently.

The python script needed two lines changing to allow me to send the same character to both Arduinos. They each ignore characters intended for the other one.

import termios, fcntl, sys, os, serial

arduino1 = serial.Serial('/dev/ttyUSB0')

arduino2 = serial.Serial('/dev/ttyACM0')

fd = sys.stdin.fileno()

oldterm = termios.tcgetattr(fd)

newattr = termios.tcgetattr(fd)

newattr[3] = newattr[3] & ~termios.ICANON & ~termios.ECHO

termios.tcsetattr(fd, termios.TCSANOW, newattr)

oldflags = fcntl.fcntl(fd, fcntl.F_GETFL)

fcntl.fcntl(fd, fcntl.F_SETFL, oldflags | os.O_NONBLOCK)

try:

    while 1: # This is a tight loop with high CPU

        try:

            c = sys.stdin.read(1)

            # repr() : Return a string containing a printable

            #    representation of an object

            arduino1.write(c)

            arduino2.write(c)

            print "Read character from stdin", repr(c)

        except IOError: pass

finally:

    termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)

    fcntl.fcntl(fd, fcntl.F_SETFL, oldflags)

The full code can be found on GitHub: https://github.com/jscott7/Robot-Arm.git

ZEUS Safety Shift - Part 2

Previously I introduced the ZEUS safety shift, a duty performed mainly by the Ph.D. students who worked with the Particle Physics detector. Now to go on the walk round!

The first step I took was to return back up to the ground floor to check the gas mixing rack (the panel just to left of centre). Here you would check the pressures on various manometers. A process for dealing with any deviations from norms was provided.

Turn 180 degrees and look back. Here you can see the pipes heading off on their way to the Pit. The corridor here leads back to the main entrance doorway (seen from the outside in the earlier post).

Now I would take the lift down floors to the 6th floor, actually 2 floors underground. Go through some doors in front of me out of the lift and I ended up in a large machinery space.

The yellow line on the floor is a fluorescent paint that guides you to the exit in case of a power cut. Turning off the lights resulted in the room being bathed in a eerie glow from this and various indicator lights. This could easily be a set for a sci-fi movie!

Following the line to the silver door in on the far wall, I would turn the corner and see my next target in the gloomy distance.

These were the calorimeter power supply units. The safety check here was to ensure the temperatures remained within safe bounds.

The large air conditioning ducts to the left in the earlier picture also had a habit of making a noise that sounded just like something scuttling through them, just to add to the atmosphere.

As an aside, the 6th floor also had the electronics lab where I spent quite a few hours analysing components of the tracking detector trigger using the test bench seen below.

My next task was to re-enter the Pit and check the far side of the detector, this involved passing under the beam through this concrete lined tunnel

The back of the detector was certainly more cramped than the other side.

The primary check here was to check gas flow through a bubble gauge, the yellow cabinet just to left of centre

I would then make a walk around the front of the detector to perform general checks before the final destination on the round which was inside the Rucksack. Here we would check on the trigger components.

An interesting, and fortunately rare, issue here was that the electronic cards would gradually ease themselves out of their sockets over a period of time due to vibration from the cooling fans. On one of my last shifts, I was on duty with a senior member of the collaboration who hadn't been shift leader for some time. Early on in the night he noticed a problem with the data from the detector that was serious enough to consider turning of data collection entirely. He asked me if I'd seen it before and while I hadn't seen those particular symptoms I said I'd head off to the Rucksack to check it out.

When I got there, I simply gave every card a push. I returned to find all was well with the data. (I remember giving a suitable vague and complex explanation)

And that was it, back to the control room for another couple of hours working on analyses until your next walk round.

I think this sign nicely summed up the end of 8 hours underground. Warning, Danger of Health!