Hamish wrote: > > > But, if the nature of the algorithm is such that processing time > > > becomes a problem long before memory does, then there's no point to > > > using any form of segmentation. > > as the module gets faster, the size of map you attempt to run it on > gets bigger and memory does start to become an issue... > > FWIW the biggest actual-data region I've tried with r.surf.contour was > 21000x13000 (this was a long while back, so god knows how long it took to > finish, could have been a week..*). If it stores it in memory in the input > map's CELL_TYPE, that'll take ~ 2.1gb RAM by my numbers (DCELL). If stored > in memory as CELL, half that. I can accept that much, but it is pushing on > needing a 'percent of map to keep in memory' option.
If you're running jobs which take days, I don't think that it's unrealistic to require a manual tile/process/patch. It's quite likely that you will want to do that anyhow in order to split the task over multiple systems. > I did the same in my tests knowing that it /shouldn't/ have an effect. > If nothing else it's a good fail-safe sanity check. e.g. NULL support > in 6.5 is currently borken, if r.surf.contour outputted maps containing > NULLs it probably would have picked that up. r.surf.contour is one of the few modules still using zero-is-null, i.e. G_get_map_row() rather than G_get_c_raster_row(). -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
