I actually get the same thing. For the first while the process runs in full use of one core, but once the process starts writing results to the db, the whole process bogs down to a grinding halt. CPU usage for v.lidar.edgedetection drops down to ~1% (1% of one core) and sqlite usage rises to ~16%. Maybe I'm wrong, but my impression was that the bottle neck was the modifications to the database.
On 19-Jun-09, at 5:43 AM, John Tate wrote:
Note that there is a bug in v.outlier. v.outlier creates a temporary table by the name of outfilename_aux (LN #137 /lidar/v.outlier/main.c) but elsewhere in the code it is hardwired to Auxiliar_outlier_table (LN's # 239 & 258 /lidar/v.outlier/outlier.c) , so when it actually tries to write to the table it complains and fails. You can get around it by manually creating this table using; db.copy from_table=outfilename_aux to_table=Auxiliar_outlier_table I'm not sure why, but it looks like the system doesn't always need to use the Auxiliar_outlier_table, and when it doesn't, it continues on merrily without complaint. Unfortunately, when it does require the table, on my system the program continues on only to segmentation fault further down the line (at least it does on my system). Maybe it's because of the changes that I made to the code to correct the above error, but I can't see why that would be true. I was planning on looking further into it, but haven't had the time to start debugging. In the mean time I've added the files with my changes to the code for the developers. I'm a hack, so the changes are probably in poor coding practice. Someone more savvy that I will need to clean it up. Cheers, Mike PS. IF I find what I think are errors or possible improvements to the code, what is the most appropriate place and method to submit them? |
main.c
Description: Binary data
outlier.c
Description: Binary data
outlier.h
Description: Binary data
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
