Subsections

5 Infrastructure: Utilities

24 Overview of Infrastructure Utility Classes

The ESMF utilities are a set of tools for quickly assembling modeling applications.

The Time Management Library provides utilities for time and time interval representation, as well as a higher-level utility, a clock, that controls model time stepping.

The ESMF Config class provides configuration management based on NASA DAO's Inpak package, a collection of methods for accessing files containing input parameters stored in an ASCII format.

The ESMF LogErr class consists of a method for writing error, warning, and informational messages to a default Log file that is created during ESMF initialization.

The ESMF VM (Virtual Machine) class provides methods for querying information about a VM. A VM is a generic representation of hardware and system software resources. There is exactly one VM object per ESMF Component, providing the execution environment for the Component code. The VM class handles all resource management tasks for the Component class and provides a description of the underlying configuration of the compute resources used by a Component. In addition to resource description and management, the VM class offers the lowest level of ESMF communication methods.

25 Time Manager Utility

The ESMF Time Manager utility includes software for time and time interval representation, as well as model time advancement. Since multi-component geophysical applications often require synchronization across the time management schemes of the individual components, the Time Manager's standard calendars and consistent time representation promote component interoperability.


Key Features
Drift-free timekeeping through an integer-based internal time representation. Both integers and reals can be specified at the interface.
Support for many calendar kinds.
Support for both concurrent and sequential modes of component execution.

25.1 Time Manager Classes

There are four ESMF classes that represent time concepts:

25.2 Calendar

The set of supported calendars includes:
Gregorian
The standard Gregorian calendar.
no-leap
The Gregorian calendar with no leap years.
Julian
The standard Julian date calendar.
Julian Day
The standard Julian days calendar.
Modified Julian Day
The Modified Julian days calendar.
360-day
A 30-day-per-month, 12-month-per-year calendar.
no calendar
Tracks only elapsed model time in hours, minutes, seconds.
See Section 26.1 for more details on supported standard calendars, and how to create a customized ESMF Calendar.


25.3 Time Instants and TimeIntervals

TimeIntervals and Time instants (simply called Times) are the computational building blocks of the Time Manager utility. Times support different queries for values of individual Time components such as year and hour. See Sections 27.1 and 28.1, respectively, for use of Times and TimeIntervals.

25.4 Clocks

It is useful to identify a higher-level concept to repeatedly step a Time forward by a TimeInterval. We refer to this capability as a Clock, and include in its required features the ability to store the start and stop times of a model run, and to query the value of quantities such as the current time and the number of time steps taken. Applications may contain temporary or multiple Clocks. Section 29.1 describes the use of Clocks in detail.

26 Calendar Class

26.1 Description

The Calendar class represents the standard calendars used in geophysical modeling: Gregorian, Julian, Julian Day, Modified Julian Day, no-leap, 360-day, and no-calendar. Brief descriptions are provided for each calendar below.

26.2 Constants


26.2.1 ESMC_CALKIND

DESCRIPTION:
Supported calendar kinds.

The type of this flag is:

type(ESMF_CalKind_Flag)

The valid values are:

ESMC_CALKIND_360DAY
Valid range: machine limits
In the 360-day calendar, there are 12 months, each of which has 30 days. Like the no-leap calendar, this is a simple approximation to the Gregorian calendar sometimes used by modelers.

ESMC_CALKIND_GREGORIAN
Valid range: 3/1/4801 BC to 10/29/292,277,019,914
The Gregorian calendar is the calendar currently in use throughout Western countries. Named after Pope Gregory XIII, it is a minor correction to the older Julian calendar. In the Gregorian calendar every fourth year is a leap year in which February has 29 and not 28 days; however, years divisible by 100 are not leap years unless they are also divisible by 400. As in the Julian calendar, days begin at midnight.

ESMC_CALKIND_JULIAN
Valid range: 3/1/4713 BC to 4/24/292,271,018,333
The Julian calendar was introduced by Julius Caesar in 46 B.C., and reached its final form in 4 A.D. The Julian calendar differs from the Gregorian only in the determination of leap years, lacking the correction for years divisible by 100 and 400 in the Gregorian calendar. In the Julian calendar, any year is a leap year if divisible by 4. Days are considered to begin at midnight.

ESMC_CALKIND_JULIANDAY
Valid range: +/- 1x10$^{14}$
Julian days simply enumerate the days and fraction of a day which have elapsed since the start of the Julian era, defined as beginning at noon on Monday, 1st January of year 4713 B.C. in the Julian calendar. Julian days, unlike the dates in the Julian and Gregorian calendars, begin at noon.

ESMC_CALKIND_MODJULIANDAY
Valid range: +/- 1x10$^{14}$
The Modified Julian Day (MJD) was introduced by space scientists in the late 1950's. It is defined as an offset from the Julian Day (JD):

MJD = JD - 2400000.5

The half day is subtracted so that the day starts at midnight.

ESMC_CALKIND_NOCALENDAR
Valid range: machine limits
The no-calendar option simply tracks the elapsed model time in seconds.

ESMC_CALKIND_NOLEAP
Valid range: machine limits
The no-leap calendar is the Gregorian calendar with no leap years - February is always assumed to have 28 days. Modelers sometimes use this calendar as a simple, close approximation to the Gregorian calendar.

26.3 Class API

27 Time Class


27.1 Description

A Time represents a specific point in time.

There are Time methods defined for setting and getting a Time.

A Time that is specified in hours does not need to be associated with a standard calendar; use ESMC_CALKIND_NOCALENDAR. A Time whose specification includes time units of a year must be associated with a standard calendar. The ESMF representation of a calendar, the Calendar class, is described in Section 26.1. The ESMC_TimeSet method is used to initialize a Time as well as associate it with a Calendar. If a Time method is invoked in which a Calendar is necessary and one has not been set, the ESMF method will return an error condition.

In the ESMF the TimeInterval class is used to represent time periods. This class is frequently used in combination with the Time class. The Clock class, for example, advances model time by incrementing a Time with a TimeInterval.

27.2 Class API

28 TimeInterval Class

28.1 Description

A TimeInterval represents a period between time instants. It can be either positive or negative.

There are TimeInterval methods defined for setting and getting a TimeInterval, for printing the contents of a TimeInterval.

The class used to represent time instants in ESMF is Time, and this class is frequently used in operations along with TimeIntervals. The Clock class, for example, advances model time by incrementing a Time with a TimeInterval.

TimeIntervals are used by other parts of the ESMF timekeeping system, such as Clocks; see Section 29.1.

28.2 Class API

29 Clock Class

29.1 Description

The Clock class advances model time and tracks its associated date on a specified Calendar. It stores start time, stop time, current time, and a time step.

There are methods for setting and getting the Times associated with a Clock. Methods are defined for advancing the Clock's current time and printing a Clock's contents.

29.2 Class API

30 Config Class

30.1 Description

ESMF Configuration Management is based on NASA DAO's Inpak 90 package, a Fortran 90 collection of routines/functions for accessing Resource Files in ASCII format.The package is optimized for minimizing formatted I/O, performing all of its string operations in memory using Fortran intrinsic functions.

30.1.1 Package history

The ESMF Configuration Management Package was evolved by Leonid Zaslavsky and Arlindo da Silva from Ipack90 package created by Arlindo da Silva at NASA DAO.

Back in the 70's Eli Isaacson wrote IOPACK in Fortran 66. In June of 1987 Arlindo da Silva wrote Inpak77 using Fortran 77 string functions; Inpak 77 is a vastly simplified IOPACK, but has its own goodies not found in IOPACK. Inpak 90 removes some obsolete functionality in Inpak77, and parses the whole resource file in memory for performance.

30.2 Class API

31 Log Class

31.1 Description

The Log class consists of a variety of methods for writing error, warning, and informational messages to files. A default Log is created at ESMF initialization.

When ESMF is started with ESMC_Initialize(), multiple Log files will be created by PET number. The PET number (in the format PETx.) will be prepended to each file name where x is the PET number. The ESMC_LogWrite() call is used to issue messages to the log. As part of the call, a message can be tagged as either an informational, warning, or error message.

The messages may be buffered within ESMF before appearing in the log. All messages will be properly flushed to the log files when ESMC_Finalize() is called.

31.2 Constants


31.2.1 ESMC_LOGKIND

DESCRIPTION:
Specifies a single log file, multiple log files (one per PET), or no log files.

The valid values are:

ESMC_LOGKIND_SINGLE
Use a single log file, combining messages from all of the PETs. Not supported on some platforms.
ESMC_LOGKIND_MULTI
Use multiple log files — one per PET.
ESMC_LOGKIND_NONE
Do not issue messages to a log file.


31.2.2 ESMC_LOGMSG

DESCRIPTION:
Specifies a message level.

The valid values are:

ESMC_LOGMSG_INFO
Informational messages
ESMC_LOGMSG_WARNING
Warning messages
ESMC_LOGMSG_ERROR
Error messages
ESMC_LOGMSG_TRACE
Trace messages
ESMC_LOGMSG_DEBUG
Debug messages
ESMC_LOGMSG_JSON
JSON format messages

31.3 Class API

32 VM Class

32.1 Description

The ESMF VM (Virtual Machine) class is a generic representation of hardware and system software resources. There is exactly one VM object per ESMF Component, providing the execution environment for the Component code. The VM class handles all resource management tasks for the Component class and provides a description of the underlying configuration of the compute resources used by a Component.

In addition to resource description and management, the VM class offers the lowest level of ESMF communication methods. The VM communication calls are very similar to MPI. Data references in VM communication calls must be provided as raw, language-specific, one-dimensional, contiguous data arrays. The similarity between VM and MPI communication calls is striking and there are many equivalent point-to-point and collective communication calls. However, unlike MPI, the VM communication calls support communication between threaded PETs in a completely transparent fashion.

Many ESMF applications do not interact with the VM class directly very much. The resource management aspect is wrapped completely transparent into the ESMF Component concept. Often the only reason that user code queries a Component object for the associated VM object is to inquire about resource information, such as the localPet or the petCount. Further, for most applications the use of higher level communication APIs, such as provided by Array and Field, are much more convenient than using the low level VM communication calls.

The basic elements of a VM are called PETs, which stands for Persistent Execution Threads. These are equivalent to OS threads with a lifetime of at least that of the associated component. All VM functionality is expressed in terms of PETs. In the simplest, and most common case, a PET is equivalent to an MPI process. However, ESMF also supports multi-threading, where multiple PETs run as Pthreads inside the same virtual address space (VAS).

32.2 Class API

33 Profiling and Tracing

33.1 Description


33.1.1 Profiling

ESMF's built in profiling capability collects runtime statistics of an executing ESMF application through both automatic and manual code instrumentation. Timing information for all phases of all ESMF components executing in an application can be automatically collected using the ESMF_RUNTIME_PROFILE environment variable (see below for settings). Additionally, arbitrary user-defined code regions can be timed by manually instrumenting code with special API calls. Timing profiles of component phases and user-defined regions can be output in several different formats:

The following table lists important environment variables that control aspects of ESMF profiling.

Environment Variable Description Example Values Default
ESMF_RUNTIME_PROFILE Enable/disables all profiling functions ON or OFF OFF
ESMF_RUNTIME_PROFILE_PETLIST Limits profiling to an explicit list of PETs 0-9 50 99 profile all PETs
ESMF_RUNTIME_PROFILE_OUTPUT Controls output format of profiles; multiple can be specified in a space separated list TEXT, SUMMARY, BINARY TEXT


33.1.2 Tracing

Whereas profiling collects summary information from an application, tracing records a more detailed set of events for later analysis. Trace analysis can be used to understand what happened during a program's execution and is often used for diagnosing problems, debugging, and performance analysis.

ESMF has a built-in tracing capability that records events into special binary log files. Unlike log files written by the ESMF_Log class, which are primarily for human consumption (see Section 31.1), the trace output files are recorded in a compact binary representation and are processed by tools to produce various analyses. ESMF event streams are recorded in the Common Trace Format (CTF). CTF traces include one or more event streams, as well as a metadata file describing the events in the streams.

Several tools are available for reading in the CTF traces output by ESMF. Of the tools listed below, the first one is designed specifically for analyzing ESMF applications and the second two are general purpose tools for working with all CTF traces.

Events that can be captured by the ESMF tracer include the following. Events are recorded with a high-precision timestamp to allow timing analyses.

phase_enter
indicates entry into an initialize, run, or finalize ESMF component routine
phase_exit
indicates exit from an initialize, run, or finalize ESMF component routine
region_enter
indicates entry into a user-defined code region
region_exit
indicates exit from a user-defined code region

The following table lists important environment variables that control aspects of ESMF tracing.

Environment Variable Description Example Values Default
ESMF_RUNTIME_TRACE Enable/disables all tracing functions ON or OFF OFF
ESMF_RUNTIME_TRACE_CLOCK Sets the type of clock for timestamping events (see Section [*]). REALTIME or MONOTONIC or MONOTONIC_SYNC REALTIME
ESMF_RUNTIME_TRACE_PETLIST Limits tracing to an explicit list of PETs 0-9 50 99 trace all PETs
ESMF_RUNTIME_TRACE_COMPONENT Enables/disable tracing of Component phase_enter and phase_exit events ON or OFF ON
ESMF_RUNTIME_TRACE_FLUSH Controls frequency of event stream flushing to file DEFAULT or EAGER DEFAULT

33.2 Restrictions and Future Work

  1. Limited types of trace events. Currently only a few trace event types are available. The tracer may be extended in the future to record additional types of events.
  2. MPI call profing not available for statically linked executables on Darwin. Currently the linker on Darwin systems does not support the wrapping of symbols during static linking. In order to access MPI call profiling on Darwin, executables should be linked dynamically in combination with the procedure described in section [*].

33.3 Class API

esmf_support@ucar.edu