I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the examples
from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk to Jaro
to see what would be the best way to fix it).
Also, should I submit these changes to GRASS64 so that it runs in winGRASS?
(I am not sure what was the problem there)
Helena
Yann,
when you have some time, could you please add units to the description / help for r.usler
(are whichever other modules needs it), something like what we have added for simwe.
I assume the rainfall input is in [mm] but it would be good to provide this info, as well as
the units for output.
thank you,
Helena
On Oct 29, 2008, at 5:15 PM, Helena Mitasova wrote:
I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the examples
from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk to Jaro
to see what would be the best way to fix it).
Also, should I submit these changes to GRASS64 so that it runs in winGRASS?
(I am not sure what was the problem there)
Helena
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova wrote:
I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the
examples from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk
to Jaro to see what would be the best way to fix it).
I suggest committing the changes, but leaving it disabled in
raster/Makefile until the sites and waterglobs.h issues have been
fully dealt with.
If you keep a private copy around for too long, it may become
problematic to merge it if the SVN copy gets modified in the meantime
(if I'm making changes related to a particular header file or a
particular function, I'll normally change everything which uses it,
even modules which are disabled).
Regarding waterglobs.h, does it work if you remove
r.sim.*/waterglobs.h and add -I../simlib to EXTRA_CFLAGS in
r.sim.*/Makefile? Or are there other issues?
Also, should I submit these changes to GRASS64 so that it runs in
winGRASS? (I am not sure what was the problem there)
I'd suggest leaving it for now. The version in 6.4 isn't as likely to
be modified as in 7.0.
--
Glynn Clements <glynn@gclements.plus.com>
On Oct 30, 2008, at 2:17 PM, Glynn Clements wrote:
Helena Mitasova wrote:
I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the
examples from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk
to Jaro to see what would be the best way to fix it).
I suggest committing the changes, but leaving it disabled in
raster/Makefile until the sites and waterglobs.h issues have been
fully dealt with.
that is what I have done - I have committed the changes to grass trunk
but left it disabled in raster/Makefile as you have suggested.
The sites issues are fixed (I commented the offending code out).
I will look into the waterglobs issue,
thanks, Helena
If you keep a private copy around for too long, it may become
problematic to merge it if the SVN copy gets modified in the meantime
(if I'm making changes related to a particular header file or a
particular function, I'll normally change everything which uses it,
even modules which are disabled).
Regarding waterglobs.h, does it work if you remove
r.sim.*/waterglobs.h and add -I../simlib to EXTRA_CFLAGS in
r.sim.*/Makefile? Or are there other issues?
Also, should I submit these changes to GRASS64 so that it runs in
winGRASS? (I am not sure what was the problem there)
I'd suggest leaving it for now. The version in 6.4 isn't as likely to
be modified as in 7.0.
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova wrote:
The sites issues are fixed (I commented the offending code out).
By "fixed", I meant making the code work.
AFAICT, there are two main issues:
1. fdoutwalk is a sites handle, but it's never closed. This wasn't
necessary when it was a FILE*, as it was automatically closed on exit,
but I think that it's necessary for a vector map.
2. fw is a plain FILE* (for simwe_data.txt), but it's being closed
with G_sites_close().
The "meta" issue is that the extensive use of global variables (and
the use of multiple versions of waterglobs.h) makes life hard for
anyone who isn't intimately acquainted with the code to do anything
with it. Which is why I didn't try to fix the above (mainly #1; it's
hard to figure out where to put the G_sites_close() call).
--
Glynn Clements <glynn@gclements.plus.com>
On Oct 30, 2008, at 5:56 PM, Glynn Clements wrote:
Helena Mitasova wrote:
The sites issues are fixed (I commented the offending code out).
By "fixed", I meant making the code work.
the site related input and output is not essential and needs to be
updated to vector points anyway so I commented it out (until
somebody who is interested in having that output will update
it to vector format - it may be me, my student or somebody else).
So the #1 and #2 is not there any more. Let me know if I should delete
it completely rather than comment it out - I am keeping it there in case
I can get to it sometimes soon.
The waterglobs.h issue is more complicated and I need to find out first
why it has been done the way it is there - I need more time for that,
but the code should compile and work as it is (at least it does for me).
Helena
AFAICT, there are two main issues:
1. fdoutwalk is a sites handle, but it's never closed. This wasn't
necessary when it was a FILE*, as it was automatically closed on exit,
but I think that it's necessary for a vector map.
2. fw is a plain FILE* (for simwe_data.txt), but it's being closed
with G_sites_close().
The "meta" issue is that the extensive use of global variables (and
the use of multiple versions of waterglobs.h) makes life hard for
anyone who isn't intimately acquainted with the code to do anything
with it. Which is why I didn't try to fix the above (mainly #1; it's
hard to figure out where to put the G_sites_close() call).
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova wrote:
>> The sites issues are fixed (I commented the offending code out).
>
> By "fixed", I meant making the code work.
the site related input and output is not essential and needs to be
updated to vector points anyway so I commented it out (until
somebody who is interested in having that output will update
it to vector format - it may be me, my student or somebody else).
So the #1 and #2 is not there any more. Let me know if I should delete
it completely rather than comment it out - I am keeping it there in case
I can get to it sometimes soon.
AFAIK, the G_sites_* functions should continue to work. It just needs
to be borne in mind that the "handle" in no longer a FILE*, so you
can't interchange G_sites_close() and fclose() in the way that you
could before (or rely upon the "file" being closed automatically upon
exit).
The code to handle old-style sites files still exists, but the
functions were renamed to G_oldsites_*. However, those functions only
exist for the benefit of v.in.sites (i.e. converting old to new).
The waterglobs.h issue is more complicated and I need to find out first
why it has been done the way it is there - I need more time for that,
but the code should compile and work as it is (at least it does for me).
If there's any disagreement between simlib/waterglobs.h and
r.sim.*/waterglobs.h, there will be problems, as only
simlib/waterglobs.h is guaranteed to match the library (insofar as any
mismatch should generate a warning).
At most, I would expect that the r.sim.* versions may contain
additional declarations, specific to the individual modules. If that's
the case, it should just be an issue of moving such declarations into
a local_proto.h (or similar) file.
--
Glynn Clements <glynn@gclements.plus.com>
the man page for r.watershed says that the lsfac is multiplied by 100, but the result is DCELL
so I am wondering whether the multiplication is still true. (and if yes whether it should be changed)
And how is this for the new r.watershed2?
thanks,
Helena
On Oct 30, 2008, at 2:17 PM, Glynn Clements wrote:
Helena Mitasova wrote:
I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the
examples from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk
to Jaro to see what would be the best way to fix it).
I suggest committing the changes, but leaving it disabled in
raster/Makefile until the sites and waterglobs.h issues have been
fully dealt with.
If you keep a private copy around for too long, it may become
problematic to merge it if the SVN copy gets modified in the meantime
(if I'm making changes related to a particular header file or a
particular function, I'll normally change everything which uses it,
even modules which are disabled).
Regarding waterglobs.h, does it work if you remove
r.sim.*/waterglobs.h and add -I../simlib to EXTRA_CFLAGS in
r.sim.*/Makefile? Or are there other issues?
Also, should I submit these changes to GRASS64 so that it runs in
winGRASS? (I am not sure what was the problem there)
I'd suggest leaving it for now. The version in 6.4 isn't as likely to
be modified as in 7.0.
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus,
I checked and it seems to be still multiplied by 100
(I cc to Chuck as he is much better qualified to tell):
in
sg_factor.c
we have
69 L = 100 * pow((slope_length / 72.6), s_l_exp);
but L is defined as double on line 55 so the multiplication is
perhaps not necessary? Same for slope steepness?
While looking at this it also seems that
there may be an issue with meter-to-foot conversion - this is needed
because the number 72.6 above is in feet, but I don't see a check whether the data
is in feet - then the conversion should be skipped (but I did not explore this
much so it may be hidden somewhere)
35 if (ls_flag) {
36 length *= METER_TO_FOOT;
37 len_slp_equ(length, sin_theta, S, r, c);
as for the conversion constant - this would be better taken from UNITS
because the US feet may be more common than the int. feet used below
#define METER_TO_FOOT (1 / 0.3048)
Helena
On Nov 27, 2008, at 6:06 PM, Markus Neteler wrote:
Helena,
could you please chek in SVN? I have uploaded the code to 6.4.and 7
into raster/r.watershed2/
It compiles as "r.watershed" module of course.
Markus
On Wed, Nov 19, 2008 at 5:36 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
the man page for r.watershed says that the lsfac is multiplied by 100, but
the result is DCELL
so I am wondering whether the multiplication is still true. (and if yes
whether it should be changed)
And how is this for the new r.watershed2?
thanks,
Helena
On Oct 30, 2008, at 2:17 PM, Glynn Clements wrote:
Helena Mitasova wrote:
I have commented out the sites-related input/output from simwe in trunk.
It compiles and runs with grass7 updated today - I tested it with the
examples from grassbook and some variations of the parameters.
Are these changes enough to get it back into grass7?
(there is still the issue of 3 separate waterglobs.h - I need to talk
to Jaro to see what would be the best way to fix it).
I suggest committing the changes, but leaving it disabled in
raster/Makefile until the sites and waterglobs.h issues have been
fully dealt with.
If you keep a private copy around for too long, it may become
problematic to merge it if the SVN copy gets modified in the meantime
(if I'm making changes related to a particular header file or a
particular function, I'll normally change everything which uses it,
even modules which are disabled).
Regarding waterglobs.h, does it work if you remove
r.sim.*/waterglobs.h and add -I../simlib to EXTRA_CFLAGS in
r.sim.*/Makefile? Or are there other issues?
Also, should I submit these changes to GRASS64 so that it runs in
winGRASS? (I am not sure what was the problem there)
I'd suggest leaving it for now. The version in 6.4 isn't as likely to
be modified as in 7.0.
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/