#520: r.terraflow/iostream does not respect STREAM_DIR option
---------------------+------------------------------------------------------
Reporter: mmetz | Owner:
[hidden email]
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
---------------------+------------------------------------------------------
Comment (by mmetz):
Replying to [comment:14 hamish]:
> Replying to [comment:10 mmetz]:
> > /var/tmp does not exist on Windows, so this is not really a
> > good choice for default temp directory.
>
> that is a problem. If it were decided to keep it out of $MAPSET/.tmp/ we
could use a compiler macro for C:\Temp\Grass\, like we do for /dev/null
and NUL:.
>
> ISTR the output files are of some interest after the module has ended.
is this the case? if so, putting them deep in a hidden .tmp/ dir isn't
very nice.
All temporary files are deleted upon successful termination, I checked.
There is also a warning to remove any temp files in case of error:
THESE INTERMEDIATE STREAMS WILL NOT BE DELETED IN CASE OF ABNORMAL
TERMINATION OF THE PROGRAM. TO SAVE SPACE PLEASE DELETE THESE FILES
MANUALLY!
>
> otherwise the lack of /var/tmp/ on MS-win makes a compelling case for
moving it to $M/.tmp/ and short-circuiting this discussion.
>
> > It is ok to call G_tempfile() ...
>
> sorry, that should have read "before G_parser() has run", not
G_gisinit().
>
> see:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/parser.c#L724 OK, then leave it blank and after G_parser() use G_tempfile() or something
else that works on all platforms if no answer was given?
>
> > AFAIKT, G_tempfile() only returns a filename, a file is not
> > created (the description of G_tempfile() says so).
>
> don't trust the comments, test it. from past experience I think it
> creates a file. (at least the `g.tempfile` module does).
>
"don't trust the comments", uff. Checking every library function if it
behaves as described in the comments is a bit uncomfortable when using
these functions in some code. In this case, g.tempfile calls the same
function like G_tempfile() and then, after that, actually creates a temp
file. So I haven't tested it, but according to the code it looks like
G_tempfile() is indeed only returning a file name without creating a file.
>
> > Increasing the memory option to e.g. 75% doesn't really help
> > for massive grids (the main aim of r.terraflow) unless there
> > are much more than 8GB of RAM available
>
> I am not sure, but I have the memory that it was not a 1:1 trade
> off, a bit more memory meant much less disk space? (untested)
> what I do remember is that when I had do do a real world run with a
massive grid, I had to crank that up until I didn't hit the LFS limit of
my 32bit system, which in turn made it run faster. I might have also had
to compromise on the resolution that time, but I don't think so as I don't
like doing that & so would have remembered :)
The manual says that 2x80 bytes per cell are needed as disk space, no
mentioning of more memory meaning less disk space needed. It would help if
one of the authors of r.terraflow and/or the iostream library could
comment on that.
>
>
> > Last comment: any reason why STREAMTMP_DIR is set system-wide
> > and not with G_putenv()?
>
> an environmental variable can not escape its process to the rest of the
system (can not export to parent or siblings, only self and children).
anyway, the code at lib/gis/putenv.c shows that G_putenv() is just a
wrapper incase putenv() doesn't exist on that system.
That is cosmetics anyway, and I think I meant G_getenv/G_setenv, not
G_putenv. And I don't know much about environment variables, it was
essentially about why not using lib/gis functions for cross-platform
compatibility.
Markus M
--
Ticket URL: <
http://trac.osgeo.org/grass/ticket/520#comment:15>
GRASS GIS <
http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
