[mpas-developers] core-independence of operators

Michael Duda duda at ucar.edu
Tue Sep 27 14:53:06 MDT 2011


Hi, Todd.

I think in certain cases -- particularly for global reduction-type diagnostics
-- we needed to be able to have a routine operate on all blocks of a field so
that, e.g., a global mean could be computed; this necessitated passing blocks
into these routines so we could follow the block pointer on to the next block,
if I recall correctly; and, passing blocks meant that the operator routine
needed to explicitly dereference fields by name. This is still an issue we need
to address (and I think we had come to a clean solution during your last visit
to NCAR). The vector reconstruction and other operator modules currently in the
trunk seem to be special cases in their immunity to this issue, though. So, it
should be fairly straightforward for me to have a go at implementing the
passing of simple arrays in the current operators; then, I definitely agree
that we should revisit the issue of global reduction-type operators with a
re-design of our data structures.

Thanks very much for the heads-up on passing arrays over pointers; I think this
is something that we'd like to experiment with, too!

Cheers,
Michael


On Tue, Sep 27, 2011 at 12:43:01PM -0600, Todd Ringler wrote:
> 
> Hi Michael,
> 
> We have certainly found the hardwiring of data arrays (like uReconstruct*) in the frameworks/operators to lead to less-than-optimal software practices. For example, when I wanted to reconstruct another vector field I ended up copying the module and simply changing the data that is pointed to. A far better way would be to simply pass the intent(in) and intent(out). If I recall, there was something preventing us from being able to do this. I think it was related to the construction of the derived data types and blocks. Maybe this no longer an issue.
> 
> In summary, I would be all for passing the data through the interfaces at the frameworks/operators. As a general rule, we want the frameworks/operators to be core independent and, to me, that included even the naming of arrays as well as the data that is processed.
> 
> Somewhat related .... We have also found that we can increase performance by passing arrays instead of using pointers. This will certainly be up to each core to decide, but we are trending toward pushing the easy-to-handle derived data types to the top levels of the code and working directly with arrays in the bottom levels.
> 
> Cheers,
> Todd
> 
> On Sep 26, 2011, at 3:01 PM, Michael Duda wrote:
> 
> > Hi, Everyone.
> > 
> > While sorting through the last of the differences between shared code in
> > our atmos_physics branch and the trunk, one issue that came up was where
> > the uReconstruct{X,Y,Z,Zonal,Meriodional} fields are stored -- that is,
> > to which structure in the Registry they belong. In the trunk, all cores
> > have these fields in 'state', while in the atmos_physics branch, we've
> > chosen to move them to 'diag', since they are diagnosed from the normal
> > velocity component on edges.
> > 
> > I think we may have discussed this sometime in the past, but one
> > possible solution to this issue would be to pass individual arrays to
> > the routines in the operators collection, thereby making them
> > core-independent. Specifically, I had in mind passing the
> > uReconstruct{X,Y,Z,Zonal,Meriodional} fields individually to the
> > reconstruct() subroutine in src/operators/module_vector_reconstruction.F.
> > But, if we chose to pursue the individual argument approach to its
> > conclusion, we could even pass all of the fields from the mesh type as
> > individual arguments, too.
> > 
> > What do you all think? Since the argument lists to the operator routines
> > wouldn't become too unwieldy from doing so, I'd propose to pass only
> > bare arrays to operator routines; but, I can see arguments to keeping
> > the mesh_type arguments, since other parts of the MPAS infrastructure
> > are also hard-wired to expect specific fields in the mesh type, too.  
> > In any case, I'd strongly argue for passing the
> > uReconstruct{X,Y,Z,Zonal,Meriodional} fields as separate arguments.  
> > 
> > Any thoughts or preferences would be welcomed!
> > 
> > Cheers,
> > 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