[mpas-developers] proposing a few infrastructure changes

Michael Duda duda at ucar.edu
Thu Sep 15 11:52:03 MDT 2011


Hi, Everyone.

The most significant of the infrastructure improvements that were
just committed is the addition of a new I/O stream that can be
read or written periodically during the course of a simulation.
The primary application that we had in mind was for updating
surface fields during a run, but you all may find other uses, too,
such as for lateral boundary fields. Note that the fields handled
by the stream don't need to be just 2d fields; 3d fields will work
just as well.

To make use of the new periodic 's' stream for input, a core will
need to:

0. Add 's' to the I/O attributes of a field in the Registry file

1. Declare a new variable of type io_input_object, setting the 'stream'
   component of the type to STREAM_SFC

2. Call io_input_init(...) for the new io_input_object type

3. Periodically call read_and_distribute_fields(...) after setting
   the time frame to read in the new io_input_object type to read
   in all fields marked as being input on stream 's' (compared with i, r, and o)

4. Call io_input_finalize(...) for the new io_input_type before completing
   the simulation

Using this new functionality as described above, one can now choose to
read the SST field from the new input stream, e.g., using

var persistent real    sst        ( nCells Time              ) 1 sro sst           sfc_input    - -


Writing output on the 's' stream can be accomplished with code
similar to the following:

   type (io_output_object) :: sfc_update_obj

   sfc_update_obj % time = 1
   sfc_update_obj % filename = 'mgd_sst.nc'

   call output_state_init(sfc_update_obj, domain, "SFC")

   call output_state_for_domain(sfc_update_obj, domain, sfc_update_obj % time)

   call output_state_finalize(sfc_update_obj, dminfo)

If anyone has any questions, I'll be glad to explain further or
provide assistance; just let me know!

Cheers,
Michael


On Wed, Sep 14, 2011 at 08:05:52PM -0600, Todd Ringler wrote:
> 
> Hi Michael,
> 
> This sounds like a great idea to me. On our side, we need to figure out how to incorporate some of these improvements into our cores.
> 
> Cheers,
> Todd
> 
> On Sep 14, 2011, at 6:53 PM, Michael Duda wrote:
> 
> > Hi, All.
> > 
> > We're hoping to merge the non-hydrostatic atmosphere core into the
> > repository trunk in the very near future, and to pave the way for
> > that merge, I'd like to incorporate some of the infrastructure
> > enhancements that I've made in the atmos_physics branch into the
> > trunk in advance. These enhancements don't have any impact on the
> > existing cores in the trunk, in the sense that, if the cores don't
> > make use of them, the changes are invisible to the cores. In
> > summary (in other words, just copying and pasting from the svn
> > log), the changes include:
> > 
> > * Add changes to I/O and registry infrastructure to support
> >  periodic input on a separate stream.
> > 
> > * Add changes to registry and I/O modules so that nVertLevelsP1 is
> >  treated as just another non-decomposed dimension, rather than as a
> >  special case.  These changes allow us to dimension a variable with
> >  nVertLevelsP1 as the outer-most dimension.
> > 
> > * Changes to allow registry-defined fields to have a
> >  non-decomposed dimension as their outer-most dimension, i.e., to
> >  have a dimension other than nCells, nEdges, nVertices, or
> >  nVertLevels outer-most.
> > 
> > * Add I/O support for time-varying, 1d integer fields.
> > 
> > * Create a version of the quicksort routine to work with real
> >  values, and create generic interface for the quicksort routine
> >  that can select between sorting real and integer values
> > 
> > The affected files are:
> > 
> > M       src/registry/registry_types.h
> > M       src/registry/gen_inc.c
> > M       src/registry/parse.c
> > M       src/framework/module_io_input.F
> > M       src/framework/module_sort.F
> > M       src/framework/module_io_output.F
> > M       src/framework/module_grid_types.F
> > 
> > For review, I've placed a working copy of the trunk that includes
> > the proposed changes at
> > http://www.mmm.ucar.edu/people/duda/files/trunk_mgd_20110914.tar.gz
> > 
> > If the changes look acceptable to everyone, I'll go ahead and
> > commit them to the trunk; otherwise, any thoughts or comments
> > would be much appreciated.
> > 
> > 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