<br>I went through the functions list and my first point of understanding was that the following functions will be nice to be worked into:<br><br>in raster functions:<br>r.terraflow, r.walk,r.watershed,r.water.outlet.<br><br>
in image functions:<br>The most obvious one I saw was i.fft and i.ifft. An extension of which would be i.zc.<br>I went through Yann's recommendation on i.atcorr, and went through the research paper corresponding to it, Since the concept is new to me, it is possible that I might end up picking the brains of the mentor.<br>
<br>Also beyond parallel, I will be fine with network tool kit also. Is it an active project?.<br><br>Whatever happens to my GSOC application, I will be more than happy to work with the developer team at GRASS.<br><br><br>
<br><div class="gmail_quote">On Thu, Mar 19, 2009 at 10:43 PM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Mar 19, 2009 at 8:27 AM, Jyothish Soman<br>
<<a href="mailto:jyothish.soman@gmail.com">jyothish.soman@gmail.com</a>> wrote:<br>
> I am a Masters student from International Institute of Information<br>
> Technology-Hyderabad India, looking to participate in google summer of code<br>
> under the OSGeo umbrella. More specifically, I want to work in the<br>
> parallelizing GRASS modules using openMP (MPI is also fine).<br>
<br>
</div>That is a great idea - I am sure that many users would benefit from that.<br>
<div class="im"><br>
> Slightly confused where to start poking in the code.<br>
> Any suggestions on possible modules that have a good scope of coarse grained<br>
> parallelization in it is welcome.<br>
<br>
</div>I guess that some kind of profiling is needed to see where time is<br>
wasted. The "problem" is that much of GRASS' intelligence stays<br>
in the modules. So heavy interpolation modules are certainly<br>
candidates.<br>
Also the vector library (topology building?) might be a candidate.<br>
<br>
We could make a quick survey in grass-user to ask people where<br>
they find GRASS slow.<br>
<div class="im"><br>
> Please note: I am assuming that all the developers I have talked to earlier<br>
> are already in this mail. If I missed anybody, please do inform me.<br>
<br>
</div>(all are in the list)<br>
<div class="im"><br>
> Have been slightly busy yesterday, so didnt put up a full effort in going<br>
> through the code, forgive me for that.<br>
<br>
</div>No problem at all! Here is also the (navigable) manual:<br>
<a href="http://download.osgeo.org/grass/grass6_progman/" target="_blank">http://download.osgeo.org/grass/grass6_progman/</a><br>
<br>
Please ask if you need specific answers.<br>
<font color="#888888"><br>
Markus<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>JYOTHISH SOMAN<br>MS-2008-CS<br>Center for Security, Theory And Algorithm Research<br>International Institute of Information Technology<br>Hyderabad<br>India<br>Phone:+91-9966222626<br>
<a href="http://www.iiit.ac.in/">http://www.iiit.ac.in/</a><br>--------------------------------------------------------------<br>The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.<br>
George Bernard Shaw<br>--------------------------------------------------------<br><br>