[mpas-developers] derived data type redesign [with attachments!]

[Michael Duda]

With attachments, this time!

Michael


On Tue, Dec 20, 2011 at 12:07:04PM -0700, Michael Duda wrote:
> Hi, All.
> 
> Attached is a first draft of a requirements and design document for the
> first item from the meeting between Doug, Conrad, and I last week; I've
> attached a PDF as well as the Latex source for editing. My assessment is
> that the changes to the DDTs themselves should be simple -- it's the
> remaining items on the list, below, that will be tricky. 
> 
> Cheers,
> Michael
> 
> 
> On Wed, Dec 14, 2011 at 03:47:35PM -0700, Michael Duda wrote:
> > Hi, Doug and Conrad.
> > 
> > Here are the key development issues that we identified this morning, in
> > roughly the order we'll probably need to tackle them:
> > 
> > 1) Update/extend the fundamental derived types in mpas_grid_types.F. 
> >    In order for other parts of the infrastructure to handle multiple 
> >    blocks per task in a clean way, we'll need to be able to pass a head 
> >    pointer to a field into a routine, and have that routine loop through 
> >    all blocks for that field, with information about which cells/edges/vertices 
> >    in that field need to be communicated. 
> > 
> > 2a) Decide on a new MPAS I/O abstraction layer, which will provide a
> >    high-level interface to the PIO layer for the rest of MPAS. This layer
> >    should work with blocks of fields, and make it possible to define an
> >    arbitrary set of I/O streams at run-time.
> > 
> > 2b) Add a new module to parse a run-time I/O configuration file that
> >    will describe which fields are read or written to each of the I/O
> >    streams that a user requests via the file. This module will make calls 
> >    to the new MPAS I/O layer to register the requested fields for I/O in 
> >    the requested streams.
> > 
> > 3) Update the mpas_dmpar module to support communication operations on
> >    multiple blocks per task. This will likely involve revising the 
> >    internal data structures used to define communication of cells 
> >    between tasks, and also require revisions to the public interface 
> >    routines themselves.
> > 
> > 4) Modify the block_decomp module to enable a task to get a list of
> >    cells in more than one block that it is to be the owner of.  
> >    Implemented in the simplest way, there could simply be a namelist 
> >    option to specify how many blocks each task should own, and the 
> >    block_decomp module could look for a graph.info.part.n file, with 
> >    n=num_blocks_per_task*num_tasks, and assign blocks k, 2k, 3k, ...,
> >    num_blocks_per_task*k to task k.
> > 
> > Some of the changes, e.g., to the dmpar module, are significant enough
> > that we should consider whether a general re-write of the module would
> > be appropriate; in such cases, we should consider whether the code can
> > be made more concise and more maintainable if it were written in C.
> > 
> > Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpas_ddt_redesign.pdf
Type: application/pdf
Size: 77918 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20111220/4b4039c1/attachment-0001.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpas_ddt_redesign.tar.gz
Type: application/octet-stream
Size: 14128 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20111220/4b4039c1/attachment-0001.obj