Hi Michael<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Since we don't currently have a way to define weights for cells or edges,<br>
I'd not object to dealing with the extension of partial_global_graph_info<br>
later, especially since it doesn't fundamentally affect the work of<br>
assigning multiple blocks to an MPI task.<br></blockquote><div><br>That sounds like a good idea to me, thanks! <br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
</div>I'd not argue that it couldn't be useful for an MPI task to know how many<br>
blocks another task owns, but I think we should consider whether the<br>
mpas_get_blocks_per_proc() routine or the blocks_per_proc vector are<br>
needed to meet any of the requirements. If not, do we want there to be a<br>
requirement for such, and if so, why? Also, while recognizing that the<br>
number of MPI tasks should be at most O(10^6) for the forseeable future,<br>
I think we should be wary of storing global information in memory.<br></blockquote><div><br>Ok, I will change it to be a public routine that simply returns the number of blocks for a given processor. This was also intended to be a routine where a processor could figure out how many blocks it was supposed to have. I planned to make the array public so the IO routines could easily read and determine how many it needed and allocate that many blocks, but it would be very easy to change to just use the routine. Also, the routine isn't very computationally expensive, so it wouldn't be a big penalty to call it a few times. I don't really anticipate any of the cores needing to call it, just other parts of framework. So I'll make this change to the design doc.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
</div>I think at some point in the past, the design document template may have<br>
had a section named "Implementation"; so, maybe we could keep the<br>
implementation details in this section, and focus on a detailed interface<br>
specification in the Design section. Does that sound like a reasonable<br>
option?<br></blockquote><div> <br>There was the implementation section. I removed it because it wasn't useful at the time, but I'll add it back, and put the actual implementations of the routines in that section. Thanks.<br>
<br>Doug<br></div></div>