NEW DEVELOPMENTS IN

THE GENERAL NOAA

O P E R AT I O N A L M O D E L I N G
ENVIRONMENT (GNOME)
christopher h. barker *

March 25, 2015

abstract
The General NOAA Operational Modeling Environment (GNOME) is an oil
spill transport model developed and used by the United States’ National
Oceanic and Atmospheric Administration (NOAA) Emergency Response
Division (ERD). It is ERD’s primary tool for trajectory analysis in support
of oil spill response in the United States. In addition, it is widely used by
the general public for use in planning, intuition building, research, and edu-
cation. In the last few years, GNOME has seen a great deal of development.
This paper presents the new features, a road map for future development,
and information about how third parties can use and/or extend the model.
GNOME is a particle tracking model designed for oil spill fate and trans-
port modeling, but is highly flexible and adaptable. It can be applied any-
where in the world, receive input from virtually any oceanographic model,
and handle problems of any scale and complexity. The major new features
are an extensible, scriptable framework for the core model, fully integrated
oil weathering, and a full featured interactive web interface for the model. In
addition to the new code structures, the individual algorithms have been up-
dated to reflect the latest understanding of spill science. This paper will out-
line the core features and algorithms, provide information about how others
can contribute or use the model, and present a few examples of GNOME’s
very broad applications.

* National Oceanic and Atmospheric Administration. Office of Response and Restoration. Emergency
Response Division. Seattle WA, USA. [email protected]

1
 introduction 2

1 introduction
The National Oceanic and Atmospheric Administration (NOAA) is desig-
nated by the United States National Contingency Plan as the agency to pro-
vide scientific support to the US Coast Guard for the response to oil and
chemical spills in US coastal waters. NOAA provides this support through
the deployment of Scientific Support Coordinators (SSCs) stationed in the
field throughout the country. In the event of a spill, NOAA’s SSCs play a
key role in the command post, advising the Federal On Scene Commander
(FOSC). In order to provide this support, the SSCs rely on NOAA’s Emer-
gency Response Division (ERD) Technical and Scientific Support Branch, a
group of modelers, oceanographers, chemists, biologists and software devel-
opers, based in NOAA’s Seattle office.
One of the key roles of ERD during spills is to provide Fate and Trajec-
tory Analysis: the modeling, analysis, and resulting forecast of where the
oil (or chemical) is likely to go, and how its properties change with expo-
sure to the environment. In order to meet this mission, NOAA ERD has
developed most of its modeling software in-house since its inception in the
1970s. This was originally due to the lack of commercial options, but the
tradition has continued as it is key to our mission that the operational mod-
elers are intimately familiar with the working of the models. In addition,
having the development in-house allows ERD to to be nimble in a response
– sometimes fixing bugs or adding features as needed to support ongoing
response.
As a result, ERDs modeling tools have been at the forefront of oil and
chemical fate and trajectory modeling for decades. NOAA’s GNOME model
is a key tool to support response, and it has also been adapted for us for
other emergency and non-emergency uses, such as hind-casting the trajec-
tory of floating mammals, Harmful Algal Bloom (HAB) modeling, and fish
and coral larval transport.
In the last few years, the core modeling tools have undergone substan-
tial development. The major components of this development have been to
re-structure the code-base to allow easier selection and updating of new al-
gorithms, the merging of the weathering and transport models, the develop-
ment of a fully cross-platform scripting framework, and new web browser-
based user interface. The code is fully available as open source software to
encourage contributions and use outside of NOAA.

2 history
NOAA’s suite of oil spill models dates back to the 1970s with the On Scene
Spill Model (OSSM). In the late 1990’s a full re-implementation, using object
oriented programming techniques and a modern user interface resulted in
the General NOAA Operational Modeling Environment (GNOME). GNOME
provided an easy to use interface for non-experts, and “location files”, down-
loadable from ORR’s web site (http://response.restoration.noaa.gov/
gnome). Location Files provide pre-set up models for select regions, allowing
minimally trained users to use the model for education, intuition building,
and preparedness drills.
GNOME is focused on the transport side of the oil spill forecasting prob-
lem – where will the oil go? What shorelines are likely to be affected? To
answer the fate part of the problem – How will the oil change as it weathers?,
 computational structure 3

How much will remain on the water surface?, How much might evaporate,
disperse, emulsify, etc? NOAA developed the Automated Data Inquiry for
Oil Spills (ADIOS) model. The first version was developed in the 1980s, with
ADIOS2 coming out in 2000. ADIOS2 provided a modern user interface and
embedded oil properties database, and became an industry standard tool
for evaluating the mass balance of spills during response and planning ac-
tivities.
In the current development, updated versions of the weathering algo-
rithms from ADIOS2 have been integrated with the transport capabilities
of GNOME. The ADIOS oil database has also been included, while also
providing a separate API and user interface with much improved search ca-
pabilities. The new combined model continues to support ERD’s response
mission, while also providing enhanced access, usability, and greater exten-
sibility to the modeling community.

3 computational structure
One of the key features of GNOME its ability to be applied at virtually
any location and time and spatial scale. Oil spill transport is primarily a
function of the winds and ocean currents. The availability of meteorological
and oceanic models varies greatly with time and location, and there may
be multiple models for some locations. It is key to the design of GNOME
that it not be tied to any particular hydrodynamic model (or grid type), and
is able to be easily configured to ingest information from multiple sources,
including hand-entered data.
In order to achieve this flexibility, GNOME is built in a very modular
structure, with each key component as independent as possible. In order
to achieve this flexibility, the model is designed around two core structures:
particle tracking, or Lagrangian Element modeling, and Linear Superposi-
tion of physical processes. Used by most oil spill modeling systems, the
particle tracking approach allows GNOME to adapt to a wide variety of
time and spatial scales and allows highly variable concentrations in an effi-
cient manner without issues of numerical diffusion. Linear superposition of
physical processes allows GNOME to add and remove various algorithms
without implications as to how they interact. With appropriate numbers of
elements and well-selected time steps, these simplifications can capture the
core processes required to understand the fate and transport of an oil spill.

3.1 Core Components

GNOME is designed around a set of core components that can be added,

removed, or combined as best fit the modeling problem at hand. The oper-
ational GNOME code provides multiple versions of many of these compo-
nents, and third parties can build new components that might introduce a
new algorithm for one particular process.

3.1.1 Spills
A Spill in GNOME is responsible for creating Lagrangian elements (parti-
cles)that are used to to track the location and properties of the spill being
modeled. It consists of a two components: A Release object that specifies
where and when elements are introduced into the model, and a Substance
 computational structure 4

object that specifies the properties associated with the elements. Elements
can be simple with only a location as properties, or very complex with all
the properties required to support the full weathering model.
Currently available release objects include simple point and line sources
(instantaneous or continuous), a plume model, pipeline leak, and pre-specified
locations (for initializing from satellite or aerial observations).

3.1.2 Maps
A Map defines the location where the model is running – it specifies where
the boundaries of the model are, including shoreline and the bottom. The
Map also defines how the elements interact with the boundaries – sticking
and/or refloating on the shoreline, leaving the domain, etc.
Maps can be build from hydrodynamic model grids so as to exactly match
the boundaries of the model, or independently from GIS definitions of the
shoreline.

3.1.3 Movers
Movers represent any physical process that might move the oil. These might
include the wind, currents, diffusion processes, stokes drift, etc. Included
with the existing code base are movers for simple isotropic diffusion (hor-
izontal and vertical), wind drift, current patterns scaled by a time series
(wind, tidal currents, river flow), and full time dependent currents from a
variety of hydrodynamic models and grid types.
GNOME uses latitude / longitude for the spatial positions, so that dif-
ferent components can all communicate in one reference system. Vertical
position is in meters down from the water surface.

3.1.4 Weatherers
Weatherers represent physical and chemical processes that change the prop-
erties of the oil ( properties associated with the elements), or remove oil
from the water surface. The GNOME code currently includes evaporation,
dispersion, emulsification, sedimentation (Oil Sediment Aggregate forma-
tion), bio-degradation, and simple Dissolution.

3.1.5 Clean Up
Clean up objects represent response clean up options that remove oil from
the water. Currently included are simple skimming and burning options.

3.2 Environment

Environment objects represent physical aspects of the environment that may

not directly act on the oil, but change how the movers and weatherers act
on the elements. Currently included are wind, tides, waves, and water
properties such as temperature, salinity, and sediment load. THis allows the
various movers and weatherers to share the same environmental parameters,
but also also allows them to use independent ones if the need arises. One
example is a time-averaged wind field to drive a coastal current pattern that
may be different than the localized wind used to move the surface oil.
 the oil database 5

4 the oil database

GNOME works very closely with the ADIOS oil database. This database
consist of thousands of individual oils, each with a variety of physical and
chemical properties. As the data available for any given oil may be incom-
plete, the database also includes approximation algorithms for approximat-
ing physical properties that have not been measured. The database and
approximation code are independent of the rest of the GNOME model and
could be used in other applications.

4.0.1 Pseudo Components

The oil weathering algorithms use a pseudo component (PC) approach – the
complex chemical makeup of an individual oil is approximated by breaking
down the oil into a manageable set of components. Each PC is defined by
a boiling point (usually from distillation data), and chemical category: Sat-
urate, Aromatic, Resin, or Asphaltene (SARA). This allows the weathering
algorithms to treat each component differently, and allows the final results
to report these individual components that may effect spill impact analysis.
As SARA analysis is not always available, approximation algorithms are
included, so that the final database always has the full data required for the
weathering analysis.

5 scripting
The core model is written in the Python programming language, with many
components written in C++ for performance. As such, fairly simple scripts
can be written that set up the model and run it as required for an indi-
vidual use-case. Each component can be optionally added as needed, with
parameters specified. And example script with annotation, is below:
s t a r t _ t i m e = datetime (2013 , 2 , 13 , 9 , 0)

# S e t up p r i m a r y m o d e l p a r a m e t e r s
model = Model ( s t a r t _ t i m e = s t a r t _ t i m e ,
d u r a t i o n = t i m e d e l t a ( days = 2 ) ,
t i m e _ s t e p =15∗60 # f i f t e e n m i n u t e s i n s e c o n d s
)

# a d d i n g a map f r o m a v e c t o r l a n d d e f i n i t i o n
# and s e t t i n g t h e r e f l o a t i n g h a l f − l i f e
model . map = MapFromBNA( ’ . /GuamMap . bna ’ ,
r e f l o a t _ h a l f l i f e =6 # h o u r s
)

# Adding n e t c d f o u t p u t f o r t h e r e s u l t s
model . o u t p u t t e r s += NetCDFOutput ( ’ script_guam . nc ’ )

# Adding a s p i l l
model . s p i l l s += p o i n t _ l i n e _ r e l e a s e _ s p i l l ( num_elements =1000 ,
start_position =(144.664166 , # longitude
13.441944 , # l a t i t u d e
0.0) , # depth
 output 6

release_time=start_time )

# Adding Random w a l k d i f f u s i o n
model . movers += RandomMover ( d i f f u s i o n _ c o e f =50000)

p r i n t ’ adding a wind mover : ’

# Adding winds f r o m g r i d d e d wind m o d e l o u t p u t

model . movers += GridWindMover ( w i n d _ f i l e )

# Adding C u r r e n t s f r o m a g r i d d e d h y d r o d y n a m i c m o d e l
model . movers += GridCurrentMover ( ’ . / hycom_ouput . nc ’ )

# Run t h e m o d e l :
model . f u l l _ r u n ( l o g=True )

6 output
GNOME has a variety of output options, including visual images and anima-
tions of the spill transport, tabular data about the oil weathering processes,
and a netcdf format that can store all the element positions and data associ-
ated with the particles, allowing for any number of post-processing options.

7 extending
GNOME can be easily extended by writing new movers or weatherers that
implement new algorithms. The API has been carefully designed to allow
users to write a new component with minimal knowledge of how the rest
of the system works. Components can be written in Python, or an language
that can be called fro Python, such as Fortran, C or C++.

8 web interface
In addition to scripting and batch mode, an extensive easy-to use web
browser based user interface has been written to facilitate easy and ca-
sual use. The model can be accessed and run on NOAA servers at http:
//gnome.orr.noaa.gov. The public NOAA version includes pre-initialized
locations for use at select locations primarily in the United States. In addi-
tion, users can set up and run a non-specific location oil weathering model
and access the oil database through the NOAA web interface.
The web interface can also be run locally on a users personal machine, or
set up on a server at any location.

9 participating in development
The GNOME source code is all open source. You can find the code on gitHub
at: https://github.com/NOAA-ORR-ERD/PyGnome. Technical documentation
 conclusion 7

is available at: http://noaa-orr-erd.github.io/PyGnome/. With the source

code, anyone is free to run teh code, fix issues, add features, and re-purpose
the code to work with an new system. If anyone makes a fix or addition that
may be useful to others, we welcome submissions. gitHub’s “pull request”
feature is an excellent way to submit suggestions for review.

10 conclusion
The new NOAA oils spill modeling tools have been developed to support
NOAA ERD’s mission, but have also been designed to be as flexible and
extensible as possible.