OpenSolaris on a motherboard with MCP65 chipset

So, just installed OpenSolaris on a Gigabyte motherboard with MCP65 (NVidia) chipset.
Everything worked out of the box except for the NIC, where the Device driver utility said a third-party driver was needed.
Web search has shown there is an alternative driver, but that as well, the device might be supported by the nge driver. All necessary to do was to make an alias for the driver and plumb the interface. To my slight surprise the network daemon took over and configured the device via DHCP.

Steps needed:

1. Get PCI ID of the card (explanation here or here):
   prtpicl -v | less
   ...search for Ethernet or 0200 and get the right PCI ID.
   
2. Add the driver alias, load driver etc.:
   update_drv -a -i 'pci1458,e000' nge
   (if ok, says nothing)
   
3. See if the interface is there
   dl-adm show-dev
4. Plumb the interface (this might be helpful)
   ifconfig nge0 plumb
5. It's up. Well?
   

VMware ESXi server

The bloody thing does not boot at all at our quad-core opteron setup.
Or even better, the setup boots and complains about no storage to write to.
We're not first to see this, though :-(

Links:

1. http://www.grid.org/blog/cameron/development-using-vmware-server-esxi
   

Remote Gnome session in nested window

I needed to access remote Gnome session (actually a JDS session) to try something with the settings. That is - I needed something like the "Remote desktop" setup on Windows. One way is to setup VNC (but that's extra effort with no sense). Second might be IPsec with XDCMP or and VPN (ok, even more extra effort...). So the chosen way was to tunnel X through ssh.

To do this with a standalone X server, you need to start X, run SSH with correctly set up display and start gnome-session script on the remote side.

1. Way:
   xinit -e 'ssh -X who@where gnome-session' -- :1
   This works reasonably, but always somewhere have the "login window" where the gnome-session was started. Pro - you see the errors, con - if you close it, the session dies.
   
2. Way:
   Add xauth data for the display, then start a nested X server and then xterm, which starts a SSH session and exits then. The SSH session keeps running on background and the session looks "normal"
   
   xauth add :1 `xauth list | grep localhost.localdomain/unix:0 | cut -d ' ' -f 2-`
   Xnest -auth .Xauthority :1 -geometry 1024x700 & xterm -display :1 -e ssh -X -f bobr7.fjfi.cvut.cz gnome-session
   
3. The same, just with normal X-server, not Xnest. Maybe a delay will be needed before X-term start?

Further reading:

1. http://www.technovelty.org/linux/tips/xnest.html

Using "Sistema koordinat 1942" with Garmin GPS

The GPS setup is a bit non-exact, giving differences against OziExplorers S-42 setup between 2-10 m. This should pose no problem for "where am I on the map", however.

How to setup an eTrex Legend:
Setup/Units/Position format = User UTM Grid, data same as in OziExplorer, so:
Longitude origin E45 deg
Scale: 1.000
False easting: +8 500 000 m
False northing: 0 m

Map datum = User
I used setup for Kazakhstan from the wgs84fin report:
dx = +15 m
dy = -130 m
dz = -84 m
da = -108 m
df = 0.00480795

Values here depend on where you are, see pages 120 and 121 of the mentioned report.
Errors/differences from what OziExplorer states as User grid coordinates vary depending on where the point is.

For systems used in Czech Republic, see http://tvorbamap.shocart.cz/kartografie/systemy.htm as well.

Links:

1. Pages 120 and 121 of the wgs84fin.pdf report, see http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf
2. http://www.kmp.vslib.cz/lide/hrus/prispevek.php?klic=070113234207
3. http://www.navgeocom.ru/support/coords/index.htm
4. http://cs.wikipedia.org/wiki/Krasovsk%C3%A9ho_elipsoid
5. http://etrex.webz.cz/
   

OziExplorer - using exUSSR military maps in the Georgia region

I needed to use exUSSR military maps for Georgia (Caucasus) together with a Garmin GPS and OziExplorer.

What I gathered as for now, the maps:

1. Probably use Krassovski ellipsoid
2. Use the Transverse Mercator projection

Steps to load and calibrate the map in OziExplorer
This was done with a registered version of OziExplorer, v3.95-4q and a scanned 1:100 000 map K-38-038 of the Lentechi region in Svaneti, Georgia.

1. Open the scan using "Load and calibrate map image" menu item.
2. Set up the map datum - the map says that it's in the Coordinate system 1942. There are three systems that give similar results in OziExplorer, I used the first Pulkovo (1) system:
   
   I left the Mag Var (magnetic variation) empty.
   
   Small update: It seems that the values better agree with what the GPS will give if the S42 is used instead of Pulkovo map datum. This gives differences about 2-10 meters (which is OK in most cases for me).
   

1. Set up the map projection is more tricky. The map uses Transverse Mercator with zones six degrees wide. That is, to make a planar projection of the ellipsoid on a certain place, the globe is sliced into "zones", where each zone has a central meridian and +/- 3 degrees on each side. Units used are (exactly?) equivalent to meters (this is the "scale factor thing") and there is a square grid on the map, where each cell 2 km times 2 km.
   To determine the right zone I used information from http://gpsinformation.net/main/warsaw.txt page by Jacek M. Holeczek . The most important information is (quoting):
   
   

   
   The Reference Ellipsoid is :
   Krassovsky (Krassovskiy) 1940
   The grid is (S-42) :
   Transverse Mercator (Gauss-Krueger type) in zones 6 degrees wide:
   in longitude range 12.0 East - 18.0 East : zone 3
   in longitude range 18.0 East - 24.0 East : zone 4
   in longitude range 24.0 East - 30.0 East : zone 5
   Latitude of Origin: 0.0 North
   Longitude of Origin:
   in longitude range 12.0 East - 18.0 East : 15.0 East
   in longitude range 18.0 East - 24.0 East : 21.0 East
   in longitude range 24.0 East - 30.0 East : 27.0 East
   Scale Factor at the Central Meridian: 1.0
   Units to meters conversion: 1.0 (GPS set to metric system !!!)
   False Easting at Origin:
   in longitude range 12.0 East - 18.0 East : +3500000.0m
   in longitude range 18.0 East - 24.0 East : +4500000.0m
   in longitude range 24.0 East - 30.0 East : +5500000.0m
   False Northing at Origin: 0.0m
   

   
   Derived from this, as the coordinates on our map are 42 deg 30 min on the left side, we need zone 8. It spans from deg. 42 to 48 E, the central meridian would be 45 and the false easting (that is the shift to get the numbers right (?)) is 8500000 (zone + 500000). The false easting makes sure the numbers are non-negative. False northing is zero as we are on the northern hemisphere.
2. Calibration of the map can be done either in latitude/longitude coords using the info at the map corners, or using the numbers on the map grid (which is 2x2 km). If you use the map grid, you also get a cross-check if you did the map projection setup right - you would get a nonsense lat/lon info if not. Note that the numbers you enter are in the TM units (e.g. meters), so 1000x what you read on the grid.
   
   
3. Switch on the grids to see if everything is OK. This is done via the Map/Grid Line Setup menu item. For suggested configuration see the images below. It might be necessary to select/unselect/select the Auto scale to actually get a visible grid.
   
   Now you should have a calibrated map with both grids active and correctly set up. Note that the display datum should be set to User grid, not UTM.
   

This is about the OziExplorer setup. Now the question is, how to setup the Garmin GPS accordingly. The goal would be to be able to get a position in the 1942 grid from the GPS and be able to easily locate oneself on the map.

MPI parallelization of MCNPX 2.5.0 on AMD64

So finally we have MCNPX-2.5.0 running with MPI parallelization. This is just to write down some of the problems and the solutions (before we forget what was the point).

The target platform was Centos 4 system on AMD64 based SMP machines. The build was always done in a directory outside the original source tree.

Compiling the code without MPI:
Using Intel 10.1 compiler collection:
Linked f90 and cc to icc and ifort. Configure called as:
/usr/local/src/mcnp/v250/configure --prefix=/share/apps/mcnpx-2.5.0 \
--with-FC=ifort \
--with-CC=icc \
--host=i686-pc-linux

It is necessary to use the host specification as the x86_64 platform is not recognised otherwise.
Intel compilers were used later on. To get tests running, go to Test dir in the source dir and:

ln -s Test.intel.linux.ifc.icc Test.intel.linux.ifort.icc

This is necessary as well for the other compilers.

Using Sun Studio 12 compiler for Fortran 90 and gcc 3.4.6:
The code compiled OK, just it was necessary to link f90 and cc to the Sun compilers (I linked f77 as well, but that is probably not necessary).

Using gfortran 4.1.2 and gcc 3.4.6:
There are some issues with GNU gfortran - after changes to the code described in http://mcnpx.lanl.gov/opendocs/installation/Intel-GCC_Linux_64.txt the code got compiled, but it crashed with segmentation fault even during make tests. I did not explore the issue further. I linked f90 -> gfortran before make, but it was maybe not necessary.

Called configure as:

.../v250/configure --prefix=/usr/local/mcnpx \
--with-FC=f90 \
--with-CC=cc \
--host=i686-pc-linux \
--with-FFLAGS="-DUNIX=1 -DLINUX=1 -DG95=1" \
--with-CFLAGS="-DUNIX=1 -DLINUX=1"

Adding MPI:
This part I tried only with the Intel compilers. I took MPICH 1.0.6 and compiled from sources, installed in a cluster-wide shared directory.

Run configure as:

/usr/local/src/mcnp/v250/configure --prefix=/share/apps/mcnpx-2.5.0-mpich2-64bit \
--with-FC=mpif90 \
--with-CC=mpicc \
--with-FFLAGS="-i8" \
--with-NOCHEAP \
--host=i686-pc-linux \
--with-MPILIB="-L/share/apps/mpich2-1.0.6/lib -lmpich"

Unfortunately, make broke with error stating something about EOF when looking for '"'. There were -lrt" strings in Makefile.h in src subdirectories. We corrected this by:

find ./ -name Makefile.h -exec ~/do.sh {} \;

where the do.sh was:

#!/bin/bash
CO=$1
cp $CO ${CO}.old
sed 's/lrt"/lrt/g' <${CO}.old >$CO

After this the code compiled OK, however when trying to use Tomas Vrba's large lattice file in a MPI environment, mcnpx failed with "Segmentation fault". The code run with smaller input files.

We did not find any notes about such problem. Finally we realized that the system has stack size limit set to ten MB in bash - setting to unlimited (ulimit -s unlimited) solved the problem.