[GRASSLIST:3396] Re: Running Grass on a Mosix cluster?

[Glynn Clements]

Antonio wrote:

> Let me figure this out. You mean that if I run r.suf.countour on a 20
> million cell file (20 days on a 450Mhz processor) I can't benefit from
> mosix or multiprocessor cluster?

No, nor will you benefit from a conventional multi-processor system.

> And if I run two instances of
> r.surf.contour then mosix will send one of them to a free node of the
> cluester?

I believe so.

> However I think that a big suite like Grass needs MP. If it is to be a
> full open sourced spirit program it must be accessible also to those who
> do not have the money to by super powerfull dual processor systems. Lets
> think on how important Grass can be for the developing countries. Yet in
> those countries there is surely no possibility to have access to very
> powerfull hardware. Only clustering small hardware can give access to
> readonable computing power.

Note that multi-processing is only useful for algoriths which are
"parallelisable". Even then, clusters are only practical for cases
where you can easily partition the data, and process the individual
blocks separately. Some parallelisable algorithms are only practical
on conventional MP hardware, where multiple CPUs have direct access to
common memory.

r.surf.contour is probably an easy case. You should be able to
partition the input data into tiles, process each tile separately,
then patch the results together. You would probably want to have some
degree of overlap, and "blend" the values within the overlapping
areas.

> Is the Grass Developing team considering the possibility of integrating
> MP on some of the Grass programs? Maybe those who need a lot of
> computing like the above mentioned r.surf.contour ....

For cases like r.surf.contour, it might be feasible to produce a
generic "manager" which partitions the data, runs multiple instances
of a program, then patches the results together.

For algorithms which don't have similar "locality" properties, the
problem is significantly more complex, and isn't likely to be
addressed soon.

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