Is anyone familiar with r.li?
How easy would it be to get rid of the (Unix-specific) client-server
framework so that the various r.li.* modules are just normal modules?
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Jan 25, 2010 at 7:58 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Is anyone familiar with r.li?
... as a user ...
How easy would it be to get rid of the (Unix-specific) client-server
framework so that the various r.li.* modules are just normal modules?
The idea is to have multi-core support which works. If that
could be maintained (maybe switching to openMP), then
the advantageous speed of r.li over r.le would be maintained.
Markus (who runs it on 4-16 cores)
Markus Neteler wrote:
> Is anyone familiar with r.li?
... as a user ...
> How easy would it be to get rid of the (Unix-specific) client-server
> framework so that the various r.li.* modules are just normal modules?The idea is to have multi-core support which works. If that
could be maintained (maybe switching to openMP), then
the advantageous speed of r.li over r.le would be maintained.
The downside is that it doesn't even compile on Windows. It also
creates a substantial hurdle for anyone needing to modify the code.
Optimisations shouldn't be at the expense of portability. If it can't
be compiled on all three of the major target platforms (generic Unix,
MacOSX, Windows), it shouldn't be in the main repository but in
add-ons.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Jan 26, 2010 at 10:11 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
> Is anyone familiar with r.li?
... as a user ...
> How easy would it be to get rid of the (Unix-specific) client-server
> framework so that the various r.li.* modules are just normal modules?The idea is to have multi-core support which works. If that
could be maintained (maybe switching to openMP), then
the advantageous speed of r.li over r.le would be maintained.The downside is that it doesn't even compile on Windows. It also
creates a substantial hurdle for anyone needing to modify the code.Optimisations shouldn't be at the expense of portability. If it can't
be compiled on all three of the major target platforms (generic Unix,
MacOSX, Windows), it shouldn't be in the main repository but in
add-ons.
I tend to agree.
But it is supported from gcc 4.2 onwards:
http://en.wikipedia.org/wiki/OpenMP
If the MinGW/MSys gcc isn't older, it should provide openMP.
Markus
Markus Neteler wrote:
>> > How easy would it be to get rid of the (Unix-specific) client-server
>> > framework so that the various r.li.* modules are just normal modules?
>>
>> The idea is to have multi-core support which works. If that
>> could be maintained (maybe switching to openMP), then
>> the advantageous speed of r.li over r.le would be maintained.
>
> The downside is that it doesn't even compile on Windows. It also
> creates a substantial hurdle for anyone needing to modify the code.
>
> Optimisations shouldn't be at the expense of portability. If it can't
> be compiled on all three of the major target platforms (generic Unix,
> MacOSX, Windows), it shouldn't be in the main repository but in
> add-ons.I tend to agree.
But it is supported from gcc 4.2 onwards:
http://en.wikipedia.org/wiki/OpenMP
I wasn't referring to OpenMP, but the existing client-server
mechanism. AFAICT, using OpenMP is relatively painless (other than a
lot of "ignoring #pragma ..." warnings), eliminating the need to
structure the code around a client/server framework.
But in order to implement that, the logical first step would be to
simply eliminate the client/server framework to produce a more
conventional module. OpenMP pragmas could be added as needed (but,
IMHO, the client/server stuff needs to go regardless of whether or not
anyone gets around to implementing OpenMP support).
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Is anyone familiar with r.li?
How easy would it be to get rid of the (Unix-specific) client-server
framework so that the various r.li.* modules are just normal modules?
I've done this, but I can't test that it still works as I don't have
any idea how to use it.
Also, r.li.setup is currently disabled (due to requiring Tcl/Tk) and
there doesn't appear to be any documention on creating a configuration
file without it.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Jan 27, 2010 at 2:50 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Glynn Clements wrote:
Is anyone familiar with r.li?
How easy would it be to get rid of the (Unix-specific) client-server
framework so that the various r.li.* modules are just normal modules?I've done this, but I can't test that it still works as I don't have
any idea how to use it.Also, r.li.setup is currently disabled (due to requiring Tcl/Tk) and
there doesn't appear to be any documention on creating a configuration
file without it.
Sorry for the delay. Attached a config file:
$HOME/.grass7/r.li/landclass96_conf
Usage (North Carolina data set [1]):
g.region rast=landclass96
r.li.shannon map=landclass96@PERMANENT conf=landclass96_conf
output=landclass96_shannon --o
Markus
[1] http://grass.osgeo.org/download/data.php
(attachments)
landclass96_conf (94 Bytes)
Markus Neteler wrote:
>> Is anyone familiar with r.li?
>>
>> How easy would it be to get rid of the (Unix-specific) client-server
>> framework so that the various r.li.* modules are just normal modules?
>
> I've done this, but I can't test that it still works as I don't have
> any idea how to use it.
>
> Also, r.li.setup is currently disabled (due to requiring Tcl/Tk) and
> there doesn't appear to be any documention on creating a configuration
> file without it.Sorry for the delay. Attached a config file:
$HOME/.grass7/r.li/landclass96_confUsage (North Carolina data set [1]):
g.region rast=landclass96
r.li.shannon map=landclass96@PERMANENT conf=landclass96_conf output=landclass96_shannon --o
Okay; it seems to work. I don't know what the output should actually
look like, but it doesn't crash or produce obviously bad data, and I
can't see any way that the changes could have "subtle" consequences.
r.li.setup still needs to replaced.
--
Glynn Clements <glynn@gclements.plus.com>