Comments:
mode 1: instantaneous solar incidence angle & irradiance using a set local time
mode 2: integrated daily irradiation
* I moved the output of r.sun_out.txt into the "history" of each output file.
This was an issue when running mode 2 for each day of the year and creating
statistics on the results with r.series. Each day would overwrite the last.
It can be viewed with r.info or parsed using the map's file in the
$MAPSET/hist/ directory. The appended command history at the bottom is from a
library function G_command_history() I wrote for src/libes/gis/history.c that
isn't in CVS yet.
Questions:
- Declination: Meaningless in mode 2?
- Latitude min-max: I'm not sure if the PROJ updates changed this. Are the
recent speedups caused by it only transforming one position (center of the
map*) or does it calculate for each cell, and what gets reported above is
simply the last instance? And why is la_max=0 (ie unset after init)?.
???
* if so, 'g.region -l' shows "-45.3119" near the SE corner, not the middle.
Maybe this a common southern hemisphere bug: (-45 + 15/60) != -45.25 ?
- sunrise & sunset times are infact slightly different for bigger maps; ok.
I'm working on:
- currently seg faults with incidout=
- currently lets you mix mode 1 and mode 2 only options without error
also in anyone can help, I'm having problems getting gdb to work with GRASS.
I compiled with:
CFLAGS="-O3 -march=pentium4 -Wall -ggdb" LDFLAGS="-s" ./configure ...
but gdb can't find any debug info:
GRASS:~ > gdb r.sun
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...
(gdb) break 460
No symbol table is loaded. Use the "file" command.
(gdb) run
Starting program: /usr/src/grass/grass53-CVS/dist.i686-pc-linux-gnu/bin/r.sun
(no debugging symbols found)...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x40000c10 in _start () from /lib/ld-linux.so.2
(gdb) bt f #0 0x40000c10 in _start () from /lib/ld-linux.so.2
No symbol table info available.
(gdb)
In general: Check the hints in /grass/documents/debugging.txt
On Tue, Sep 23, 2003 at 12:02:43AM +1200, Hamish wrote:
also in anyone can help, I'm having problems getting gdb to work with GRASS.
I compiled with:
CFLAGS="-O3 -march=pentium4 -Wall -ggdb" LDFLAGS="-s" ./configure ...
Good.
but gdb can't find any debug info:
GRASS:~ > gdb r.sun
Run the actual command in etc/bin/cmd or etc/bin/inter not the wrapper
from the grass command prompt.
* I moved the output of r.sun_out.txt into the "history" of each output file.
This was an issue when running mode 2 for each day of the year and creating statistics on the results with r.series. Each day would overwrite the last.
It can be viewed with r.info or parsed using the map's file in the $MAPSET/hist/ directory. The appended command history at the bottom is from a
library function G_command_history() I wrote for src/libes/gis/history.c that
isn't in CVS yet.
It's a good idea, thanks.
Questions:
- Declination: Meaningless in mode 2?
no, it is still necessary in mode 2.
- Latitude min-max: I'm not sure if the PROJ updates changed this. Are the
recent speedups caused by it only transforming one position (center of the map*) or does it calculate for each cell, and what gets reported above is simply the last instance? And why is la_max=0 (ie unset after init)?
???
la_max=0 is wrong, it should be -90.
* if so, 'g.region -l' shows "-45.3119" near the SE corner, not the middle.
Maybe this a common southern hemisphere bug: (-45 + 15/60) != -45.25 ?
- sunrise & sunset times are infact slightly different for bigger maps; ok.
I'm working on:
- currently seg faults with incidout=
- currently lets you mix mode 1 and mode 2 only options without error
Yes, this fix would be helpful as well.
Many thanks.
- Latitude min-max: I'm not sure if the PROJ updates changed this. Are the
recent speedups caused by it only transforming one position (center of the
map*) or does it calculate for each cell,
Certainly it still calculates the lat/long for each cell (well if it did
that before). Before it also read the PROJ_INFO file and parsed the
key/value pairs into a PROJ.4 projection definition for every cell;
obviously it only needs to do that once as the projection won't change
over a map. That is where the major speed-up came from.
also in anyone can help, I'm having problems getting gdb to work with GRASS.
I compiled with:
CFLAGS="-O3 -march=pentium4 -Wall -ggdb" LDFLAGS="-s" ./configure ...
1. Don't use LDFLAGS="-s" if you want to debug the binary; "-s" strips
the debugging information.
2. Don't use -O if you want to be able to step through function
bodies. When optimisation is enabled, the compiler will re-order
statements and re-arrange expressions, resulting in object code which
barely resembles the source code.
Sorry, I meant in the r.sun_out.txt output, not in the program.
OK. I think it could stay there. It is important to now what value of declination was used in calculations because there are many approximation formulas. It is meaningless if you set your own declination value, but if you set just a day number, it is still necessary.
Just about to commit some changes to CVS.
I hope there are no mistakes.
I am looking forward to your updates! Thanks again.
> also in anyone can help, I'm having problems getting gdb to work
> with GRASS.
Glynn:
1. Don't use LDFLAGS="-s" if you want to debug the binary; "-s" strips
the debugging information.
2. Don't use -O if you want to be able to step through function
bodies. When optimisation is enabled, the compiler will re-order
statements and re-arrange expressions, resulting in object code which
barely resembles the source code.
Bernhard:
Run the actual command in etc/bin/cmd or etc/bin/inter not the wrapper
from the grass command prompt.
Binaries will be a lot bigger (compiled source dir now close to 1GB).
I guess you could leave off the -ggdb and add it to Gmakefiles as
needed, but that wouldn't help you with any library calls.
From within GRASS:
GRASS:~ > gdb $GISBASE/etc/bin/cmd/g.command
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
[...]
(gdb) run <command line args>
...
Binaries will be a lot bigger (compiled source dir now close to 1GB).
I guess you could leave off the -ggdb and add it to Gmakefiles as
needed, but that wouldn't help you with any library calls.
You could also add -g in the Gmakefiles for the relevant libraries
(primarily libgis), although that will probably mean that you don't
actually save very much (see below for rationale).
For Linux, you also have the option of using shared libraries (see
mk/README). I suspect that a lot of the extra space is from having
~470 executables statically linked against a version of libgis which
includes debug info. Many of the modules only comprise a single object
file; in such cases, the bulk of the executable will be library code.
Yet another option would be to build everything with CFLAGS=-g and
LDFLAGS=-s (i.e. add the debug info to all of the object files then
strip it from the executables), then delete and rebuild the relevant
executables after removing -s from LINK_FLAGS in head.<arch>.
FWIW, I normally use the alternate build mechanism and shared
libraries, and build everything with debug info. The source tree
totals 149Mb, while the build directory (object files, libraries and
executables) totals 193Mb, of which dist.<arch> (i.e. the executables)
accounts for 78Mb. That suggests that up to 2/3 of your 1Gb figure may
be due to static linking.
On Tue, Sep 23, 2003 at 07:40:31PM +1200, Hamish wrote:
> > also in anyone can help, I'm having problems getting gdb to work
> > with GRASS.
Glynn:
> 1. Don't use LDFLAGS="-s" if you want to debug the binary; "-s" strips
> the debugging information.
>
> 2. Don't use -O if you want to be able to step through function
> bodies. When optimisation is enabled, the compiler will re-order
> statements and re-arrange expressions, resulting in object code which
> barely resembles the source code.
Added to INSTALL file.
Bernhard:
> Run the actual command in etc/bin/cmd or etc/bin/inter not the wrapper
> from the grass command prompt.