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.

Desire

This is actually a local joke. You will probably not get the point if you live in other country. You may not get the point even in case you live in the same country...

VMware, USB and BSOD in an Windows XP guest system

Ha, I am happy this has so easy solution under Linux :-)

When you attach an USB 2.0 device to a VMware virtual machine running Windows XP, you almost surely get the BSOD.

VMware proposes to attach a USB 1.1 hub to force the device to use the USB 1.1 mode (classical Windows solution?).

But under Linux, you may just unload the ehci_hcd kernel module responsible for USB 2.0, VMware virtual controller does not get confused and the device works like a charm (but slow).

More detailed explanation:

Let's assume you have a computer with USB 2.0 controller and a guest Windows XP system under VMware. When you attach an USB 2.0 device to the controller and some software starts using it, there is a big chance you get a BSOD in few moments.
Actually - for some devices like Canon PTP cameras each time you attach them.

Core of the problem is that the USB virtual controller in VMware is only USB 1.1 capable.

There is response in VMware forums to this problem stating: One workaround is to get a USB 1.1 hub, and plug the USB2 device into the USB 1.1 hub instead of directly into the computer, then the host will see it as a USB 1.1 device instead of USB 2 and it will likely work better.

Ok, so you should carry a notebook, camera and an USB hub. No, thanks.

However, under Linux there is an easier solution - two kernel modules take care about handling USB device - ehci_hcd and uhci_hcd (as for my 2.6.18). The first one is just an extension of uhci_hcd (USB 1.1) to USB 2.0. If you do a rmmod ehci_hcd prior to attaching the device, your system will respond as with an USB 1.1 controller.

At least for a Canon S3 camera this helped. Sure, if they finally port the remote capture utility to Linux, that would be better...