<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div class="_2Qk4AbDuWwkuLB005ds2jm QMubUjbS-BOly_BTHEZj7 allowTextSelection">
<div>
<div>
<div dir="ltr">
<div style="color:black;font-size:12pt;font-family:Calibri,Arial,Helvetica,sans-serif">
<span>Hi everyone, </span></div>
<div style="color:black;font-size:12pt;font-family:Calibri,Arial,Helvetica,sans-serif">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>Week 4 has concluded, and this is my report for this week.</div>
<div><br>
</div>
<div>
<p style="margin-top:0;margin-bottom:0">1) What did I get done this week?<br>
</p>
</div>
<div>r.mfilter (PR: <a href="https://github.com/OSGeo/grass/pull/1634/files" target="_blank" rel="noopener noreferrer" data-auth="NotApplicable" data-linkindex="0" id="LPlnk796504">
https://github.com/OSGeo/grass/pull/1708</a>)
<div style="margin-top:0;margin-bottom:0">
<ul>
<li><span>Add test cases for different input options (Sequential/Parallel filters, repeated, null_mode)</span></li><li><span>Add parallel implementations for all options excluding Sequential filters (inherently not possible to do parallelization
<br>
</span></li></ul>
</div>
<div style="margin-top:0;margin-bottom:0">2) What do I plan on doing next week?</div>
<div style="margin-top:0;margin-bottom:0">Upon discussion with the mentors, we decided to change the current implementation for r.neighbor that currently uses Segment libraries that uses a temporary file buffer for the different threads to work on before producing
 the raster file format. We realized that the Segment library does not fit the use cases enough to compensate for the overhead it might add. It was essentially used as an API to write to the file buffer, and we are not making good use of its caching capabilities.
 A native temporary file buffer should fit our use cases the most where the threads can write output simultaneously (which is the current implementation for r.mfilter).</div>
<div style="margin-top:0;margin-bottom:0"><br>
</div>
<div style="margin-top:0;margin-bottom:0">Next week, I aimed to make the necessary changes for r.neighbor and do proper benchmarking on large raster files to monitor the performance gain from parallelization (r.mfilter).<br>
</div>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">3) Am I blocked on anything?<br>
</p>
<p style="margin-top:0;margin-bottom:0">No, it has been good so far.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<div style="margin-top:0;margin-bottom:0">Github repo: <a href="https://github.com/aaronsms/grass" target="_blank" rel="noopener noreferrer" data-auth="NotApplicable" data-linkindex="0">
https://github.com/aaronsms/grass</a><br>
</div>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Any suggestions are welcome. Thanks!<br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Warmest regards,</p>
<p style="margin-top:0;margin-bottom:0">Aaron</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</body>
</html>