[mpas-developers] proposed changes for trunk

[Michael Duda]

Hi, All.

Since the changes for pre-processing the registry file are very minimal,
enable useful functionality, and have minimal impact on existing code
(I've only needed to update the comment character in each registry
file), I'd like to go ahead and commit these changes this afternoon
unless there are any objections or difficiencies that should be
addressed.

Thanks!
Michael


On Wed, Dec 21, 2011 at 02:35:46PM -0700, Michael Duda wrote:
> Hi, Folks.
> 
> Based on the feedback I've received on the RKIND changes, I'll plan to
> commit them later today.
> 
> To be considered as a separate commit, I've also come up with another
> set of changes that I'd like to get some early feedback on; these
> changes enable us to run the registry files through cpp before they are
> parsed by the registry program. This can be useful, for example, if we
> would like to have a common registry file for the atmospheric physics
> that can be shared (via #include) between the hydrostatic and
> non-hydrostatic atmosphere cores, or if we'd like to conditionally
> remove fields from a registry, for example.
> 
> The changes required to enable us to pre-process the registry file are
> very minor:
> 
> 1) Modify the registry program so that it will read from standard input
> if no filename is given on the command line, and so that it will echo
> back the entries that were used.
> 
> 2) Change src/Makefile to run the registry file through cpp and pipe the
> output to the registry program, rather than giving the registry file as
> a command-line argument.
> 
> 3) Since cpp uses # at the beginning of lines to mark directives, change
> the comment character used in the registry files from # to % (very
> familiar to Latex users!).
> 
> 4) Find and replace all # with % in the registry files for each of the
> MPAS cores.
> 
> I've implemented the above changes and have been trying out various use
> cases (#include'ing a file, commenting out blocks of entries with #if 0, etc.), 
> and all seems to work exactly as expected with no impacts to existing behavior. 
> If anyone would like to try out the modified, code, I've placed a copy at
> http://www.mmm.ucar.edu/people/duda/files/cam_mpas_nh.tar.gz.
> 
> Any comments or suggestions for improvement would be welcomed!
> 
> Cheers,
> Michael
> 
> 
> On Tue, Dec 20, 2011 at 03:44:30PM -0700, Michael Duda wrote:
> > Hi, All.
> > 
> > I've been making a few minor improvements in a branch along the way to
> > integrating the non-hydrostatic atmoshpere core in CAM, and since these
> > changes are generally applicable, I'd like to propose adding them in the
> > trunk, too.
> > 
> > The first set of changes affects the way that the RKIND value is
> > defined.  Currently in the trunk, we use cpp with -DRKIND=8 to change
> > the types of reals throughout the code; however, this approach doesn't
> > allow us to type literal constants (e.g., to change 0.0_RKIND to 0.0_8
> > due to the way cpp works), and it also ignores the fact that different
> > compilers are permitted to define the double-precision kind differently
> > (in other words, usind kind=8 is not universally guaranteed to give us
> > double-precision reals). To address these issues, I've added a new
> > module, src/framework/mpas_kind_types.F, that defines RKIND using the
> > intrinsic SELECTED_REAL_KIND. Now, we can be sure that the value of
> > RKIND is a value that will give double-precision, and we can also define
> > literal constants like 0.0_RKIND. I've gone through all of the cores and
> > updated them so that they compile with this new module. An added bonus
> > is that we can remove one more macro definition (-DRKIND=8) from the
> > Makefile, and we can in theory get rid of compiler options like -r8,
> > -qrealsize=8, etc. (although in practice, the physics routines we've
> > inherited from WRF still require these compiler options, so I've left
> > them in the Makefile for now).
> > 
> > The second change is in the dmpar module, and simply makes it possible
> > to use an externally-supplied MPI communicator, which might come, e.g.,
> > from CESM.
> > 
> > All and only these changes are in branches/cam_mpas_nh, so I'd like to
> > propose at this point to merge this branch to the trunk. If there are
> > any questions, suggestions for improvements, or concerns, just let me
> > know!
> > 
> > Thanks,
> > Michael