[GRASS5] GRASS on OpenMOSIX cluster

Glynn Clements glynn.clements at virgin.net
Mon Jan 13 20:00:33 EST 2003


Markus Neteler wrote:

> at time I am trying to run GRASS on a 20 node OpenMOSIX cluster.
> The task to perform is to 'i.smap' 230 aerial images with 3 bands
> each (later I'll try an improved method).
> 
> The main problem is that the various jobs seem to influence
> each other (especially the current region). The result is
> 
> - probably correct CELL files
> - damaged cell_hd files (zero size with a few exceptions)
> - damaged color files (zero size with a few exceptions)
>   (after i.smap I use r.colors)

> I am a bit in the dark where to search for the problem/solution.
> I remember that it was discussed once if two/multiple sessions of GRASS
> are possible, but I cannot find that thread.

For the most part, you can run multiple sessions provided that they
each operate upon a different mapset. The primary exception is that
using monitors is problematic (monitor names are per-uid).

Having multiple sessions using the same mapset is high-risk. It could
theoretically be done, but to be safe, you would have to analyse the
behaviour of each command which is intended to be used to ensure that
no two processes attempt to modify the same file. The most likely
cause of conflict would be the WIND file.

For your specific case, SEARCH_PATH (written by g.mapsets) would also
be an issue. I don't know enough about the imagery programs to know
whether there would be any issues there.

One change which would allow conflicts to be reduced would be to
eliminate the use of getuid/geteuid/getpwuid, and use $USER/$HOME
instead. Relevant files include:

	src/libes/gis/mapset_msc.c
	src/libes/gis/set_prior.c
	src/libes/gis/user_config.c
	src/libes/gis/whoami.c
	src/libes/vask/V_support.c
	src/general/g.help/menu.c
	src/general/init/chk_dbase.c
	src/general/init/clean_temp.c

This would also be useful for Mike's work on a native Windows version.

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-dev mailing list