[GRASS-dev] Re: [GRASS GIS] #520: r.terraflow/iostream does not respect STREAM_DIR option

[GRASS GIS]

#520: r.terraflow/iostream does not respect STREAM_DIR option
---------------------+------------------------------------------------------
  Reporter:  mmetz   |       Owner:  grass-dev at lists.osgeo.org
      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>