Soeren, I am taking this out of bug tracker as these comments are not directly relevant to the r.sim.water problem on Windows.
>Helena can you please provide a simple spearfish example for >r.sim.sediment, so i can test my changes with this module? I don't use spearfish anymore but here are couple ready to use examples for the nc_spm_08 data set: http://courses.ncsu.edu/mea582/lec/001/GIS_anal_grass/GIS_Anal_grsimwe.html the data set is on the GRASS website and also here: http://courses.ncsu.edu/mea582/common/media/01/nc_spm_08.zip and the result of the first example should look something like this: http://skagit.meas.ncsu.edu/~helena/wrriwork/lakewh/flowsimwedem.jpg >BTW: Is it possible to add the water depth in every step to the elevation >map and additionally computing the direction derivatives dx and dy to >avoid infinite water accumulation in sinks and pits? I suggest this will >make the solution of the partial differential equation non linear, but >maybe the time steps are already small enough to implement this as an >explicit step? the diffusion term prevents infinite water accumulation in deperessions, the water depth parameter hmax controls when the diffusion term increases to get water out of pits, how much it increases is controled by halpha. So water will flow out of depressions and over dams (see the video below) but it could still grow too fast and create spikes or bumps so it is not the real diffusive wave. If you are getting spikes in depressions for Spearfish you need to lower the value of hmax and increase halpha. But you are right on target that the elevation should be updated with water level and new gradient computed so that gradient of surface water is used for routing. That would allow the depressions to be filled more accurately without artificial spikes. The time step is estimated in such a way that for each time step the particle does not travel through more than one cell so the water depth can be added and gradient computed as an explict step. I did some experiments in that direction - the gradient needs to be computed from smooth enough approximation to prevent artifacts that would get amplified after each time step. If you could help implement the water depth updates that would be fantastic, let me know. We use simwe a lot for the Tangible GIS project - see e.g., here: http://courses.ncsu.edu/mea582/lec/001/GIS_anal_lecture/tg1bak2_ed4_1min640.mov Thanks for the update to grass7, Helena Helena Mitasova Associate Professor Department of Marine, Earth and Atmospheric Sciences North Carolina State University Raleigh, NC 27695 hmit...@unity.ncsu.edu On Jan 27, 2010, at 5:55 PM, GRASS GIS wrote: > #617: r.sim.water crashes on WinGrass > ---------------------------+------------------------------------------------ > Reporter: hamish | Owner: grass-dev@lists.osgeo.org > Type: defect | Status: new > Priority: normal | Milestone: 6.4.0 > Component: Raster | Version: 6.4.0 RCs > Resolution: | Keywords: wingrass, r.sim.water > Platform: MSWindows XP | Cpu: x86-32 > ---------------------------+------------------------------------------------ > Comment (by huhabla): > > I have hardly tried to find the error using valgrind, but was > unsuccessful. > Neither the grass6.4 version nor the grass7 version showing any suspicious > behavior on 32bit Linux. > So i don't know if my changes may have solved the problem, but it would be > great, if anybody may > compile the latest grass7 version on MacOS or Windows for testing, running > the speafish60 example. > > Helena can you please provide a simple spearfish example for > r.sim.sediment, so i can test my changes with this module? > > BTW: Is it possible to add the water depth in every step to the elevation > map and additionally computing the direction derivatives dx and dy to > avoid infinite water accumulation in sinks and pits? I suggest this will > make the solution of the partial differential equation non linear, but > maybe the time steps are already small enough to implement this as an > explicit step? > > Soeren > > -- > Ticket URL: <https://trac.osgeo.org/grass/ticket/617#comment:5> > GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev