[mpas-developers] derived data type redesign
Todd Ringler
ringler at lanl.gov
Tue Dec 20 12:09:11 MST 2011
Hi Michael,
I was thinking about this issue this morning and if we would have the opportunity to make these DDTs more flexible in how we use them.
I think the attachment might be missing from the original email.
Cheers,
Todd
On Dec 20, 2011, at 12:07 PM, 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
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
More information about the mpas-developers
mailing list