Changes between Version 5 and Version 6 of GSoC/2021/RasterParallelization


Ignore:
Timestamp:
06/28/21 01:03:46 (4 years ago)
Author:
aaronsms
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2021/RasterParallelization

    v5 v6  
    228228No, it has been good so far, but I hope to improve on my pace.
    229229
     230=== Week 2 ===
     231
     232'''1) What did I get done this week?'''
     233
     234r.univar\\
     235 - Address changes for the PR (1) , e.g. to use a standard option "nprocs" will now be a parameter for users to indicate the number of threads
     236
     237r.neighbor\\
     238 - Write test cases for parallel execution
     239 - Drafted a PR alongside its implementation (2)
     240
     241r.proj\\
     242 - Write new test cases for the modules (3)
     243
     244'''2) What do I plan on doing next week?'''\\
     245
     246I have managed to come up with a way to parallelize output-based modules like r.neighbor. The idea is to make use of a temporary segment file to allow threads to perform random write operations, which is not possible directly on compressed raster format file without using intermediate cache. With this design in mind, I intend to continue to parallelize similar modules next week. Also, there may be ideas in discussion to encapsulate a benchmarking framework possibly under grass.benchmark as this will be used repeatedly in the future to measure performance.
     247
     248
     249'''3) Am I blocked on anything?'''\\
     250
     251No, it has been good so far.
     252
     253(1) [https://github.com/OSGeo/grass/pull/1634]\\
     254(2) [https://github.com/OSGeo/grass/pull/1654]\\
     255(3) [https://github.com/OSGeo/grass/pull/1663]\\
     256(4) [https://github.com/OSGeo/grass/pull/1670]\\
     257
     258
     259=== Week 3 ===
     260
     261'''1) What did I get done this week?'''
     262
     263Upon discussion with the mentors, we have decided to explore alternative designs to using Segment library as intermediate output buffer. Specifically, there are two designs in mind, one which simply increases the size of the buffer but does sequential I/O to fill and output from the buffer with intermediate parallel computation, and a more complicated one which tries to eliminate having the threads to wait for the I/O.
     264
     265'''2) What do I plan on doing next week?'''\\
     266
     267I plan to finalize the design by this week. (1)
     268
     269'''3) Am I blocked on anything?'''\\
     270
     271No, it has been good so far.
     272
     273(1) https://github.com/aaronsms/grass
     274
    230275== Final report ==
    231276