[mpas-developers] Block Decomposition Revision

Doug Jacobsen jacobsen.douglas at gmail.com
Fri Jan 27 18:49:59 MST 2012


Thanks for the comments Phil,

I fixed the typo you mentioned, and I have already changed the design
document to only provide a public interface to the
mpas_get_blocks_per_proc, rather than the lookup table.

Considering dynamic load balancing, would it be useful to store the local
block id, and owning processor number within the block derived data type? I
could see at least the local block id being useful, to help you if you need
to rearrange the block indices, or insert a new block into the correct
position, but I am unsure about the owning proc information. I guess that
would just be dminfo % my_proc_id, since you would only have blocks that
you would own.

If anyone has any input on these ideas please let me know, but for now I'll
add the local block index to the block data type (in the design doc), and
leave out the owning proc id.

Thanks again,
Doug

On Fri, Jan 27, 2012 at 3:52 PM, Jones, Philip W <pwjones at lanl.gov> wrote:

>
> Doug,
>
> Generally, I think it’s ok.  Couple of minor things below.  Michael is
> correct in saying we want to be careful about holding onto arrays that are
> proportional to either number of tasks/blocks, even if they appear small
> now.  Memory per node is not growing and on a per-core basis will continue
> to shrink. I suspect we will only need these functions on
> start-up/initialization and may be able to deallocate after this phase is
> complete (and then the functions would return an error).  Once we’ve set up
> communicators/patterns for halos, reductions and I/O, I don’t believe we’ll
> have a need for these sorts of global maps.  Even if we did dynamic load
> balancing, we’d typically be passing off a block or two from one task to
> another and can update locally without these global queries.  Maybe we can
> keep these around for now and worry about this later.
>
> For minor issues:
>
> Do we want this in the io namelist block?  I think there should be a
> general decomposition group rather than putting this in i/o.  (I have other
> naming preferences too, but that’ll open another can o’ worms).
>
> The last para on page 6 of the pdf is missing something “wher is the
> number of proc”.  It appears in the tex input too, so it’s not a tex issue.
>
> Phil
>
>
>
> On 1/27/12 2:53 PM, "Doug Jacobsen" <jacobsen.douglas at gmail.com> wrote:
>
>  Hi again all,
>
> I have now attached the newest version of this design doc.
>
> Please let me know of any other comments/questions.
>
> Doug
>
> ------------------------------
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>
>
>
> ---
> Correspondence/TSPA/DUSA EARTH
> ------------------------------------------------------------
> Philip Jones                                pwjones at lanl.gov
> Climate, Ocean and Sea Ice Modeling
> Los Alamos National Laboratory
> T-3 MS B216                                 Ph: 505-500-2699
> PO Box 1663                                Fax: 505-665-5926
> Los Alamos, NM 87545-1663
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20120127/0aaa86ed/attachment.html 


More information about the mpas-developers mailing list