CCSM/ESMF Stage-1 meeting

Tuesday May 16th, 1:30-3:00pm

Directors Conference room

Attending: Brian E., Brian K., Erik, Mariana, Tony and Nancy N.

  1. Stop time is NOT an alarm in ESMF – as such I don't want to treat
    it the same as other alarms.
  2. Personally, as all models need restart alarms – I think there should be special methods to deal with them. But, I do like the idea
    of having a general method for alarms – but we don't have need for other alarms at Stage-1, so this seems to be a Stage-2 idea. (At stage-2 we need alarms for each component).
  3. The principle I want to suggest we use is – "Make what's standard easy, and what's not standard more difficult (but not too difficult)".
    3.) - make mpicom and mastertask optional (or absent) – Yes.
    We actually talked about this at an earlier meeting. I'm fine with changing it if desired. So if mpicom and mastertask are not available,
    always read in namelist and don't do the broadcast (regardless of the build-time setting of HIDE_MPI.
    4.) Flexible interfaces for namelist objects...
    This is something I can't do at this time and try to meet get Stage-1 done by the deadline. But, this is a valid topic for Stage-2.
    Basically the interface I've proposed from the start has a hard-coded interface for datavalues.
    My interface looks like...
      call shr_timemgr_setDefaults( perpetual_run=perp_run, &
                                    perpetual_ymd=perp_ymd, Setup )
      ! Change some values in the setup object
      call shr_timemgr_change( Setup, start_ymd=my_start )
      ! Read in the timemgr namelist
      call shr_timemgr_readNL( nlfilename, LogPrint, MPICom, MasterTask, &
                               SetupOut )
      ! Get info from the clock-setup object
      ! call shr_timemgr_get( setup, stop_option=stop_option )
      ! Setup the clock
      call shr_timemgr_setupClock( setup, LogPrint=.true.,     
                                   desc="my_clock", &
                                   ClockOut=clock )
      ! Print out the clock
      call shr_timemgr_print( clock )
      ! Get info from the clock
      call shr_timemgr_clockGet( clock, CurrentYMD=ymd, currentTOD=tod )
    
    So the _change and _clockGet or other such methods have a list of
    items you can change or get.
    A flexible interface might look like:
      call shr_timemgr_setDefaults( Setup )
      call shr_timemgr_setDefaultValue( Setup, "perpetual_run", perp_run )
      call shr_timemgr_setDefaultValue( Setup, "perpetual_ymd", perp_ymd )
      ! Change some values in the setup object
      call shr_timemgr_change( Setup, "start_ymd", my_start )
      ! Read in the timemgr namelist
      call shr_timemgr_readNL( nlfilename, LogPrint, MPICom, MasterTask, &
                               SetupOut )
      ! Get info from the clock-setup object
      call shr_timemgr_get( setup, "stop_option", value=stop_option )
      ! Setup the clock
      call shr_timemgr_setupClock( setup, LogPrint=.true.,     
                                   desc="my_clock", &
                                   ClockOut=clock )
      ! Print out the clock
      call shr_timemgr_print( clock )
      ! Get info from the clock
      ymd = shr_timemgr_clockGet( clock, "CurrentYMD" )
      tod = shr_timemgr_clockGet( clock, "CurrentTOD" )
    
    Personally I do NOT want to go this direction for the following reasons:
  4. The interfaces I've proposed have been specific from the start – I needed this suggestion earlier in the design phase to get this done by Stage-1.
  5. However, this is a perfectly valid debate and good suggestions to decide on for Stage-II.
  6. There will be development time to make this change.
  7. The generic calls take up more code than the specific ones as the generic calls require one method call per item returned. For long lists of things you want to get out – this is bad.
  8. ESMF already has a generic object for handling namelist type data – the ConfigAttributes object. It solves some problems with namelists already and the development has been done.
  9. Why spend development costs to create our own ConfigAttributes object equivalent – why not leverage off ESMF?
  10. I don't expect that these underlying types will have a lot of development and changes going on with them (by nature they are data that span several components, the only reason to add data to them is for driver level information that you want to effect two or more components).
  11. Developments I expect: remove archive info, add orbit option to stay in sync with year, add ability for Paleo calendars?, add more options to control compenent execution (no_land, no_ice_nor_land, no_ice_nor_ocean), add new methods (without changing underlying data).