Hi Phil,<br><br>I think the reason the document is a bit jumbled right now is just because the changes touch a lot of modules.<br><br>I'll respond to your comments below.<br><br>Thanks for your comments, <br>Doug<br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">
First, do we have a layout of the architecture (esp. At these lower levels)? That might help to see whether we need to think about reorganizing some stuff in the framework. And help to see the dependencies and how we might limit the dependencies and hide
more of the detail. A nice figure showing the modules, the dependencies, etc. would be great (doesn’t have to be UML – just a quick sketch).<br></span></font></div></blockquote><div><br>I can try to put together an image of the modules, but it might be a bit
incomplete. I'll send it out if I can get anywhere with it.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">
Second, it might help to see how the main data structures are going to change by showing, say, the field and block structures. <br></span></font></div></blockquote><div><br>Second, I don't really plan to change any of the data structures. The
changes that I refer to in the document only relate to what data
structures are used in the creation of blocks. Currently when blocks are
created a lot of simple 1d arrays are used to determine the
cell/vertex/edge id's owned by a block, but I can't foresee this being
able to be used with multiple blocks. Mainly because of halos and
exchange lists.<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">
Third, some pseudo code showing where the block loops will sit and how the info is passed might help to see whether support for arrays can still happen.<br></span></font></div></blockquote><div><br>Keep in mind, none of the changes should effect anything at the core level. All of the changes that are referred to in this document only relate to framework which is used prior to running a core. With the exception of halo updates, but the interface for halo updates won't change.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">
Finally, some interfaces for functions like halo updates and/or reductions would be useful to see how we can minimize what’s exposed at higher levels.<br></span></font></div></blockquote><div><br>I can add some of these to the document and send it out again, but there was a project that Conrad worked on earlier where he modified the halo updates to work on the field data type, rather than arrays. However reductions are still going to be done on arrays rather than fields.<br>
<br>The changes that I refer to regarding the allToAll communication routines are essentially the analog of the previously done halo conversion but for the allToAll routines. We need to modify them to work on fields rather than arrays, which essentially comes back to the exchange lists. You can't specify exchange lists for multiple blocks on a processor without using the field data type.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt">Right now, I guess I still have a muddied picture on how this looks in MPAS. <br>
</span></font></div></blockquote><div><br>I'll try to get that picture that might help some.<br></div></div>