[mpas-developers] core-independence of operators

[Michael Duda]

Hi, Folks.

I've prepared a set of changes to the trunk that will pass the non-mesh
fields (i.e., u, uReconstruct{X,Y,Z,Zonal,Meridional}) separately to the
vector reconstruction module; besides the change to the argument list of
the reconstruct() routine itself, the changes I've made to the different
cores essentially involve changes of the type

<          call reconstruct(block % state % time_levs(2) % state, block % mesh)
---
>          call reconstruct(block % mesh, block % state % time_levs(2) % state % u % array,          &
>                           block % state % time_levs(2) % state % uReconstructX % array,            &
>                           block % state % time_levs(2) % state % uReconstructY % array,            &
>                           block % state % time_levs(2) % state % uReconstructZ % array,            &
>                           block % state % time_levs(2) % state % uReconstructZonal % array,        &
>                           block % state % time_levs(2) % state % uReconstructMeridional % array    &
>                          )

In case anyone would like to take a closer look, I've placed a 
tar file with the code, as I'm proposing to commit, at
http://www.mmm.ucar.edu/people/duda/files/mpas/generic_vector_reconstruct.tar.gz.
This tar file contains a checked out copy, so 'svn status', 'svn diff',
and other svn commands should make it easy to see the changes.

I didn't pass any of the mesh fields (e.g., xCell, yCell, zCell, etc.)
separately, since in some cases, doing so would have resulted in fairly
long argument lists; for core-independence, this isn't an issue, since
the mesh description fields in the mesh type are required to be there by
most parts of the infrastructure anyway. Aside from the mesh type, the
vector reconstruction module was the only one to assume fields in a
particular type; so, with these changes, I think we can consider the
current set of operator modules to be effectively "core-independent".

If there are any comments, suggested changes, or objections, please
don't hesitate to let me know. 

Thanks!
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
>