►
From YouTube: CESM Workshop: Software Engineering Working Group
Description
The 26th Annual CESM Workshop will be a virtual workshop with a modified schedule on its already scheduled date. Specifically, the virtual Workshop will begin with a full-day schedule on 14 June 2021 with presentations on the state of the CESM; by the award recipients; and three invited speakers in the morning, followed by order 15-minute highlight and progress presentations from each of the CESM Working Groups (WG) in the afternoon.
On 15-17 June 2021, working groups and cross working groups have half-day sessions, some with presentations and some that are discussion only.
A
A
C
B
Elizabeth
just
put
the
the
meeting
agenda
in
the
chat.
If
anyone
is
interested
in
pulling
that
up
all
so
I'll
show
that
in
just
a
minute.
B
We
I'll
we'll
go
ahead
and
get
started.
I
mean
it
looks
like
people
are
still
trickling
in,
but
just
to
kind
of
move
things
along.
We
have
a
full
agenda,
so
I'll
just
start
with
a
couple
of
introductions,
while
people
trickle
in
so
I'm
bill
sachs,
I'm
one
of
the
co-chairs
of
the
software
engineering
working
group
and
I'm
in
the
cesm
software
engineering
group
at
ncar,
along
with
a
new
co-chair
of
the
software
engineering
working
group,
lisa
bernardette
from
noaa
lisa.
Do
you
want
to
introduce
yourself.
A
Global
systems
laboratory,
so
I've
been
working
with
noaa
models
for
quite
a
while
and
I'm
a
scientist,
I'm
not
a
software
engineer,
but
I
do
have
an
appreciation
for
things
such
as
code
management,
public
releases,
documentation,
support,
so
that's
the
field.
I've
been
working
with.
B
So
we're
really
happy
to
have
lija
on
board,
as
as
the
new
co-chair,
as
as
there
is
kind
of
growing
collaboration
between
and
car
cgd
and
and
noaa
in
a
in
a
variety
of
areas
of
software
development,
some
of
which
you'll
get
to
hear
about
this
afternoon.
So
so
we're
happy
to
have
you
here
and
I
want
to
also
just
say
thank
you
to
the
to
the
previous
software
engineering
working
group
co-chairs
who
all
recently
stepped
down.
Marianna
bertenstein
rob
jacob
and
john
dennis.
So
thank
you
all.
B
They
all
served
the
software
engineering
working
group
for
for
many
years
before
this
change
exchange
of
co-chairs.
So
let
me
go
ahead
and
start
sharing
again
just
to
share
a
couple
of
logistics
for
this
afternoon.
B
So
we
will
have
a
couple
hours
of
a
series
of
talks
this
afternoon
and
then,
in
the
later
part
of
the
afternoon,
we'll
have
an
extended
discussion
session
on
the
wide
range
of
work.
That's
going
on
right
now
on
cesm
diagnostics,
packages
and
the
development
of
new
diagnostics
packages,
and
so
we
we
hope
that
many
people
can
stay
for
that
and
take
part
in
that
discussion.
I
think
that
should
be
an
interesting
and
engaging
discussion,
they're
interested
in
hearing
feedback
from
from
everyone
on
just
a
few
logistics.
B
The
meeting
is
being
streamed
to
youtube
and
being
recorded.
The
chat
will
also
be
recorded.
I've
been
told
that
that
includes
private
chat.
So
if
you
want
to
arrange
a
dinner
date
for
after
the
meeting
use,
some
other
means
please
make
sure
your
microphone
is
muted.
When
you're
not
talking
for
questions,
we
will
hope
to
allow
time
for
questions
after
each
talk
and
if
you
have
a
question,
you
can
either
raise
your
hand,
which
can
be
done
using
the
reactions,
button
and
zoom
or
type
your
question
or
comment
in
the
chat
speakers.
B
You
do
have
a
15
minute
slot,
just
in
the
interest
of
allowing
some
time
for
questions
we
hope
you'll
you'll
end
around
12
minutes,
we'll
give
you
a
two
minute
warning
at
the
10-minute
mark
and
I
just
want
to
also
remind
everyone
of
the
encarn
yukar
code
of
conduct.
So
please
try
to
offer
constructive
feedback
share.
The
air
acknowledge
teamwork,
encourage
innovation,
show,
appreciation
and
consider
new
ideas.
B
So
with
that,
I
would
like
to
introduce
our
first
speaker,
ann
fuyu.
I
hope
I'm
pronouncing
your
last
name
close
to
correct
from
the
nordic
e
infrastructure
collaboration
who's
going
to.
Let
us
know
about
some
work,
they're
doing
on
techniques
for
packaging
and
distributing
earth
system
models
so
and
if
you
want
to
share
your
screen
and
go
ahead
whenever
you're
ready.
D
E
Yes,
okay,
so
I
will
talk
about
this
earth
system
model
model
as
a
service.
This
is
a
work
where
I
do
with
my
colleague,
shonia
quinta
he's
working
at
the
university
of
oslo
in
norway,
and
this
is
done
in
the
context
of
two
projects,
your
snowdik
and
the
nicest
tool
project.
E
So
this
is
a
brief
of
outline
of
this
presentation.
First,
with
the
objective
requirement
and
the
approach
what
we
have
done
so
far-
and
this
is
also
where
we
would
like
to
get
feedback
from
you
guys
and
some
conclusions
and
next
steps
and
we
would
be
interested
to
have
collaboration.
There
are
many
things
we
don't
know,
and
you
know
that
could
be
very
helpful
for
us
to
to
make
progress.
E
So
this
is
something
that
we
would
be
interested
at
least
so,
the
main
objectives
and
the
requirements.
This
is
really
to
open
up
a
system
models
to
a
wider
range
of
users
and
to
increase
collaboration
paths
between
scientists
from
different
disciplines.
So
we
have
more
and
more
requests
from
people
not
from
the
earth
system,
modeling
community.
E
That
would
like
to
create
their
own
scenario
or
one
workflows,
and
they
would
like
to
do
it
in
the
context
of
climate
change,
mitigation
or
climate
change
impact
studies.
So
we
would
like
to
to
find
a
way
to
help
them
to
do
it
properly.
So
we
still
would
like
to
make
it
reproducible
so
to
this
is
quite
important,
especially
when
you
have
non-specialist,
and
we
would
like
to
increase
the
fairness
of
earth
system
models,
but
not
only
the
data.
It's
mostly
about
tools
and
workflows.
E
One
of
the
requirements
is
to
have
a
very
low
maintenance,
so
if
we
have
a
new
version,
ideally
we
just
want
a
number
to
change
a
number
and
everything
should
be
done
automatically
like
from
deployment
test,
validation,
etc.
So
we
would
like
to
have
like
a
single
recipe
for
multiple
usage
and
platforms,
and
everything
should
be
automated
and
open
source.
E
So
this
is
the
approach
and
we
would
start
like
with
packaging,
so
what
we
do
with
any
any
tool
like
cesm,
we
start
to
package
and
we
use
package
manager.
So
at
the
moment
we
are
using
conda
as
a
package
manager,
but
ideally
we
could
change
it
by
anything
and
then
automatically
we
want
to
create.
We
create
containers,
it
can
be
singularity
docker
or
whatever.
So
we
are
going
on
this
on
the
right
hand,
side,
and
this
from
once
we
have
a
container.
E
E
E
So
we
would
like
to
have
some
kind
of
registries
where
user
could
search
for
tools
could
search
for
containers
and
could
search
for
workflows
and
like
experiments
when
they
have
run
an
experiment
in
terms
of
infrastructure.
We
we
want
to
be
a
agnostic
from
the
underlying
infrastructure,
but
we
still
want
to
have
performance
so
to
be
able
to
run
on
on
any
cloud
or
existing
galaxy
web
server
if
they
exist
and
on
hpc,
including
exaskelson.
E
That's
what
we
would
like
to
to
do
what
we
have
done
so
far,
so
we
started,
for
instance,
with
csm,
and
we
started
to
package
and
to
containerize.
So
ideally
we
we
started
to
write
like
a
small
recipe
for
cesm.
It's
like
a
yaml
file
where
we
have
all
the
requirements
for
using
csm
and
we
did
the
same
for
norism.
No
esm
is
a
norwegian
earth
system
model,
it's
identical
to
cesm,
except
they
have
a
ocean
component
where
it
is
different
and
the
atmosphere
is
slightly
different.
E
E
So
what
we
have
started
to
do
is
we
started
on
like
virtual
machines
and
it
works
very
well,
and
then
we
say:
okay,
let's
try
an
hpc,
so
we
use
betsy
betsy
is
a
biggest
national
supercomputer
in
norway.
It's
not
maybe
very
big,
but
it's
still
the
biggest
for
norwegian.
This
is
where
they
are
running
semi-six
experiment.
E
So
here
this
is
the
result
for
a
relatively
small
configuration
comp
set.
This
is
a
norism.
This
is
nf
2000
klimo,
which
is
very
similar
to
your
f2000
climbo,
it's
in
terms
of
performance,
a
bit
lower
because
it's
additional
ios
all
and
it's
quite
low
resolution.
E
So
the
next
step
was
okay,
but
can
we
do
that?
If
we
we
take
the
same
container
and
we
run
it
on
a
completely
new
architecture
or
completely
new
machine,
and
we
don't
know
the
machine
and
we
deploy
it
in
less
than
one
hour.
So
we
when
we
went
on
the
oracle
cloud
infrastructure
and
they
have
like
bare
metal
hpc,
which
you
can
combine
to
create
a
hpc
cloud.
E
So
what
we
did
we
we
took
so
they
have
nodes,
they
have
36
processor
and
we
we
build
a
hpc
cluster
with
16
nodes
and
we
added
a
shared
file
system
and
big
gfs,
and
then
we
deployed
the
container
immediately
just
to
see
how
it
goes.
As
you
can
see,
it's
not
that
bad
as
you
increase
the
number
of
processors.
You
have
some
drop
in
performance
here.
This
is
related
to
big
gfs,
so
we
did
absolutely
nothing,
no
performance
improvement.
So
this
is
what's
really
to
to
test
if
it
was
efficient.
E
So
it's
not
too
bad.
It
could
be
improved
for
sure,
but
I
mean
we.
We
were
quite
happy
with
the
results,
so
the
next
step
was
okay,
so
we
have
the
container.
So
now,
let's
write
a
small
wrapper,
which
is
a
xml
wrapper
to
create
a
tool,
and
then
we
can
put
the
tool
into
a
register
and
then
we
can
create
start
to
create
workflows.
E
So
that's
what
we
did
and
then,
when
you
write
the
xml
wrapper,
we,
you
can
add
metadata.
So
we
add
some
metadata
for
a
small
ontology
for
tools,
so
it
can
be
searchable
and
fundable,
accessible,
etc,
and
the
main
advantage
of
this
xml
wrapper
is
out
of
the
box
without
any
additional
work.
You
have
a
small
graphical
interface.
It's
not
super
fancy.
E
I
think
you
will
show
something
much
nicer
later
on,
but
it's
still
good
enough
for
a
end
user
to
to
build
an
experiment,
and
this
is
based
from
what
I
have
chosen
for
inputs.
I'm
sure
it
can
be
improved,
but
I
mean
that's
the
main
ideas
and
from
this
you
also
have
a
graphical
interface.
So
you
can
combine
your
like
cesm
here
with
other
tools
to
make
some
workflows
that
you
can
share
with
end
user.
E
So
when,
when
you
get
a
workflow,
a
workflow
is
just
a
text
file
and
you
we
can
convert
it
in
a
common
workflow
language,
so
it
is
interoperable
and
you
can
register
it
in
a
in
a
register,
for
instance,
and
get
a
persistent
identifier
if
you
have
like
results
and
visualization
or
like
a
net
cdf
output,
you
want
to
to
share
what
we
want
is
to
gather
everything
at
least
like
cross-reference
and
put
it
in
what
we
call
a
research
object,
and
we
would
like
to
share
it
in
a
like
a
research
object
hub
where
people
could
search,
for
instance,
with
data
text
mining
facility,
some
experiments
that
have
been
done
somewhere
in
the
world
and
could
reuse
the
results.
E
If
you
don't
like
the
graphical
interface,
you
can
use
other
like
command
line
or
jupiter
lab.
It's
really
very
flexible
on
how
you
can
the
different
interfaces.
You
can
access
the
same
tool
conclusion
and
the
next
step
I
mean
there
are
a
lot
of
work
to
still
to
do.
There
is
no
documentation.
Mostly.
E
We
really
would
like
to
have
a
cesm
as
part
of
our
training
infrastructure
as
a
service,
which
is
a
free
service.
We
are
offering
to
everyone
in
the
world
and
they
can
book
like
a
virtual
classroom
and
they
can
teach
any
anything
like
any
tools
and
we
would
like
to
see
esm
to
be
part
of
it.
So
have
a
small
training
material.
For
this
add
some
more
different
models.
For
instance
in
the
nordic
we
are
using
eco.
So
it's
probably
something
we
need
to
add.
E
I
heard
you
are
developing
some
new
new
diagnostics,
so
it's
probably
maybe
something
useful
to
add.
As
a
post
process,
we
have
started
to
containerize
the
ncaa
vrm
editor
and
I
think
we're
here.
We
could
have
a
like
a
use
case
where
you
can
create
your
own
grid
and
then
you,
you
create
your
experiment
out
of
it.
I
think
it
could
be
maybe
of
added
value,
maybe
something
we
could
do
as
part
of
a
training
material.
E
I
don't
know,
but
I
would
be
happy
to
get
any
question
feedback
and,
as
I
said
before,
we
would
be
very
interested
to
to
collaborate
in
some
ways.
I
mean
there
are
many
things,
the
scripts
we
don't
know,
and
we
could
do
better,
for
instance,
and
that's
it.
B
Thanks
very
much
and
that
that
is
really
interesting
and
really
good
to
hear
about
we
do
have.
We
do
have
a
few
minutes
for
questions.
I
see
one
question
in
the
chat
that
I'll
start
by
by
reading
from
peter
caldwell,
are
you
able
to
choose
optimal
pe
layouts
automatically,
as
you
move
your
container
to
different
machines
with
different
cores
per
node.
E
Yes,
so
I
mean
this
is
an
area
where
I'm
not
so
good
because
I
don't
know
very
well
csm,
so
I
I
could
see
we
could
change
this.
We
create
this
configuration
machine
where
you
can
specify
the
number
of
processors
per
node
and
they
have
this
config
p
layout,
which
I
don't
know
very
well
how
to
make
it
best.
So
we
try
like
a
adork
algorithm
which
seems
to
work,
but
I'm
sure
there
are
some
improvements
here.
D
E
Yeah
so-
and
this
is
why
I
was
talking
about
these
registries
because
one
of
the
main
problems
we
we
see
for
people
not
from
the
earth
system-
modeling
community
or
even
not
knowing,
for
instance,
cesm.
They
don't
even
know
how
to
search
and
what
to
search.
So.
We.
G
E
Would
like
to
improve
this
part
where-
and
this
is
where
I
was
talking
at
the
end,
we
would
like
to
have
like
text
mining
for
searching
experiment,
because
usually
what
they
want
to
do
is
like
to
write
a
sentence.
Is
there
anything
with
a
double
co2
or
something
like
that?
Any
experiment
and.
D
B
E
E
B
Oh,
I
have
a,
I
have
a
question,
but
it
kind
of
ties
together,
your
talk
and
and
the
upcoming
talk
which,
which
is
from
brian.
So
maybe
I'll,
ask
the
question
now,
but
we
can
hold
off
on
answering
it
until
after
brian's
talk,
which
is
I'm
I'm
just
interested
to
have
a
couple
minutes
of
discussion
on
whether
and
how
it
would
make
sense
to
to
coordinate
the
kind
of
containerization
and
and
cloud
activities
of
of
our
two
groups.
Since,
since
it
seems
like
there's
a
lot
of
great
work
in
that
area,.
D
B
E
D
B
All
right:
well,
let's,
let's
go
on
then
to
the
the
next
speakers
is
brian
dobbins,
I'm
remembering
the
schedule
right.
Yes,
who
will
be
telling
us
also
about
the
kind
of
container
and
cloud
activities
that
he's
been
working
on
for
cesm,
so
brian?
Take
it
away.
I
Yes,
thumbs
up
all
right:
yes,
we're
good,
so
yeah!
This
is
great
to
go
after
anne.
I
was
really
excited,
so
she
was
sending
her
slides
to
elizabeth
this
morning
and
I
was
like
I
couldn't
resist,
but
looking
at
them,
because
we
have
very
similar
design
goals.
So
I'm
already,
I
sent
her
an
email
already
and
said
this
is
really
cool.
I'd
love
to
talk
to
chad,
so
I'm
hoping
we
can.
We
can
do
that
soon.
I
I
Oh
and
there
we
go
all
right.
So
there's
three
things
I
want
to
cover.
So
I'm
going
to
talk
about
csm
platforms,
you've
kind
of
already
gotten
some
of
this
from
from
what
ann
was
saying,
but
maybe
not
the
same
verbiage,
some
infrastructure
for
the
cloud
and
then
some
database
infrastructure,
which
is
really
cool
databases,
don't
excite
people,
but
I'm
hoping
after
this
you'll
be
pretty
excited
about
what
we
can
do
so
okay.
So
what
is
the
platform?
I
So,
as
everyone
here
who
has
tried
to
port
csm
knows
it's
it's
a
little
complicated
you've
got
not
just
the
code
that
we
released,
but
also
everything
from
an
mpi
library,
compilers,
netcdf,
git
subversion.
You
got
to
customize
some
files.
So
what?
If,
in
addition
to
just
releasing
code,
we
can
also
release
platforms
that
people
can
just
download
and
it's
all
pre-configured
and
ready
to
go,
and
the
answer
is
well.
This
is
what
containers
and
clouds
will
let
us
do
so,
both
cases
and
containers
and
clouds.
I
We
can
pre-configure
them
with
the
full
environment
we
want
and-
and
you
can
also
standardize
it.
So
one
of
the
issues
we
have
is
that
people
you
know
on
different
systems.
They
have
different
versions
of
python.
Different
versions
of
the
intel
compiler
different,
you
know
we
can
standardize
all
that
and
make
sure
that
there's
a
a
single
platform
that
we
know
works
the
same
for
for
users.
We
can
even
standardize
between
the
container
and
cloud
platform,
so
you
can
move
from
one
to
the
other
pretty
transparently.
I
So
what's
the
difference
between
these
well
containers
are
something
that
we
use
on
existing
hardware
that
you
have
access
to.
Clouds
are
something
where
you
can
rent
hardware.
You
can
actually
run,
of
course,
the
container
on
rented
cloud
space
as
well,
but
that's
the
main
difference
is.
If
you
have
stuff
you
want
to
use
you
already
own.
You
use
a
container.
If
you
are
just
need
more
resources,
you
can
use
the
cloud
so
with
both
of
these,
yet
we
can
kind
of
basically
get
people
up
and
running
in
minutes.
I
So
we've
done
this
with
some
grad
students
who
are
struggling
to
run
cesm
at
the
university
and
we're
like
hey,
try
this
and
they're
up
and
running
in
like
five
minutes-
and
you
know,
there's
still
work
to
do
obviously,
but
it
really
makes
a
big
difference.
It
even
runs
on
windows
systems
or
macs
or
linux.
You
know
you
can
you
can
run
the
container
pretty
much
anywhere,
which
is
a
really
big
plus
one
example
of
a
platform
is
so
in
addition
to
just
cesm.
I
We
can
combine
this
and
do
cesm,
plus
a
jupiter
lab
environment.
Add
in
the
the
many
python
packages
that
are
in
the
standard,
pangeo
stack
and
in
some
add
in
some
tutorials,
and
now
you
have
a
standardized
platform
that
works
everywhere
works
the
same
everywhere.
This
allows
you
to
develop
documentation
to
teach
new
users
stuff,
and
so
you
know
this
is
an
example
from
this
cesm
lab
and
we
will
start
releasing
these
tied
to
csm
releases
in
the
near
future.
I
Okay,
so
I'm
going
to
switch
gears
a
little
bit
and
talk
about
some
cloud
infrastructure.
So
everybody
hears
about
the
cloud
and
if
you
listen
to
the
vendors
they're
like
the
the
cloud,
is
you
know
it's
great?
It's
just
you
know
infinite
scalability
and
they
talk
about
all
the
good
size
of
the
cloud.
I
They
don't
talk
about
how
complex
it
is,
and
that's
especially
true
with
a
model
like
cesm,
which
is
already
complex,
so
peter
caldwell
was
asking
about
load
balancing,
and
so
what
happens
when
you
have
a
cloud
where
you
have
six
different
node
types
and
different
network
types
and
different
processor
types,
and
that's
just
one
vendor,
and
then
on
top
of
that
you
have
multiple
vendors.
Each
vendor
has
different
region.
Each
region
has
different
pricing.
I
We
don't
want
atmospheric
scientists
to
kind
of
have
to
struggle
through
the
cloud
we
want
them
to
just
be
able
to
say.
I
want
to
run
this
into
cloud
and
make
a
best
choice
on
that.
So
an
example
of
this
is
this:
is
a
recent
use
case.
So
a
bw1850.
This
is
a
wacom
case.
Amazon
might
be
cheaper
per
node,
but
azure
scales
better.
I
So
the
same
case
if
you're
running
on
on
amazon
might
be
better
on
eight
nodes,
but
it
might
be
better
on
16
nodes
on
azure
and
better
meaning
cost
optimal
in
this
case,
so
it's
complicated.
So
how
are
we
addressing
this?
Well,
we're
going
to
create
this
cloud
api
that
basically
allows
people
to
just
say:
hey.
I
I
want
to
run
a
cluster
in
the
cloud
or
I
want
to
launch
this
job
in
the
cloud
and
we
decouple
those
sorts
of
requests
from
all
the
back
end
logic
that
goes
into
determining
what's
best
and
then
spinning
up
these
cloud
resources
for
people.
We
want
to
do
this
with
their
credentials
so
that
we're
not
we
don't.
I
You
know
we
can't
run
everybody's
runs
for
them,
and
so
we
we
don't
store
any
credentials
because
that's
the
security
problem,
but
we
can
update
this
this
functionality
in
a
fully
decoupled
way,
so
that
you
know
right
now.
I
have
it
sort
of
working
with
amazon.
It's
still
in
development.
We
can
add
azure
as
we
get
more
access
to
that.
We
can
add.
Google
cloud
and
the
user
side
still
looks
the
same.
I
So
here's
an
example
of
this
for
creating
a
cluster
so
on
the
left
is
just
what
you
normally
see
as
a
user
on
the
right,
I've
added
a
lot
of
the
verbosity
just
so
you
can
kind
of
see
the
details
of
what's
happening.
So
I
run
this
command
csm
create
cluster.
This
is
this
is
an
unreleased
tool
right
now
we're
still
working
on
it
and
what
it
does
is
it
says:
okay,
you're
trying
to
create
a
cluster.
I
Well,
okay,
you
haven't
given
me
any
any
information
on
comp
set
or
resolution,
which
are
things
that
affect
performance
and
you're,
just
saying
optimized
for
cost.
I
was
only
going
to
look
at
the
cost
of
hardware
for
this,
and
it
knows
it's
me:
it's
just
doing
a
single
user.
You
can
do
classroom
use,
though,
with
a
list
of
users.
I
It's
going
to
query
what
clouds
I
have
access
to
via
my
credentials
and
then
just
spins
up
a
cluster.
All
I
get
is
an
ssh
command
with
an
ip
address
and
that
cluster
will
be
fully
ready
to
run
cesm
and
that
cluster
is
fully
compatible
with
the
containerized
version.
You
can
run
on
your
laptop.
In
fact,
this
is
where
I'm
not
showing
it
here.
I
I
have
it
later
because
I
know
I'm
going
to
run
out
of
time,
but
if
you
wanted
to
run
a
laptop
you're
running
the
container
on
your
laptop,
you
want
to
offload
a
run
to
the
cloud,
it's
just
as
easy
as
to
as
this
as
well.
All
right.
So
I
know
this
is
this
is
fast
covering
a
lot
of
ground
here.
I'll
switch
one
more
moment
to
some
database
infrastructure,
and
so
this
is.
I
This
is
seemingly
a
different
topic
right
now,
we'll
loop
back
to
the
cloud
on
the
next
slide,
but
we
always
have
this
big
question
of
how
is
cesm
being
used,
and
you
know
I
know
that
there
are
people
that
look
through
publications.
We
we
talk
to
people
at
conferences
like
this.
We
have
some
sense
of
that,
but
wouldn't
it
be
better
if
we
had
actual
data
and-
and
we
can
do
this-
we
can-
we
can
set
up
a
database
that
gets
updates
from
runs
and
and
we're
not
evil.
I
So,
of
course,
people
can
can
turn
us
off
and
it's
anonymized
data
anyway,
but
this
would
give
us
usage
trends
over
time
and-
and
this
is
useful
to
pretty
much
everybody,
so
scientists
can
do
you
know
meta-analysis
of
climate
experiments.
They
can
look
for
areas
that
are
not
being
run,
resolutions
that
are
not
being
run
csm
developers.
We
would
love
this
because
it
informs
us
of
trends
and
one
thing
that
you
know
even
model
improvements
like
we
can
collect
metadata
on
source
mods.
I
We
don't
want
to
collect
source
mods,
because
that's
people
doing
work
that
they're
going
to
be
publishing,
but
we
can
say,
hey
like
which
file
was
modified
and
if
we
have
a
file
that's
modified
often.
Maybe
this
informs
us
that
we
need
to
expose
some
of
that
functionality
via
name
lists
or
some
other
stuff
that
doesn't
require
modifying
source
and
obviously
nsf
would
love
some
high
level
view
on
cesm
use.
You
know
just
that's.
They
would
love
that.
So
this
is
one
use
case
for
a
metric
for
a
database.
I
Another
one
we
talked
a
little
bit
about
cloud
runs
so
in
clouds
we
can
create
clusters
or
we
can
create
runs.
We
we've
seen
some
limitations
with
spinning
up
a
cluster
and
trying
to
do
large
scale
runs
so
now
we're
looking
at
disconnected
runs,
so
you
just
launch
a
run
and
it
doesn't
need
to
be
connected
to
a
cluster.
This
raises
some
questions,
though,
of
what
do
you
do
with
you?
Don't
have
a
qstat.
You
don't
have
a
persistent
file
system
that
you
can
just
check
on
see
where
your
job
is.
I
So
you
need
some
status
update
of
how
your
run
is
going,
and
this
is
ironically,
what
things
like
pbs
pro
and
slurm
do.
Is
they
use
databases,
so
we're
just
kind
of
reinventing
the
wheel
here,
but
because
we're
working
for
a
specific
application
or
we
can
return
more
than
just
how
long
it's
been
running
or
how
long
it's
been
sitting
in
the
queue
we
can
return.
Cesm,
specific
information
like
what
year
it's
on
or
what
model
date
or
expected
finish
time,
simulated
years
per
day,
data
volume.
I
On
top
of
that,
we
don't
have
to
just
track
individual
jobs
like
let's
say
that
you
had
a
10
000
member
parameter
sweep
and
you
could
give
it
an
id.
That
is
a
project
you
could
track
all
10
000
of
those
as
one
run
and
just
kind
of
see
what
percentage
done
it
is
and
if
you
have
a
public
database,
you
know
I,
I
know
most
people
here.
I
You
know
we're
always
in
front
of
our
computers
we
like
to
disconnect,
but
just
in
case
you're
off
on
the
beach,
and
you
want
to
check
your
cesm
runs.
You
can
look
at
an
app
on
your
phone
and
see
what
the
status
is
too.
So,
there's
a
lot
of
potential
here
from
this.
So
I
know
I'm
running
out
of
time,
so
I
I
get
really
excited
about.
You
know
new
functionality
like
this,
so
here
are
some
other
things
you
can
do
with
a
database.
I
I'm
gonna
go
a
little
out
of
order
because
I
think
I
saw
peter
ask
about
load
like
load,
balancing
and
stuff.
This
is
a
really
complicated
task
in
csm,
as
I
think
some
of
you
know,
and
it's
getting
worse
and
part
of
it
is
there's
new
components
all
the
time.
There's
new
hardware,
you
know,
there's
there's
variable
resolution
grids.
I
So
how
do
you
know
what
an
optimal
layout
is,
and
so
one
thing
that
we
can
do
is
we
can
sort
of
start
setting
up
machine
learning
once
we
have
enough
data
where
you
say
oh
well,
you're,
on
this
kind
of
processor,
with
this
kind
of
network
you're
running,
you
know
this
number
of
processors.
We
estimate
this
will
be
a
good
grid
and-
and
you
know,
as
we
get
more
data
that
gets
better
and
better
it's-
I
don't
expect
it
to
be
perfect,
but
I
think
it'll
beat.
I
You
know,
sort
of
naive,
decompositions,
pretty
quick.
Finally,
one
other
one
I'll
mention
you
know
again,
let's
say
that
you
had
this
this.
Let's
say
we
were
doing
a
parameter
sweep
between
ncar
and
two
partner
universities
and
we
set
up.
You
know.
Ten
thousand
small
runs
that
we
wanted
to
do.
Well,
if
you
have
a
central
database
in
a
standard
platform,
you
could
have
your
systems
opportunistically,
pull
a
run
from
the
database
that
needs
to
be
run,
run
it
and
then
notify
the
database.
I
That's
done
and
you
can
sort
of
distribute
your
computing
here
and
coordinate
with
other
universities
or
other
partners.
There's
a
lot
of
neat
functionality
that
we
can.
We
can
do
here.
I
I
could
go
into
more,
but
I
think
I'm
pretty
much
out
of
time
already,
so
I
will
pause
and
take
questions.
B
Thank
you
very
much
brian.
That's!
That's
really
excellent.
Thanks
for
sharing
that,
let's
see,
there's
a
couple
of
questions
or
comments
in
the
chat.
I'll
start,
there's,
I
think,
was
just
maybe
a
comment
from
hendrick
the
hidden
costs
of
cloud
data
egress.
I
don't
know.
H
Yeah,
just
just
just
intend
intended
as
a
command
our
smaller
or
smaller
one-off
experiments
in
the
cloud
are
fine
we're
getting
into
real
trouble
when
we
try
to
link
all
the
different
data
that
we
keep
at
different
places,
so
yeah,
and
so
that
may
be
actually
also
a
problem
with
the
last
example
that
was
given.
H
I
Sure
yeah
we're
seeing
this
now
with
a
project
that
we're
doing
where
you
know
so.
Academic
institutions,
I
think,
have
a
waiver
of
egress
up
to
15
of
compute
costs,
but
we
found
out
only
in
the
month
in
which
you
do
the
compute.
So
if
you,
if
you
do
three
months
of
compute
and
then
try
to
download
all
your
data,
nothing
is
waived.
So
this
is
definitely
a
problem
that
we've
got
to
deal
with.
You
know
and
there
are
yeah.
I
Storing
things
in
the
cloud
is
great,
but
even
if
you
do
something
distributed,
we
could
use
like
globus
automated
to
transfer
to
a
university
right
after
the
run
that
minimizes
it
because
you're
doing
at
the
same
time
as
compute.
So
there's
a
lot
of
a
lot
of
options
but
yeah.
I
agree.
It's
it's
a
messy
complex
thing
and
nobody
wants
big
bills.
B
I
Oh,
that's:
that's
a
com
like
I,
so
we
create
the
cloud
capability
primarily
for
external
users.
I
don't
see
it
being
viable
economically
in
terms
of
you
know
replacing
something
like
cheyenne
or
duratio.
It's
it's
simply
too
expensive.
On
a
large
scale
case.
There
are
systems
so
like,
for
example,
again
this
bw1850
case
we've
got
experience
running
this
on
aws.
I
We
notice
scaling
problems,
but
azure
has
a
amd
milan
based
infiniband
connected
cluster,
which
is
kind
of
similar
to
what
the
ratio
is
looking
like
and
doesn't
have
the
scalability.
So
performance
is
definitely
fine,
but
again
the
cost
is
just
prohibitive,
for
you
know
compared
to
on-premise
stuff,
so
I
I
don't
see
it
as
being
viable
for
something
as
large
as
cmip7.
Unless
the
cloud
vendors
wish
to
give
us
a
whole
lot
of
free
credits,
so
yeah.
B
I
So
absolutely
so
that
the
catch
is
I
mean
yes,
you
can
download.
I
can.
I
can
send
you
an
email
afterwards,
you
can
download
the
container
now
and
you
could
run
it
on
a
simple
laptop.
The
catches
are
going
to
be
limited
in
terms
of
what
you
can
run
from
the
memory
on
your
laptop.
If
you
have
a
departmental
server
that
gives
you
a
little
bit
more
flexibility,
but
it
just
depends
so
you
can
run
you
know
yeah,
I
I
can.
I
can
send
you
more
information.
I
You
can't
run
like
a
fully
coupled
b1850
on
a
laptop
because
it
requires
like
80
or
90
gigs
of
ram,
but
you
can
run
a
four
and
a
half
degree
atmosphere
case
or
a
lot
of
the
simpler
models,
and
that's
something
that
we've
seen
a
lot
of
interested
in
and
yeah
I'd
love
to
chat
with
you
more
about
that.
B
I
Yeah,
so
that's
a
really
interesting
question,
so
we
would
store
the
database
we'd.
This
would
be
a
cloud-based
database
just
because
we
would
avoid
issues
with
ncar's
firewall
most
likely
by
having
it
outside
the
there
in
terms
of
runs.
This
is
something
that
we'd
use
moving
forward,
but
if
this
project
did
get
its
initial
look
by,
I
I
trawled
through
all
of
scratch
and
found
like
a
million
timing
files
and
loaded
them
into
a
database.
I
Well,
I
should
say
like
so:
we
use
databases
for
cesm
where
we
have
a
timing
database.
We
have
a
an
experiment
database.
These
are
kind
of
different
databases
like
talking
about
databases
like
talking
about
code,
you
have
different
kinds
of
applications
and
codes,
we're
talking
about
a
basically
a
key
store,
nosql
database
for
this,
so
it's
much
more
scalable,
much
easier
to
use,
and
it's
just
all
anonymized
similar
entries,
but
yeah.
This
would
be
on
the
cloud
we'd
start
with
newer
data,
because
we
want
to
collect
additional
information.
I
Right
so
this
is
still
a
very
open
question,
so
you
know:
there's
there's
there's
questions
there,
because
if
you
have
a
public
tool,
you
don't
want
to
leave
it
fully
open
to
anybody
to
add
whatever
they
want,
because
you
might
get.
You
know
strange
things
added
and
so
we're
looking
at,
but
we
do.
We
would
like
people
to
be
able
to
tag
like
their
work
and
then
you
could
maybe
envision
like
a
create
clone
command.
That
can
pull
straight
from
a
reference
to
work
from
a
database
or
something
like
that.
I
So
there's
a
lot
of
things
that
that
I
think
we
can
add,
and
I
think
that
the
overall
design
of
this
is
sort
of
orthogonal
to
to
the
the
the
metadata
tags,
but
the
one
I
mentioned
that
I
really
am
interested
in
is
again.
We
don't
want
to
collect
source
mods,
but
we
want
data
on
which
files
are
modified
so
that
we
can
kind
of
maybe
work
on
making
them
easier.
So
that's
one
bit
of
metadata
I'd
love
to
collect
yeah.
B
Great
well
thanks
a
lot.
There's,
there's
more
coming
in
there's,
there's
a
few
more
comments
that
I
didn't
repeat
in
the
chat,
as
well
as
a
couple
questions
at
the
end.
So
if
you
want,
if
you
get
a
chance
to
answer,
there's
a
question
from
brian
medeiros
and
from
adriana
foster,
if
you
get
a
chance
to
answer
those
in
the
chat,
I'm
sure
might
appreciate
it,
and
I
will
let
sounds
like
you
and
ann
already
are
already
connecting.
B
So
that's
great,
so
I'll,
let
you
guys
maybe
address
and
I'd
be
happy
to
be
part
of
a
discussion.
I'm
sure
a
number
of
us
would
on
how
we
can
coordinate
these
different
cloud
and
container
efforts
between
ces
and
nor
esm,
but
we
could
take
that
offline
thanks
brian.
Thank
you.
Next
up
we
have
alpera
altoontis
who's
gonna,
be
showing
us
some
work
he's
been
doing
on
putting
together
a
graphical
user
interface
for
cesm,
in
particular.
The
simpler
models
framework
so
help
her.
Take
it
away.
G
G
All
right,
so
my
name
is
I'm
a
software
engineer
at
the
oceanography
section
at
encar
and
more
recently,
I'm
also
working
on
this
simpler
models,
framework
toolkits
that
we
are
developing
for
the
broader
cesm
and
so
I'll
present
a
visual
tool,
a
gui
for
users
to
create
csm
cases,
and
the
goal
here
we
have
is
to
streamline
coupled
and
simple
modeling
within
csm,
and
also
enable
this
idea
of
hierarchical
modeling,
where
users
can
mix
and
match
different
model
components
with
varying
complexity
and
have
a
hierarchy
of
experiments
models.
G
And
we
have
in
developing
several
tools
I'll,
be
talking
about
two
of
these
tools:
a
new
relational
metadata
and
an
associated
infrastructure
for
that
metadata
to
be
processed
and
also
a
graphical
user
interface.
And
so
the
emphasis
here
is
on
simpler
modeling.
But
we
also
envision
these
tools
to
have
a
broader
utilization
beyond
simpler
modeling
and
within
the
broader
csm
applications.
G
So
the
tool
chains
that
we
have,
we
would
like
to
provide
a
few
key
functionalities.
The
first
one
I'll
mention
is
that
we
want
users
to
be
able
to
query
what's
available
within
csm,
which
is
a
which
is
a
lot
of
options
really,
and
you
want
to
be
able
to
list
these
options.
We
want
to
be
able
to
visualize
them
for
users
to
select
from
those
options,
and
we
also
want
to
enable
users
to
create
their
own
custom
configurations
where
they
can
mix
and
match
different
options.
G
So,
first
I'll
briefly
describe
this
new
metadata
to
be
incorporated
in
scene.
This
new
method
data
is
going
to
be
in
a
file,
a
yml
file
that
we
call
config
comply
this
sort
of
resembles
our
legacy
config
files.
But
the
goal
here
is
to
express
relatively
complex
interdependencies
and
incompatibilities
between
different
options
like
the
ocean
grid.
G
What
atmosphere
component
that
we
use
or
what
the
mode
that
we
have
for
a
certain
component
and
these
options
might
be
specified
in
different
config
files,
but
within
the
config
comply
file
we
can
express
some
rules,
some
compliance
rules
to
be
checked
and
satisfied,
and
we
also
aim
for
this
new
metadata
to
be
concise
and
highly
expressive,
and
we
want
to
be
able
to
support
arbitrary
expressions
in
these
in
this
new
metadata
and
the
infrastructure
that
we
are
using
is
that
this
new
file
format
is
yaml,
we're
using
yaml
file
format
and
as
for
the
syntax,
within
this
file,
we
can
have
arbitrary
python
expressions
in
the
forms
of
assertions
that
may
include
literals,
logical
or
arithmetic
operators
and
seam
case
variables,
and
a
we
developed,
a
python
module
to
be
added
into
seam
that
parses
this
new
metadata
and
then
evaluator
within
the
gui
tool
that
evaluates
and
determines
whether
any
rules
that
we
add
in
this
file
is
satisfied
or
not.
G
And
here
I
have
few
examples
from
this
file.
As
you
can
see,
this
is
in
yaml
format,
but
also
uses
python
syntax.
So
I
have
three
rules
here
that
are
specified
by
python
assertions,
the
first
one
being
the
simplest
one,
which
says
that
cam
cannot
be
coupled
with
data
eyes,
and
here
is
the
logical
expression
that
enforces
this
assertion
or
we
can
have
a
little
more
involved.
G
G
So
the
next
is
the
gui
that
makes
use
of
that
metadata,
and
the
purpose
for
this
gui
is
to
guide
the
users
through
the
process
of
creating
csm
cases
and
primarily
choosing
appropriate
comp
sets
and
grids.
Here
we
use
ipi
widgets
module.
This
is
a
python
module
that
works
on
jupiter
lab
and
it's
highly
portable
and,
I
think
widely
used,
and
so
we
imagine
this
tool
be
able
to
run
on
clusters,
local
machines
or
even
cloud
and
web,
and
I
think
brian
has
some
ideas
on
that
front.
G
Again,
we
don't
need.
We
don't
expect
users
to
be
familiar
with
python
or
jupiter,
it's
fully
graphical,
and
so
now
I'm
going
to
go
into
this
live
demo.
But
before
that
I
should
mention
that
the
tool
is
still
in
an
experimental
stage
and
it's
a
prototype
with
some
of
the
key
features
not
yet
finalized,
and
with
that,
let
me
switch
to
a
notebook.
G
So
all
the
user
has
to
do
now
is
to
run
this
cell
jupyter
note
excel,
which
basically
imports
the
gui
and
then
calls
its
display
method.
So
when
you
run
this
you'll
get
two
consecutive
dialogues
step.
One
is
where
the
user
selects
some
preliminary
variables
and
then
once
this
preliminaries
are
confirmed,
we
move
on
to
the
second
second
step.
That
is
create
case,
so
we
can
select
from
different
drivers,
and
now
here
we
have
two
modes
predefined
and
custom.
G
So
the
predefined
is
where
the
user
can
query
from
already
available
configurations
within
csm
already
defined
once
and
the
custom
one
is
where
the
user
can
create
their
own
configurations,
but
let
me
first
start
with
the
predefined
one
and
I'll
hit
confirm
I
get
this.
I
get
to
this
new
dialogue
create
case
so
initially,
so
the
ultimate
goal
here
is
to
select
the
comp
set
and
the
grid,
and
then
we
can
give
it
a
case
name
and
create
the
case,
but
initially
we
have
229
available
comp
sets.
G
These
are
all
of
the
concepts
that
are
defined
in
cesm
and
we
can
narrow
this
down.
For
instance,
we
can
let
the
gui
know
that
we
only
want
to
see
the
scientifically
supported
ones
and
now
I'm
down
to
27
available
component
sets
or
I
can
select
these
individual
components.
Maybe
I
know
that
my
ocean
component
should
be
pop
and
then
I
picked
up
here
it
narrows
down
and
perhaps
for
the
atmosphere
component.
G
G
I
can
select
from
different
initialization
times
and
this
time
I
can
also
fine-tune
the
components
that
I
want
to
work
with.
For
instance,
if
I
pick
cam
here,
I
can
select
from
different
cam
physics
and
when
I
select
different
cam
physics,
options
get
updated
and
to
get
information
about
these
options.
I
can
power
over
these
buttons
and
I'll
get
the
descriptions
of
these
and
I'll
just
randomly
pick
some
components
here
and,
as
you
can
see,
as
I
make
more
decisions
make
more
selections
here.
G
Some
of
the
options
become
ineligible,
so
datawave
here
becomes
knowledgeable
and
if
I
click
on
this,
I
get
an
error
message.
G
Emailed
wave
selection
mum6
cannot
be
coupled
with
datawave
component,
and
so,
if
I
want
to
make
the
state
away
available
again,
I
can
change
my
ocean
component
to
say
pop
and
then
data
a
becomes
eligible
available
and
when
I
pick
data
wave
now,
mom
six
becomes
ineligible
for
the
same
exact
reason
and
I'll
pair
it
up
two
more
so
once
okay,
so
once
I
make
all
these
selections,
I
again
get
a
comp
set
name.
G
G
G
We
want
to
provide
more
guidance,
so
so
those
concept
names
are
still
cryptic
and
we
want
them
to
be
more
expressive
and
clear,
and
we
are
planning
to
establish
automated
testing.
We
have
some
ideas
on
that
and
explore
alternative
logic.
Solvers
like
the
smt
satisfy
will
be
modulated
solvers
and
hopefully
we
will
be
releasing
a
stable
version
for
early
users
to
experiment
with
this.
But
for
those
who
would
like
to
experiment
with
this
raw
version,
it's
publicly
available
in
this
github
repository,
and
with
that
I
will
conclude.
B
Thanks
a
lot
out
there
for
sharing
this
awesome
work
with
us
and,
let's
see,
there's
we
have
time
for
a
couple
questions.
I
do
see
a
couple
questions
in
the
chat
so
I'll
start
there,
steve
goldhaber
asks
will
yaml
come
with
seem
and
what
happens
for
users
on
environments
where
they
cannot
install
new
software.
You
can
share
your
perspective
or
I
can
share
mine
if
you'd
like.
B
Okay,
well,
I
think
this.
This
is
a
discussion
we've
had
on
and
off
in
a
number
of
contexts
over
the
last
few
years,
and-
and
I
think
my
perspective
on
it
is-
is
that
we
are
in
the
near
future
going
to
need
to
require
a
couple
of
non-standard
or
third-party
packages
to
python.
Probably
the
the
two
that
I
think
are
most
requested
are
yaml
and
an
scdf
package.
So
that's
a
bigger
discussion,
but
I
don't
know
if
I'll
hear
you
of
anything
you
want
to
add
to
that.
G
Yeah
I
pretty
much
agree
and
as
for
yayama,
we
also
use
it
for
our
mom
six
nameless
generator
and
I
know
nfc
uses
it
for
some
functionality
so
yeah.
I
think
that's
something
we
should
be
adding
soon.
B
D
G
B
Let's
see
one
last
question
and
I'll
ask
for
now:
would
this
gui
be
portable
for
non-entire
machines?
Maybe
ties
in
with
the
earlier
question.
B
Cool
thanks
again
albert
there's,
there's
a
couple
more
comments
and
another
question
from
ann
in
the
chat
about
licensing,
but
in
the
interest
of
time
I'll.
Let
you
take
a
look
at
the
chat
when
you
get
a
chance
and
we
will
move
on
to
the
last
speaker
before
a
short
break,
who
is
john
dennis
from
sizzle
group
at
ncar
who's
going
to
give
us
an
overview
of
gpu
enablement
activities
in
stp
and
the
asap
group
so
john,
whenever
you're
ready
go
ahead,
please.
C
Oh
I'm
gonna
unmute
myself,
all
right.
Hopefully
everybody
can
see
and
hear
me
now
so
so
thank
you
for
this
opportunity.
I'm
gonna
give
an
overview
of
stp
and
asap.
There
are
two
groups-
and
I
so
I'll
mention
who
those
people
are
here,
but
first
something
of
an
outline.
C
So
this
is
I'm
just
going
to
acknowledge
the
people
that
have
worked
on
this
project
or
the
the
four
projects
two
of
them
are
going
to
be
relevant
for
csm
and
two
of
them
are
or
not
within
within
csm,
but
they're,
just
kind
of
informational
about
what
we're
working
on
so
so
the
acknowledgements
are
the
application,
scalability
performance
group.
This
is
a
group
that
I
would
lead
at
in
within
sizzle
and
also
special
technical
projects
for
for
stp.
C
C
But
I
tried
to
get
as
many
as
I
could
remember.
So.
Some
of
the
funding
for
this
work
is
from
nsf
earthworks
base
funding
and
also
through
through
noaa,
through
the
eol
laboratory.
So
again,
four
projects
that
we've
been
working
on
the
first
one
is
the
parameterization
for
unified
microphysics
across
jail.
So
this
is
pumas,
and
this
is
so.
C
So
this
is
a
subs
grid,
scale,
sub
microscale
that
derive
the
formation
and
evolution
of
clouds
and
precipitation
particles,
and
so
this
is
a.
This
is
a
picture
here
of
all
these
processes
that
are
going
on
this
is
this
is
a
microphysics
package
that
is,
I
believe,
the
default
now
in
cam
and
and
so
some
of
the
details
of
this,
this
gpu
port.
C
Why
did
we
go
after
it?
Well,
it
consumes
about
five
percent
of
the
total
cam
execution
time,
and
it
only
had
six
tenths
of
a
percent
of
the
total
cam
volume,
so
so
cam
and
csm
in
general
is
a
very
large
code
base.
C
So
this
looked
like
as
easy
of
a
of
an
entry
in
as
far
as
impact
versus
code
volume,
so
there
was
code
changes
that
included
the
the
addition
of
of
directives,
open
acc
directives
into
the
code
for
both
the
pumas
code
and
and
also
for
the
cam
code.
You
can
see
the
the
kind
of
the
source
lines
of
code
changes
there,
so
a
modest
amount
of
directives
in
both
pumas
and
in
cam
it
did
have.
C
It
did
touch
a
lot
of
different
subroutines
because
of
the
deep,
the
deep
call
stack
that
is
used
in
this
code,
and
so
we
have
done
provided
these
modif
modified
versions
of
the
code
back
into
multiple
repositories,
the
pumas
repositories,
the
cam
and
the
the
seam
repository,
and
those
have
been
those
have
been
accepted.
So
the
status
of
this
this
code
right
now
as
far
as
execution
time
for
the
mg3
or
or
the
puma's
code
is
you
can
see
in
this
this
table.
C
It's
the
configuration
that
we're
running
is
an
f
2000
climbo
two
degree,
and
we
we
are
placing
this
this
two-degree
model
on
a
single,
node
and
or
gpu.
So
this
is
a
rather
large
dense.
It's
a
it's
a
it's
a
rather
large
problem
for
for
a
single
node,
and
so
you
have
the
when
we
set
key
columns
equal
to
16,
which
is
the
default
used
in
csm.
You
have
the
execution
times
there
and
you
also
have
the
384
b
columns.
So
what
you?
C
What
you
see
here
is
that
the
gpu
enablement
really
doesn't
quite
break
even
yet
even
on
this
rather
large
problem
on
a
single
node,
and
but
it
does
so
it
you
know
it
runs.
I
guess
it
runs
faster
than
the
pgi
compiler
on
on
casper,
with
this
very
large
p
columns
size.
So
so
that
was
with
mg3
and
pumas
some
other
work-
and
this
is
I
was-
I
was
very
involved
in
the
the
previous
section.
C
I'm
I'm
going
to
be
less
involved
in
this
one,
so
I'm
going
to
oscillate
here.
So
this
is
for
work.
That's
the
model
for
predictions
across
scales
for
the
ed
pass
atmosphere.
So
this
will.
C
C
So
the
approach
here
is
the
so
there's
a
you
know:
there's
the
the
call
stack
they
moved
most
of
the
the
code
onto
the
gpu.
C
There
were
certain
sections
of
the
code
that
were
not
really
compatible
with
the
gpu,
that
being
the
the
land
surface,
the
no
lens
land,
surface
model
diagnostics
and
shortwave
and
long
wave
radiation,
and
so
the
cpu
part
of
this
is
actually
handling
both
the
offload
and
the
other
components
that
do
not
do
not
play
well
with
with
the
gpu.
C
So
this
was.
This
was
kind
of
timing
results
from
the
ballot
about
two
years
ago.
C
They
have
since
improved
the
message
passing
characteristics.
I
did
not
include
that,
so
what
this
is
showing
is
so
for
an
impasse.
A
at
10,
kilometers,
56,
vertical
levels,
we're
seeing
about
a
3x
decrease
in
x-
or,
I
guess,
increase
in
days
per
hour
for
the
for
the
summit
versus
cheyenne.
It
does
some
it
does
for
the
gpu
version
does
not
scale
quite
as
well.
This
is
due
to
issues
with
how
they
handle
the
the
the
message
passing
boundary
exchanges.
C
This
is
something
that's
been
done
within
the
last
year
or
so
so,
but
anyway,
so,
okay,
so
in
pass
another
project-
and
this
is
one
that
I've
been
very
involved
with-
is
the
spline
analysis
at
mesoscale,
utilizing
radar
and
aircraft
instrumentation.
So
what
this
is
is
they
would
they
would
take
an
aircraft
and
they
would
fly
it
through
like
a
thunderstorm
or
a
or
a
hurricane,
or
something
like
this,
and
it
would.
C
It
would
take
doppler
radar
and
it
would
bounce
off
the
particles
that
were
in
the
storm,
and
then
this
code
essentially
addresses
the
question:
what
did
I,
what
did
we
just
fly
through
and
then
it
reconstructs
the
field
into
an
initial
condition
or
they
could
be
used
for
a
numerical
weather
prediction?
So
you
see
the
the
the
image
here.
You
see
the
little
black
plane,
it's
as
it's
flying
around
the
eye
of
the
sort
of
the
the
eye
of
the
hurricane
here.
C
So
this
was
this.
Was
this
was
work,
so
this
was
initially
a
c
plus
plus
code
that
was
written
in
achieved
parallelism
through
openmp.
There
was
so
we
kind
of
radically
improved
the
performance
of
this
code,
and
we
also
put
it
on
a
gpu
because
it
was
well
designed
for
this.
So
here's
here's
some
execution
times
for
again
the
comparison
of
the
the
intel
broadwell.
So
that's
cheyenne
versus
the
nvidia
b100.
C
You
have
two
cases
here:
supercell
and
hurricane.
They
have
different
characteristics
as
far
as
the
physical
domain
that
you're
solving
for
versus
the
observation,
and
so
you
see
about
a
you
know
a
factor
of
three
to
over
two
to
three
speed
up
for
the
the
the
cheyenne
node
versus
nvidia
u100.
C
So
if
you
look
at
the
you
know,
if
you
look
at
the
broader
kind
of
end-to-end
performance
of
when
we
started
working
on
this
code
to
the
end
result,
we
ended
up
getting
a
factor
of
100x
speed
up.
This
was
from
the
original
from
the
original
version
of
the
code
on
cpu
to
nvidia
v100,
so
it
dropped
from
from
about
600
minutes
down
to
a
little
over
five
minutes
to
run
this.
C
So
quite
a
significant
speed
up
and
a
lot
of
this
was
well.
There
was
multi
layers
of
speed
up.
There
was
some
numerical
speed
up
that
that
allison
baker
helped
with
that
achieved
about
a
factor
of
eight
speed
up.
You
know
you
got
about
a
four
factor,
four
speed
up
from
the
the
hardware
and
then
you
then
the
remainder
speed
up
came
from
just
run-of-the-mill
code
optimizations.
C
So,
finally,
the
the
the
fourth
project
is
muram.
This
is
a
solar
model
for
simulations
of
the
earth's
atmosphere.
C
Okay-
and
so
this
has
been
jointly
developed
by
hoa,
the
max
constitute
this
was
again
using
open.
Acc
had
to
kind
of
this
was
not
just
an
addition
of
open
acc
directives,
but
rather
had
to
rewrite
some
of
the
algorithm
and
because
of
its
challenging
kind
of.
C
Algorithm
perspectives,
so
here's
the
so
a
scaling
curve
again,
the
green
is
the
the
nvidia
and
the
blue
is
the
the
intel
and
so
that
you
have
the
throughput
there.
So
you
again,
you
see
about
a
factor
two
to
three
yeah
impact
on
speed
up
so
and
then.
Finally,
one
more
thing
here
before
the
end,
we're
trying
to
create
a
community
of
practice.
C
The
the
this
meeting
and
it's
going
to
include
a
lightning
round
talks,
and
I
have
some
suggestions
for
a
little
some
lightning
around
items.
That's
going
to
be
july
1st
and
if
you're
interested,
there's
a
you
know,
register
or
send
your
slides
with
cody.
So
any
any
questions.
B
All
right
thanks
thanks
a
lot
john
for
sharing
that
great
overview
of
all
those
activities.
Yeah
I'll
wait,
wait
a
minute
to
see
if
anyone
has
any
questions,
feel
free
to
put
questions
in
the
chat
or
ask
john.
D
So
I'll
ask
a
question:
it
sounds
like
you're
focused
on
open
acc.
Are
there
other
approaches
that
you're
considering.
C
C
We
will
have
that
by
the
end
of
summer,
but
but
based
upon
the
code
bases
that
we
have
around
here.
That
are,
you
know,
created
over
a
number
of
years
and
the
directive
seems
to
be
the
most
viable
at
the
moment.
C
Well,
it
you
know,
if
you
have,
it
really
depends
upon
the
project
I
mean
some
of
the
projects
were
were
were
like
four
fte
months.
Some
of
them
were,
you
know,
closer
to
two
to
three
years,
so
the
probably
the
quickest
one
also
had
the
most
spectacular
results,
which
was
the
samurai
that
had
four
to
five
fte
months
effort.
Csm
was
rather
long.
The
the
m
pass
was
was
quite
expensive
as
well,
so.
B
All
right,
well,
thanks
again
and
thanks
thanks
to
all
the
speakers
in
this.
In
this
first
section
we
are
going
to
take
about
a
10
minute
break,
so
we're
turning
at
15
minutes
past
the
hour
so
get
up
and
stretch
do
whatever
you
need
to
do.
There
may
or
may
not
be
coffee
and
cookies
in
your
kitchen.
If
you'd
like
to
go,
get
those
and
we'll
see
you
in
about
10
minutes.
J
H
H
J
J
A
Okay,
it
is
2
15,
so
we're
gonna
resume
our
session.
This
is
lisa.
I
will
share
this
part
of
the
program
for
the
speakers.
Again,
you
have
15
minutes,
but
we
need
to
fix
the
speaker
change
in
there,
as
well
as
the
questions.
A
So
I
will
give
you
a
warning
at
10
minutes
and
ask
you
that
you
please
stop
talking
at
12
to
13
minutes.
So
we
have
time
for
the
questions
and
please
remember
to
put
your
presentation
in
present
mode
mariana.
Yours
is
already
there
so
with
that.
Let's
go
ahead
and
get
started
I'll.
We're
going
to
have
marianna,
bertenstein
and
she's
going
to
talk
to
us.
Give
us
an
update
on
the
new
esmf
new
oxy
coupling
infrastructure,
the
maps
and
the
data
models
see
depths.
J
Can
you
hear
me
alicia,
everything's,
good?
Okay,
thank
you
for
giving
me
the
opportunity
to
talk
about
this.
I'm
really
excited
about
the
progress
that
we've
made
over
the
last
year,
so
I'm
going
to
give
a
super
brief
overview
on
what
esmf
neuopsy
is.
J
Apologies
to
those
of
you
that
are
already
super
familiar
with
this,
but
there
might
be
people
on
the
meeting
that
are
not
so
I'll,
explain
it
and
then
I'll
delve
into
progress
we've
made
with
the
new
cmets
coupling
infrastructure
between
components,
as
well
as
the
new
data
models
that
created
and
are
being
extensively
used,
both
by
csm
and
the
noaa
project,
which
will
be
talked
about
a
little
bit
later,
and
that
is
c
depth
and
I'll
be
defining
all
of
these
acronyms.
J
One
of
the
additions
to
the
esmf
package
that
was
done
several
years
ago
is
called
the
new
oxy
layer,
which
is
the
national
unified
operational
prediction
capability
that
that
is
a
big
mouthful,
but
it
comes
along
with
esmf
and
what
it
does
is
that
it's
standardized
and
made
it
easier
to
create
a
coupled
model
by
introducing
four
new
generic
components
that
could
be
customized
and
those
would
be
the
new
opsi
driver,
neopsy
model
which
would
be
used
for
a
component
and
meter
which
I'll
be
talking
about
extensively
in
the
next
few
slides
and
the
connector,
which
enables
different
components
of
the
model
system
to
couple
together
and
exchange
data.
J
So,
in
terms
of
coupling
between
components,
we've
introduced
this
new
mediator,
which
I'll
define
in
a
second
called
cmets
that
stands
for
the
community
mediator
for
earth
prediction
systems.
It
is
shared
between
csn
and
the
unified
forecast
system,
as
noaa
as
part
of
the
encarnola
moa,
and
it's
gone
into
operations
as
noaa.
We
will
be
officially
releasing
it
for
csm23,
but
we
already
have
beta
tax
with
cmips
capability
and
I'll
I'll.
Give
you
a
quick
outline
in
a
little
bit
of
where
that
stands.
J
J
It
means
that
the
components
of
the
system
don't
directly
exchange
data
with
each
other,
but
rather
they
exchange
data
with
a
central
coupler
that
can
run
on
its
own
course
and
that
central
coupler
is
responsible
for
regretting
the
data
from
a
source
component
to
a
target
component
and
then
merging
data.
That's
been
regretted
from
a
collection
of
source
components
to
the
right
correct
target
component,
as
you
can
see
here.
J
Another
part
of
the
system
is
that
for
each
of
these
components
we
have
the
ability
to
swap
out
data
components
for
the
prognostic
component
as
part
of
configuring,
an
experiment.
Now
the
current
coupler
was
based
on
mct
coupler
7,
which
has
been
in
place
for
many
years
and
has
served
csm
quite
well.
J
But
what
we're
doing
now
is
exchanging
that
coupler,
seven
hub
to
what
we
call
a
new
opsi
c-maps
hub,
and
that
implies
that
now
the
components
need
to
have
another
translation
cap
at
the
top
layer
called
the
new
oxycat
that
translates
between
the
component
data
structures
and
the
esmf
neuopsy
data
structures
and,
as
a
result,
this
mediator
neuopsycmaps
can
be
exchanged
between
component
modeling
systems,
but
is
essential
to
a
lot
of
the
new
capabilities
that
we
are
now
exploring
in
csm
and
just
to
let
you
know
what
I've
circled
here:
size,
6,
mom,
6
and
wave
watch
3.
J
These
are
components
that
are
used
simultaneously
by
the
noaa,
unified
forecasters,
sorry,
the
noaa,
unified
forecast
system
and
csn
and
with
size
six
and
one
six.
They
actually
share
a
new
opsic
app
and
we're
going
to
be
exploring
over
the
summer
how
to
create
a
unified
nail
cab
for
wave
watch.
But
in
addition,
with
the
same
coupling
infrastructure,
we
can
also
run
the
ufs
atmosphere,
but
in
a
completely
different
modeling
framework,
which
is
the
ufs.
J
First
one
is
it's
going
to
be
much
easier
to
introduce
new
grids
to
the
system
for
one
thing,
esmf
provides
online
mapping
between
source
and
destination
components
and,
as
a
result,
you're
no
longer
going
to
need
most
of
mapping.
Files
that
you
have
you'll
still
need
custom
mapping
files
which
require
smoothing
like
runoff
to
ocean.
J
J
Another
one
that
has
been
introduced
very
recently
is
the
removal
of
the
need
to
create
domain
files
which
for
the
ocean
and
the
land,
and
particularly
cln,
describe
what
the
land
fraction
was.
The
way
in
csn
you
get
the
land
fraction.
Is
you
take
an
ocean
mass?
J
You
map
it
to
the
land
grid
and
that
gives
you
the
land
fraction
on
the
atmosphere
land
grid,
because
in
our
all
our
cases
we
run
the
atmosphere
and
land
on
this
on
the
same
grid
in
coupler,
seven,
each
new
component
grid
required
you
to
act,
use
a
offline
tool
to
generate
these
domain
files,
and
then
you
had
to
update
scene
with
them,
and
that
was
a
headache
because
it
implied
a
lot
of
offline
steps
and
updates
the
scene
to
do
that
with
cmets.
J
J
Another
big
simplification
is
what
we're
doing
for
landeis
development
in
terms
of
coupling
both
antarctica
and
greenland
in
one
simulation
go
khan
referred
to
this
briefly
yesterday,
with
coupler
seven,
what
we
were
going
to
do,
which
we
never
started,
was
to
create
a
unified
global
grid
for
the
system.
J
That
implied
that,
for
every
combination
of
relent
and
antarctica
or
potentially
other
new
ice
sheets,
you
would
have
had
to
do
a
new
unified
grid,
which
would
have
resulted
in
a
combinatoric
explosion
with
c-max
esmf
provides
this
really
nifty
capability,
where
you
could
create
nested
states
inside
your
state,
where
each
nested
state
corresponds
to
a
different
ice
sheet,
and
the
flexibility
of
nuances
is
that
each
of
these
nested
states
couples
one
by
one
to
one
with
a
corresponding
ice
sheet
in
the
mediator.
J
As
a
result,
this
is
very
extensible,
you
can
keep
adding
new
ice
sheets
and
there
really
is
not
any
change
you
need
to
put
into
the
mediator.
It
automatically
recognizes
that
and
does
the
regridding
and
merging-
and
we
our
hope,
is
to
have
this
in
a
beta
tag
this
summer.
J
Another
nice
feature
is
what
would
happen
with
antibiotic
ocean
land
ice
coupling.
This
requires
actually
coupling
to
multiple
levels
of
the
ocean
beneath
the
land
ice
and
that
each
multiple
level
has
a
different
bathymetry.
So
when
this
was
explored
in
mct,
the
way
it
was
done
is
that
each
level
had
required
a
different
mapping
file
because
you
had
a
different
mask
again.
You
can
imagine
if
you
were
going
to
try
to
extend
this
along
with
the
combinatoric
nightmare
of
different
ice
sheets.
It
just
becomes
unfeasible
to
think
of
how
this
could
have
been
supported.
J
This
is
set
up
the
press.
We
have
the
ability
now
that
I
think
will
have
a
very
large
performance
impact
on
csn,
which
is
the
ability
to
have
different
components
that
share
cores
run
with
different
threading
levels,
and
this
was
simply
not
available
with
the
coupler
seven
infrastructure.
So
in
coupler
seven,
if
component
a
was
threaded
four
ways
and
component
b
was
not
threaded
and
they
shared
nodes.
You
could
only
use
a
quarter
of
the
course
in
a
node
with
cmx.
J
This
restriction
has
been
removed
and
just
to
show
you
the
latest
timings
for
a
b
1850,
you
can
see
that
the
model
cost
is
significantly
reduced
and
at
the
same
time
the
throughput
is
better.
So
I
think
this
will
have,
like
I
said,
a
very
significant
impact
on
the
cost
of
running
simulations,
as
well
as
throughput
as
we
start
optimizing
and
leveraging
this
capability.
J
And
finally,
what
we
have
is
a
dynamic
ascii
file
that
is
runtime
that
determines
the
sequencing
of
the
system
with
a
very
simple
syntax
and
runs
okay.
The
run
sequence
can
be
changed
without
recompiling.
J
The
status
of
cmaps
is
that
all
new
science
is
being
done
with
cmeps
we're
targeting
it
for
csm23
and
above
for
the
default
coupling
infrastructure
and
it's
fundamental
to
several
collaborations.
J
J
J
So
if
you
look
at
what
our
current
data
models
look
like,
you
have
in
purple
the
forcing
data
where
these
are
streams
that
share
a
common
grid
and
temporal
frequency,
and
what
the
data
model
does
is
that
it
uses
these
different
streams
and
maps
them
both
in
time
and
spatially
to
get
data
fields
on
the
model
grid
that
are
then
filled
in
with
potentially
missing
data
or
other
science
requirements
to
create
the
fields
that
are
then
sent
to
cmaps,
but
a
really
big
new
addition,
which
was
also
available
in
coupler
seven,
but
is
much
more
extensible
now
because
of
the
capabilities
of
the
c
dev
share
code
is
for
prognostic
components
such
as
cam
or
ctsm
to
directly
use
this
share
code
capability
to
do
interpolation,
and
particularly
for
cam
we're
going
to
be
looking
at
using
this
for
aerosol.
J
J
As
of
csm-23
beta
o2
and
it's
again
fundamental
to
several
collaborative
efforts
that
we
have,
including
the
nsf
earthwork
efforts,
it's
being
integrated
into
the
unified
forecast
system
and
it
will
be
targeted
for
csm23
as
the
default
data
model
and
again,
both
c-maps
and
c-depths
are
being
shortly
developed
between
noaa
and
ncar
as
part
of
the
mla,
and
I
really
want
to
call
out
that
none
of
this
would
have
really
existed
without
the
tremendous
input
of
the
esmf
core
group,
which
is
located
at
and
carton
cgd.
J
They
have
been
tremendously
responsive
about
addressing
any
hiccups
and
problems
we
ran
into,
and
especially
this
new
efficiency
that
I
showed
was
very
much
put
in
place
as
a
collaboration
between
csag
and
the
esmf
core
group
working
together
and
with
that.
Hopefully,
I've
made
my
time.
So.
Thank
you
and
I'm
happy
to
take
questions.
A
Okay,
I
think
we
have
time
just
for
a
couple,
quick
questions,
one
I
think
jim
already
answered,
but
if
you
have
any
comments
for
an
f
case
which
ocean
match,
would
you
use
for
making
the
landmass
without
a
domain.
J
I
haven't
looked
at
what
jim
said.
So
the
point
is:
if
you
have
a
gx1
b7
ocean,
the
ocean
always
has
a
mask
of
letter
zero.
So
it
depends
on
what
your
complementary,
if
you're
running
a
b1850
at
f19g17,
your
ocean
mask,
is
g17
and
that's
put
into
the
land.
Nameless,
that's
a
new
feature
in
the
land
that
you
have
to
pick.
A
Okay,
so
we're
going
to
do
one
more
and
then
we're
going
to
move
on
from
robert
halberg
when
you
change
the
order
of
the
component
clause
and
run
time,
is
there
the
ability
to
change
which
fluxes
are
calculated
explicitly
or
implicitly
for
each
component.
J
So
that's
a
good
question
so
when
ufs
uses
it,
they
calculate
the
atmosphere
ocean
fluxes
in
the
atmosphere
when
csm
uses
it.
We
calculate
the
atmosphere
ocean
fluxes
in
the
mediator.
I
don't
believe
that
either
formulation
for
sure
the
formulation
in
csm
is
not
implicit,
but
we
are
looking
at
bringing
in
implicit
formulations
into
the
mediator
using
the
exchange
grid,
and
that
is
an
ongoing
effort
that
started
right
now.
So
where
you
actually
calculate
the
atmospheric
complexes
is
really
independent
of
the
sequence
that
you
would
put
them
in.
J
So
we
have
a
very
definite
place
in
the
sequence
where
it
makes
sense
to
calculate
those
and
then
use
that
to
be
sent
to
the
atmosphere
and
again
the
exact
same
being
used
by
the
ufs,
but
no
atmosphere.
Ocean
classes
are
being
calculated
so
that
particular
phase
of
the
mediator
is
never
invoked
in
the
run
sequence.
A
Okay,
so
we're
gonna
have
to
move
on.
Thank
you
mariana
hendrick.
You
can
take
the
screen
over.
If
you
don't
stop
there
and
henrik
thomann
will
talk
to
us,
will
give
us
an
update
on
the
unified
forecast
system.
H
You
can
see
my
screen.
I
assume
yes
all
right.
So
it's
a
pleasure
to
be
here
at
the
cesm
meeting.
I
think
that
in
a
few
more
years
we
might
have
to
deliberately
hold
joint
ef,
csc,
esm
and
ufs
meetings,
but
we'll
get
there
just
a
bit
when
we
get
there.
So
I'm
talking
here
for
the
ufs
community,
so
it's
just
my
name
on
there,
but
the
reality
is
that
that's
a
large
group
of
people
and
a
lot
of
those
people
are
in
both
communities,
the
cesm
and
the
ufs.
H
So
bottom
line
up
front.
Why?
Why
is
noah
going
to
the
ufs
simplification,
the
production
suite
basically
applications
from
now
cast
to
seasonal,
but
not
nine
years,
nine
months
out
by
law,
we
can
go
about
two
years
out:
accelerate
r2o
by
doing
research
and
operations
with
the
same
tools
and
broaden
the
base
having
a
bigger
group
of
people
looking
at
the
models
that
we're
using
for
research
and
operations.
H
So
this
used
to
be
just
an
idea,
but
it's
really
become
a
reality.
The
last
18
months,
because
we
have
some
code
releases
and
we
actually
have
some
of
the
ufs
now
in
operations
and
then
the
ufs
has
really
joined
at
the
hip
through
the
infrastructure,
with
the
cesm
to
particularly
the
ncar
weather
service,
oer
moa
on
infrastructure
that
mariana
already
mentioned,
and
the
fact
that
mariana
already
mentioned
that
we
have
quite
a
few
shared
components
about
the
ufs.
H
You
probably
have
seen
this
before
I'm
going
to
go
through
my
slides,
pretty
quick,
because
of
course
I
have
way
too
many.
But
the
idea
is
that
we
have
a
community
code
that
is
used
both
for
research
and
operations,
that
our
governance
is
evidence-based
decision
making
based
the
scope
is
on
application.
So
we
have
actionable
outcomes
and
not
just
papers
to
write.
H
The
idea
is
to
have
a
unified
system,
another
unitary
system,
where
we
balance
focus
on
a
smaller
number
of
ways
of
doing
business,
while
still
at
the
same
time,
assuring
that
we
have
the
diversity
we
need
for
research
and
then
it's
really
a
paradigm
shift
in
a
sense
that
we
not
especially
for
our
weather
models,
have
been
inward.
Looking
more
than
outward
looking
for
quite
a
while,
although
that's
not
been
the
case
for
all
our
other
component
models.
H
H
That's
kind
of
clear
that
from
the
fact
that
we
have
set
up
a
unified
modeling
committee
about
five
years
ago
to
to
make
sure
that
we
looked
at
how
we
could
simplify
the
work
we're
doing
and
how
we
could
go
to
community
modeling.
The
moa
was
already
mentioned:
the
fact
that
all
our
codes
are
now
available
on
github
and
things
like
that.
H
The
fact
that
we
are
doing
research
and
operations
with
the
same
code
and
another
big
thing
is
the
fact
that
noaa
has
sort
of
formalized
their
their
commitment
to
the
ufs
by
setting
up
a
large
ufs
r2l
project
that
spends
multiple
years
and
multiple
applications,
with
a
focus
on
getting
ufs
into
operations
and,
more
recently,
a
few
months
ago,
we
have
set
up
a
noaa
modeling
board
which
coordinates
within
noaa
all
the
modeling
efforts
and,
along
that
same
time,
the
same
week,
the
epic
contract,
the
earth
prediction,
innovation
center
contract
was
awarded,
which
is
going
to
put
a
lot
more
resources
in
specifically
the
infrastructure
building
for
the
ufs
and,
of
course,
that
can
be
directly
leveraged
by
the
cesm.
H
H
I
won't
go
through
all
the
details
here,
but
this
is.
These
are
some
of
the
details
of
the
previous
slide
in
blue?
Are
there
are
the
different
releases
that
we've
had
so
two
medium
range
weather
and
one
short
range
weather
application
and
in
red
are
the
actual
implementations
and
operations
that
are
associated
with
that?
H
So
this
really
changes
the
timeline
of
collaboration
massively
and
what
we're
looking
at
now
is
having
a
other
medium
range,
better
application,
possibly
late
this
year
or
possibly
looking
at
a
hurricane
application
late
this
year.
But
this
is
the
same
thing.
This
would
be
the
if
it
is
the
global
model,
it
will
be
the
coupled
seasonal
sub,
seasonal
prototype
and
again
we
would
be
basically
sharing
that
with
the
community
order
of
three
to
four
to
five
years.
H
Perhaps
before
we
go
into
operations-
and
I
don't
want
even
with
the
short
time
I
have-
I
don't
want
to
miss
the
opportunity
to
say
that
there's
a
lot
more,
it's
the
the
mad
ccp
cmaps
jedi.
All
these
things
and
tools
are
all
part
of
the
bigger
picture
of
the
fact
that
this
becomes
a
reality,
so
the
r2o
acceleration
we
had
some
proof
pre
ufs.
H
That
pointed
us
in
the
direction
of
doing
this
community
modeling
effort,
the
wave
model
and
the
hurricane
model
are
the
examples
of
that
where
we
show
that
if
we
do
full
community
modeling,
we
can
accelerate
the
r2o
process
by
a
factor
three
to
five
for
the
wave
model.
It
was
going
from
five
to
six
to
seven
years
for
a
new
model
to
go
into
operations
to
be
able
to
do
the
equivalent
of
a
new
model
in
under
18
months
for
age
work.
H
It's
a
little
early
to
access
what
the
impact
is
on
the
r2o
acceleration,
but
we
had
a
very
interesting
situation
in
march
that
for
the
first
time
in
many
many
years,
our
global
model
actually
was
beating
the
european
center
model
on
the
standard,
monomial
correlation
measures
for
a
full
week,
and
I
hadn't
seen
it
happen
in
at
least
five
years.
So
that's
that
that's
boating
well,
but
it's
no
hard
proof
yet
so
ufs
and
cesm
in
a
few
things.
H
Maria
already
talked
about
some
things
of
that
and
we
talked
already
about
the
moa
on
the
infrastructure.
Just
a
few
examples
here-
and
this
is
this
actually,
this
session
is
a
good
example
of
why
we
collaborate
very
well
because
normally
I
would
be
talking
for
about
an
hour
about
this.
H
But
now
mariana
ufo
condom
are
all
talking
about
elements
of
things
that
I
don't
have
to
talk
about,
and
that
shows
you
essentially
how
well
we
already
collaborate
on
a
lot
of
things
and,
of
course,
it's
really
neat
to
see
that
we
actually
not
only
share
infrastructure,
but
that
we
have
couple
component
codes
that
are
all
shared
between
the
the
two
systems
too.
H
So
there
are
differences
between
cms,
cesm
and
ufs,
which
helps
us,
create
both
diversity
and
identifying
cases
where
we
can
leverage.
So
applications
are
different.
We
are
looking
mostly
at
now
cast
to
seasonal,
whereas
the
csm
is
traditionally
looking
at
the
cable
and
centennial.
There
are
different
component
models,
although
there's
a
lot
of
overlap
right
now.
H
There
are
also
different
metrics
that
we
use
in
a
different
forecaster
or
outlook
ranges,
and
we
also
see-
and
this
is
probably
the
one
place
in
the
in
the
moa
that
we
haven't
quite
completely
got
together-
is
on
the
workflow.
So
siem
is
using
the
cesm
in
some
of
the
ufs
applications,
but
we've
also
recognized
that
we
need
multiple,
multiple
workflow
solutions
for
multiple
applications
in
the
ufs
I'll
get
back
to
that
in
the
next
few
slides.
So
the
basic
principles
for
the
ufs.
H
Again,
it's
unified,
not
unitary,
and
so
we
have
to
have
a
balance
between
focus
on
on
having
tools
at
work,
but
also
diversity
when
needed,
and
that
basically
means
that
we're
looking
at
modular
tools,
rather
than
a
one
size
fits
all
and,
of
course,
with
the
ufs
and
with
any
kind
of
place
where
you
want
to
go
forward
rapidly.
You
start
from
functional
requirements,
not
from
solutions,
and
so
we
were
looking
at
software
engineering
perspective
and
at
the
system
engineering
perspective
and
to
to
really
summarize
very
quickly,
a
very
long
discussion.
H
We
came
to
the
conclusion
that
one
size
is
not
fit
all.
We
have
places
where
it's
really
important
to
limit
the
latency
between
model
runs
and
data
simulation,
in
which
case
we
really
need
to
run
the
models
out
of
the
data
simulation
environment.
But
we
also
have
places
where
the
resource
requirements
are
so
different
between
data
simulation
and
initialization
and
the
actual
model
runner.
H
That
makes
much
more
sense
to
run
them
separately,
and
this
comes
up
with
a
matrix
of
elements
and
a
modular
library
approach
that
we
are
sort
of
contemplating
right
now
for
workflow
and
what
I'm
showing
then
the
next
slide
is
highly
tentative.
It's
not
a
final
solution,
but
just
give
you
an
idea
of
what
we're
thinking.
H
So,
if
you
take
along
the
top
the
functional
aspects
of
a
run
in
operations
with
going
from
input
to
initialization
to
model
to
product
generation
and
then
the
functional
separation
from
having
the
actual
program
to
wrapping
that
in
script,
setting
configurations
up
and
running
schedules
creates
a
matrix
of
all
kinds
of
things
that
need
to
be
done.
H
Yep,
I'm
almost
done.
If
you
have
one
step
further,
then
you
can
look
at
what
you
do
with
these
things.
But
the
red
part
here
is
really
about
all
about
things
that
we
could
share
and
then
on
the
blue
part
on
the
bottom.
We
would
build
separate
solutions
for
separate
applications.
H
Last
but
not
least,
we
are
talking
within
noaa
between
ufs
and
gfdl,
not
being
unified,
with
the
climate
models
and
the
shorter
part,
so
we're
working
on
that
it's
an
ongoing
discussion
and
there's
particularly
issues
with
differences
in
infrastructure
and
with
ufs
and
cesm
we're
really
looking
at
our
coupled
prototype
for
seasonal
and
subseasonal
applications
as
being
a
potential
bridge
between
the
communities.
Therefore,
I
will
talk
a
little
bit
about
this
prototype.
H
H
The
first
four
prototypes
we
were
running
were
really
based
on
different
types
of
initialization
that
we
could
do
and
then,
since
then,
we
have
two
more
prototypes
that
have
been
completed
and
functioning
all
focusing
on
getting
into
a
newer
ice
model
using
the
fractional
grids
that
mariana
was
talking
about
and
unifying
the
vertical
structure
of
our
atmospheric
models.
We
also
now
went
to
a
full
nems
mediator
and
we
started
to
merge
all
our
global
codes,
so
there's
a
different
github
link
for
that
part
and
without
going
too
much
into
detail.
H
This
actually
does
work
pretty
well
for
us
already,
particularly
looking
at
how
the
ice
came
out
of
our
coupled
model
without
any
tuning
or
anything
like
that.
Black
lines
is
what
observations
are
the
gray
whiskers
are
how
badly
our
cfs
v2
drifts
away
from
that
in
45
days,
and
then
the
red
and
blue
lines
are
different.
Initializations
that
show
that
the
coupled
model,
without
any
tuning
with
the
newer
components
to
it,
actually
does
a
heck
of
a
lot
better
job
already
than
the
cfs
v2
same
thing
for
another
one
of
the
prototypes.
A
All
right,
thank
you,
henrik.
I
don't
see
any
question
in
the
chat,
yet
we
probably
have
time
for
one
quick
question.
A
So
while
I
don't
see
any
questions,
I
I'll
ask
one
so
that
first
public
release
of
the
ufs
media
marine
trader
application
was
done
using
the
same
workforce
or
at
least
part
of
it.
The
same
case
control
system.
A
H
That
is
still
open
for
discussion,
so
I
can
give
you
an
idea
where
we're
going,
but
those
are
not
to
be
interpreted
as
final
answers,
so
we
are
definitely
looking
if
you
looked
at
the
matrix
plot
over
the
top
of
it
configura
central
configuration
management
is
something
that
is
a
a
key
part
of
workflow,
and
so
that
is
something
that
we're
definitely
looking
at
at
using
seamforcetale
on,
in
terms
of
in
terms
of
being
able
to
run
something
effectively
in
operations
and
research.
H
We
are
working
with
with
ankar
and
with
other
parts
of
noaa
actively
on
trying
to
figure
out
how
that
is
working
best
in
practice,
and
so
we
see
the
benefit.
We
see
that
we
see
a
very
clear
benefit
of
seeing
as
a
whole
in
terms
of
managing
experiments,
but
we
also
see
that
there
are
things
in
there
that
are
unnecessary
overheads
and
not
necessarily
always
the
most
effective
way
of
doing
business
and
operations
and
considering
how
our
collaborations
have
been
so
far.
H
I
am
pretty
sure
that
at
the
end
of
this
this
discussion,
everybody
will
benefit
from
it
and
we'll
we're
definitely
looking
at
from
the
noaa
perspective,
like
with,
with
other
things
that
we've
been
able
to
pick
up
from
from
ncar.
We
see
a
lot
of
benefit
in
that
and
the
nice
thing
of
this
whole
moa
has
been.
That
has
been
the
other
way
around
too,
because
the
whole
cmap
setup
is
really
based
for
a
big
part
out
of
the
original
nems
development.
We
did
before
that.
H
So
this
has
been
a
lot
of
give
and
take,
and
it
is
really
really
fun
to
to
go
these
days
to
meetings
and
have
basically
people
like
mariana,
and
I
be
tech
teaming
and
we
could.
We
were
making
the
joke
before
we
started
the
session
we
could
do.
We
can
basically
do
each
other's
presentations
by
now
and
that
I
think
both
pretty
well
for
for
collaboration,
and
this
is
all
about
functionality.
Now
the
discussion
is
no
longer
about
solutions,
and
so
that
gives
me
the
that
gives
me
the
the
trust
that
we
will.
A
Okay,
we
due
to
the
time
we're
gonna,
have
to
move
on.
So
thank
you
hendrick.
There
is
another
question
on
the
chat,
so
perhaps
you
can
answer
there
directly.
So
ufo
you
can.
Please
start
sharing
your
presentation
and
ufo
will
talk
to
us
about
the
development
and
use
of
cdx
in
the
uss.
K
Okay,
I
I
will,
I
will
talk
a
little
bit
more
about
cdx
and
its
integration
with
the
unified
forecast
system,
the
ufs.
So
at
the
beginning
of
my
talk,
I
just
want
to
mention
about
the
all
the
people
that
contributes
this
work.
So
it's
a
really
effort
of
a
large
group
at
this
point,
so
the
the
main
motivation
behind
of
integrating
cdeps
to
ufs
model
is
the
is
to
support
the
hierarchical
model
development.
K
It
also
reduce
the
overhead
computational
overhead
in
the
development
phase,
because
if
you
are
using
a
fully
coupled
system
in
a
high
resolution,
you
have
to
wait
in
a
queue
and
then
you
have
to
the
development
goes
a
little
bit
hard
with
that
kind
of
way.
So,
if
you
want
to
focus
particular
file,
particular
part
of
the
modeling
system
and
then
trying
to
develop
something
over
there,
you
can
you
can
get
benefit
of
the
data
components.
K
Also,
the
time
span
in
the
debugging
and
testing
is
reduced
at
this
point,
so
you
can
just
isolate
this
individual
components
and
then
try
to
focus
that
fund
to
solve
existing
problem
or
issues
in
there
and
also
the
using
of
data
components.
Allow
you
to
fill
the
grid
points
outside
of
the
unmapped
outside
of
the
active
coupling
region.
K
So
the
data
components
could
really
help
to
solve
those
kinds
of
situations,
and
also
you
can
use
the
data
components
for
the
data
assimilation.
So
the
the
data
atmosphere,
for
example,
forcing
can
be
used
for
the
the
am
not
in
the
a
application
that
couples
the
ocean
and
eyes
composed
together.
K
The
main
the
basic
the
domain
building
block
of
c
c
devs
is
the
data
stream.
So
the
data
stream
is
something
like
a
optimal
interpolation
c
surface
temperature,
the
the
error
five
data
set,
or
something
like
that.
So
you
can
use
different
data
set
to
define
the
data
stream
and
then
these
data
streams
could
have
same
spatial
and
temporal
columns,
and
also
the
data
models
could
have
multiple
input
streams.
So
you
can
combine
multiple
input
streams
together
to
free
the
active
component
in
here.
K
It
has
lots
of
benefits
in
c
dev,
so
you
can
have
automated
regrading
capability
provided
by
smf
nfc,
so
it
it
can
support
different
interpolation
types,
bilinear,
conservative
and
also
it
supports
temporal
interpolation.
So
you
have
different
options
for
temporal
interpolation.
This
is
important
because
the
model
coupling
time
step
could
be
high
could
be
higher
than
the
the
the
time
step
between
the
data
data
time
slices.
So
because
of
that,
you
might
need
to
have
temporal
interpolation
in
there
and
just
my
animation
before
it
provides
also
inline
data
model
functional
functions.
So
you
don't.
K
You
can
easily
call
the
a
data
component
inside
of
the
active
or
prognostic
model
component,
so
the
ufs
system
currently
adopting
the
cdeps,
along
with
the
cmf's
mediator,
so
sharing
syllabus
between
the
organizations
such
as
ncr
and
noaa,
has
to
bring
new
features
and
new
data
streams
and
community
contributions
to
c
devs
and
that
that
will
lead
to
and
lead
to
the
benefit
of
ncaa
csr
model.
Also
because,
at
the
end
of
the
day,
all
those
pieces
will
be
shared
and
then
all
of
all
those
different
modeling
systems
could
use
the
same
code
base.
K
K
The
currently
house
has
two
different
mods
one
for
data
atmosphere
and
another
for
data
ocean.
So
you
can
fit
the
fe3
with
data
ocean
through
the
cedars
in
stress
site.
There
is
a.
There
is
all.
There
is
only
one
implementation.
They
are
only
using
the
seeded
state
atmosphere,
but
cdx
also
provides
other
data
components,
for
example,
wave
ice,
runoff,
glacier
everything.
So
it's
it's
a
matter
of
time
to
implant.
Other
data
components
use
other
data
components
through
the
configuration
of
those
applications.
K
K
Another
option
is
noaa
optimum
high
pollution
sea
surface
temperature.
We
are
also
looking
for
the
possibilities
of
global
high
resolution
sea,
surface
temperature
and
r2fs
data
sets
to
use
as
a
data
ocean
component
in
svs.
They
have
two
different
data
streams,
one
for
cfsr,
another
one
for
gifs.
So
it's
getting
more
and
more
so
you
can
you
can,
for
example,
you
can
use
nf5
in
the
svs
application
or
you
can
use
alternate
interpolation
see
surface
temperature
in
the
c
space
application,
because
all
of
them
is
using
the
same
code
base
at
this
point.
K
What's
the
main
difference
between
the
okay
before
saying
the
difference
between
them,
the
ufs
model
had
already
a
custom
written
custom
developed
data
atmosphere
before
so.
The
c
devs
is
basically
replacing
that
one.
So
the
main
difference
between
these
two
different
data
components,
c
devs,
will
give
you
more
data
components.
For
example,
the
data
ocean
data
is
data
where,
rather
than
see,
the
names
has
only
data
postfire
and
cds
also
use
the
sms
mesh
rather
than
the
smf,
rather
than
using
the
smf
grid.
K
Smf
mesh
will
give
you
more
capability
to
represent
different
application,
regional
global,
different
grids.
So
it's
much
more
flexible
at
this
point
and
the
the
next
data
atmosphere
only
supports
the
linear
interpolation
in
the
in
the
time
axis,
but
c
that
supports
different
kinds
of
interpolation
in
time,
so
nearest
linear
or
because
or
then,
if
you
want
to
do
some
kinds
of
radiation
interpolation
in
time
you
might
want
to
represent.
K
Of
it,
so
there
are
some
kinds
of
options
for
it,
and
also
cds
also
provides
some
capability
for
extrapolation.
So
if
you
don't
have
data,
but
if
you
want
to
run
the
model,
you
have
some
kinds
of
options
you
can
cycle
the
data
or
you
can.
You
can
use
the
last
data
or
first
data
for
it.
So
there
are
lots
of
different
capabilities
over
there,
including
the
inline
data
components
capability.
K
The
the
validation
of
cdx
under
ufs
weather
model
is
done
initially
done
in
the
house
application
and
also
sas
application
in
a
space
application.
They
just
want
to
compare
the
united
states
atmosphere
with
the
cedar
state
atmosphere
to
see
the
difference
between
them
and
under
house.
K
We
are
just
looking
for
the
creating
a
better
forecast
for
the
hurricanes,
so
there
is
also
another
validation
done
by
evan
and
someone
from
nora
and
but
the
initial
results
in
the
indicates
that
the
cdx
is
able
to
reproduce
the
results
of
original
nam's
provided
data
atmosphere.
So
I
will
show
some
examples
about
that
in
my
next
slide.
So
if
you
look
at
this
plots,
the
first
one
is
belongs
to
custom
data
postwar.
The
second
one
in
here
belongs
to
cdx
data
post
and
the
last
row
is
the
difference
between
them.
K
So,
as
you
can
see,
they
are
creating
a
very
similar
results
at
this
point,
so
the
the
difference
between
them
is
very
small.
So
for
10.
K
K
And
then
this
leads
to
a
more
robust
software
and
cdx
could
be
also
using
a
be
a
part
of
the
data
simulation
workflow.
If
you
want
to
look
at
the
the
it's
included
in
the
csm,
the
last
beta
snapshot,
it's
also
included
in
the
ufs.
So
you
can.
You
can
use
ufs
or
csm
to
reach
the
cdx
to
look
at
the
is
this
is
its
structure.
So
that's.
A
D
A
Okay,
thank
you.
We
have
time
for
a
question
of
two.
I
don't
see
any
in
the
chat
yet
so
I'll
ask
the
question.
You
mentioned
this
possibility
of
cdaps
being
used
as
part
of
the
da
workflow.
How
do
you?
How
would
that
work?
What's
that.
K
Yeah,
currently
under
sds
application,
the
marinda
group
is
trying
to
use
cdx
in
the
in
the
lda
workflow.
So
I
don't
know
too
much
detail
about
that
word,
but
there
are
some
possibilities,
so
we
in
in
recently
we
had
couple
of
tall
chats
with
the
a
group
and
then
we
we
did
some
presentation
to
them
to
possible
usage
directions
in
terms
of
the
da
application.
A
Okay,
well,
there's
no
more
questions
here
on
the
chat,
so
we're
going
to
move
on
and
thank
you
ufo
other
questions.
If
they
come
up,
please
just
type
them
in
the
chat
and
our
next
speaker,
I
will
be
don
heinzeller
and
he
will
talk
to
us
about
the
common
community
physics
package,
ccpp,
sharing
physics
across
noaa
and
n-car
models
using
a
common
software
framework.
L
I
would
like
to
give
you
an
update
on
the
common
community
physics
package
tcp
on
our
efforts
for
sharing
physics
across
now
and
income
models
using
a
common
software
framework,
so
provide
the
clock
a
bit
to
2017
when
we
started
working
on
the
ccpp
initially
initially,
it
was
planned
or
developed
as
a
ufs
infrastructure
for
as
the
ufs
infrastructure
for
atmospheric
physics,
and
the
original
verbiage
is
to
facilitate
the
improvement
of
physical
parameterizations
and
their
transition
from
research
to
operations
by
enabling
the
community
to
participate
in
the
development
and
testing.
L
L
While
it
was
initially
planned
for
physics,
it
only
turns
out
that
aerosols
have
been
added
recently,
so
we're
adding
a
chemistry
component,
and
the
idea
behind
this,
and
I'm
going
to
come
back
to
this
later,
is
that
these
aerosols
can
be
either
called
as
the
neopsi
component
or
they
can
be
called
inline.
As
a
ccpp
physics
option.
L
L
L
So
at
compile
time,
the
ccpp
framework
looks
at
metadata
tables
for
each
of
the
ccp
physics
schemes
that
describe
the
variables
that
are
required
to
run
the
physics.
It
also
looks
on
the
host
model
side
for
metadata
tables
that
describe
the
variables
that
are
provided
and
by
one
of
their
attributes,
the
ccp
standard
name.
L
L
So
I
wanted
to
note
that,
while
the
cons
that
construct
of
having
sweets
is
an
important
one,
because
that's
more
for
the
operational
side
in
terms
of
a
better
combination
of
schemes,
that's
that's
known
to
run
well
and
work
well
together.
L
We
also
support
this
idea
of
an
easy
interchange
of
schemes
within
these
sweet
definition
files,
so
that
the
research
side
can
do
its
testing
and
have
this
flexibility
that
it
needs
in
any
way.
This
is
a
full
speed
definition
file.
It's
called
fv3
gfs
version,
16
beta,
it's
actually
the
same
one
as
the
fe3
gfs
version
16
operational
suite,
but
this
was
the
original
one
that
I
put
in
here,
and
it's
probably
much
longer
than
many
of
you
have
expected
it
to
be.
L
You
would
have
expected
things
like
radiation
and
then
pbl,
convection
and
microphysics,
and
the
reason
for
this
is
that
in
the
ccpp
world
there
is
no
physics
driver
anymore,
so
these
gigantic
files
that
can
be
up
to
forty
thousand
lines,
long
like,
for
example,
in
wharf
all
this
glue
code
that
connects
the
different
the
different
schemes.
This
glue
code
has
to
become
a
scheme
itself
and
we
call
these
schemes
interstitial
schemes
because
they
sit
in
between
the
the
actual
primary
schemes
that
do
the
the
work
that
you
know
like
pbl
or
convection.
L
We'll
come
back
to
this
all
right.
A
couple
of
features
to
point
out:
ccp
supports
groups.
That
means
you
can
call
a
group
individually
or
you
can
call
all
groups
as
they
are
listed
in
in
the
suite
definition
file.
In
that
order
we
have
a
capability
to
sub-cycle
schemes
that
can
be
used
for
iterations
or
for
calling
them
at
a
higher
frequency
over
the
shorter
time
step
that
has
recently
been
introduced
for
thomson
microphysics
and
tested
now,
and
the
order
of
the
schemes
is
up
to
the
user.
L
Of
course,
care
must
be
taken
if
you
swap
the
order
schemes,
because
some
of
this
glue
code
in
these
interstitial
schemes,
for
example,
rtmg
short
y3
or
dmg
short
with
post,
and
so
some
of
this
depends
on
the
order,
while
it's
safe
in
this
case
radiation
wave
long
wave,
we
have
tested
it.
There
may
be
other
combinations
where
it's
not
that
easy.
So
one
needs
to
know
what
yeah
users
need
to
know
what
they
are
doing
when
they,
when
they
swap
schemes
all
right.
L
L
The
most
important
ones
are
listed
here,
an
augmented
metadata
standard
which
has
already
been
adopted
in
the
ufs,
the
ability
to
automatically
allocate
variables
that
are
used
by
the
physics
only
and
that
the
host
model
doesn't
have
to
know
about
the
ability
to
compare
metadata
to
actual
fortran
code
and
improve
build
system
and
code
generator
and
advancements
for
chemistry,
constituents
for
example,
and
further
so
that
path
to
converting
towards
the
common
ccpp
framework
is
sort
of
we're
coming
from
two
sides
and
trying
to
trying
to
to
get
together
by
the
end
of
2022.
L
We
integrated
that
ccpp
version
in
the
dtc
single
column
model
in
nrl,
neptune,
small
neptune
and
in
the
noaa
ufs,
and
then
we
went
and
looked
at
the
requirements
for
a
joint
ccpb
framework
between
ncar
and
noaa,
and
so
we
made
several
improvements
to
that.
First
generation
code
generator
in
these
that
they
highlighted
in
these
red
boxes
here.
L
In
order
to
get
to
a
common
code
base
or
a
point
of
reconciliation,
so
these
are
the
updated
metadata
format
that
I
meant
that
I
mentioned
beforehand:
automatic
unit
conversions,
support
for
block
data
structures,
additional
ccp
phases
that
were
required
for
the
csm,
for
example,
and
then
a
new
metadata
standard
and
rules
on
how
to
create
standard
names.
L
At
the
same
time,
the
end
car
side,
most
notably
steve,
was
working
on
the
second
generation
code,
generator
captain.py,
the
early
prototype
was
tested
in
the
encarmica
model,
and
then
progress
was
a
little
slower,
but
by
the
end
of,
but
within
this
year,
2021.
We
hope
to
have
this
version
implemented
in
the
encar
empath
model
than
in
the
ufs
in
scm,
in
cesm
and
then
also
in
neptune.
L
All
right
I
mentioned
on
the
last
slide
that
we
are
working
on
a
metadata
standard
and
rules.
So
there
is
a
github
repository,
ccpb
standard
names
under
the
escomp
organization,
and
this
repository
is
meant
to
contain
community
accepted
ccp
standard
names,
publishing
tools,
search
tools
and
soon
also
rules
for
how
to
create
new
standard
names.
So
there's
an
active
discussion
on
the
contents
of
this
repository
and
also
on
the
way
to
utilize
it.
L
Currently,
there
are
two
open
pr's
with
updated
standard
names,
it's
about
two-thirds
of
the
standard
names
that
are
used
in
the
ufs
and
their
rules
and
the
pr
for
rules
for
creating
new
names.
So,
if
you're
interested
in
this
process,
I
encourage
you
to
go
to
that
website
and
take
a
look
at
that
at
the
issues.
The
pull
requests
in
the
discussion
therein.
L
Another
activity
that
is
not
coding
in
itself
is
that
code
management
for
shared
physics
and
chemistry,
so
we
are
trying
to
develop
a
process
for
joint
code
management
and
testing
of
physics
and
chemistry.
This
involves
multiple
organizations
and
multiple
modeling
systems,
and
this
does
far
from
being
easy.
L
Yep,
so
ccpp
provides
opportunities
for
future
development,
especially
after
transitioning
to
the
new
code.
Generator
caption.py,
and
I
just
want
to
mention
a
few
highlights
here.
One
is
automatic
area
transformations
from
ikj
to
ik
or
ki,
and
so
on,
or
the
ability
to
calculate
derived
variables,
for
example,
potential
temperature
from
temperature
and
geopotential
or
tools
that
help
developers
such
as
a
visualization
tool,
which
is
like
a
flow
graph
of
a
certain
variable
through
a
ccpp
suite,
where
it's
completely
overwritten,
where
it's
just
read
in
where
it's
modified
and
so
on.
L
L
Two
more,
these
ones
are
not
funded,
or
at
least
not
entirely
funded
the
ability
to
create
ccpp
or
newer
pc
caps
for
physics,
so
that
a
developer
can
decide
at
build
time
whether
he
wants
to
run
a
component
as
an
inline
component
in
ccp
or
as
an
external
component
from
an
opc
and
primary
candidate,
of
course,
is
the
land
surface
model
and
then
the
ability
to
generate
optimized
caps
to
dispatch
physics
on
cpus
or
gpus,
which
is
certainly
required
for
next
generation
hpcs.
L
I
would
like
to
end
with
a
short
advertisement.
There
is
a
special
issue
in
air
quality
forecasting
in
nwp,
with
editors,
myself
and
jordan.
Powers
and
the
deadline
for
submissions
has
been
extended.
So
if
you
would
like
to
submit
a
paper,
please
do
so
and
with
that,
I'm
going
to
finish
and
I'm
happy
to
take
questions.
A
Thank
you
dom.
I
don't
see
any
questions
yet
so
we
do
have
time
for
one
or
two
questions.
So
while
people
type
I'll
ask
you,
since
you
have
this
this
special
issue
here
about
chemistry,
can
you
tell
us
a
little
bit
how
ccpp
is
being
used
for
chemistry.
L
All
right,
yes,
so
the
idea
here
is
that
the
nasa
nasa
has
created
a
chemistry,
repository
gocard
repository
with
a
process
library
that
contains
all
the
core
processes
in
a
clean
library
and
that
this
component
or
this
library
can
be
used
either
through
neuropc
in
the
ufs
or
any
other
modeling
system
or
through
the
ccpp.
L
And
there
is
there's
a
lot
of
discussion
going
on.
To
which
extent
this
should
be
done
all
all
of
it
in
neopc
or
all
of
it,
in
ccp
or
key
components
like
the
the
aerosols
that
really
belong
close
to
convection,
or
so
whether
this
should
be
done
in
the
ccpp
and
the
rest
should
be
done
in
obscene.
A
D
Regarding
your
comment
on
computing
derived
variables,
such
as
potential
temperature,
and
I
was,
I
was
wondering
if
the
ccpp
would
be
able
to
support
a
functionality
where
primarization
would
be
able
to
query
from
some
common
place,
how
to
compute
certain
variables,
such
as
you
know,
enthalpy
or
energy,
where
different
parallelizations
may
compute
that
in
different
ways,
which
leads
to
you
know,
thermodynamic
or
energetic
inconsistencies
between.
L
Them,
yes-
and
we
have
discussed
this
not
not
necessarily
within
the
context
of
entropy
or
so,
but,
for
example,
when
it
comes
to
try
diagonal
solvers
or
when
it
comes
to
random
number
generators
and
stuff,
like
that,
so
the
yeah.
That
idea
is
on
the
table
that
we
would
have
some
sort
of
library,
standardized
library
that
gives
people
access
to
common
ways
to
compute
things,
to
transform
things
and
then
hopefully
we
can
make
these.
We
can
document
them
well
and
we
can
make
them
as
efficient
as
possible.
L
L
A
All
right
well,
thank
you
tom,
so
I
think
we're
gonna
bring
this
part
of
the
program
to
a
closing.
Thank
you
to
all
the
speakers
so
far
and
I'm
gonna
pass
the
award
back
to
bill
sacks
who
will
tell
us
what
will
happen
after
the
break.
B
Yeah
thanks
thanks
again
to
all
the
speakers
yeah,
so
we're
going
to
take
a
break
until
about
3
30
and
then
return
for
an
extended
for
a
presentation
and
extended
discussion
on
cesm
diagnostics.
So
we
hope
you
can
join
us
for
that,
and
then
I
wanted
I
forgot
to
point
out
at
the
beginning.
B
We
are
gonna.
This
session
is
gonna,
go
until
about
five
o'clock
officially,
for
this
extended
discussion
time,
and
then
we
do
welcome
you
to
stay
on
after
that.
We'll
we'll
keep
this
zoom
session
open
until
5
30
in
case
people
just
want
to
stick
around
to
informally
catch
up
and
chat
and
network
afterwards.
D
H
D
M
D
M
Yeah,
you
might
hear
some
boats
cruising
by
on
the
background.
D
D
D
B
All
right:
well,
it's
3
30.!
So
I
guess
we
can
get
restarted
here
and
max.
Grover
is
going
to
lead
us
off
with
a
overview
presentation
of
the
current
state
of
cesm
diagnostics,
and
so
then
he
and
some
others
organize
a
discussion
around
that
topic.
So
yeah
take
it
away
max.
Looking
forward
to
this.
M
Yeah,
so
the
idea
of
this
presentation
is
kind
of
to
get
some
ideas
going
and
kind
of
spark
some
discussion.
M
So
this
will
be
roughly
20
minutes
long
and
then
we'll
break
out
into
small
groups
have
some
discussion
there
and
then
we'll
come
back
together
at
the
end,
so
I'll
go
ahead
and
get
started,
then
so
again,
we'll
sort
of
be
talking
about
the
current
state
of
csm,
diagnostic
csm
diagnostics
and
some
potential
plans
forward
with
these.
So
what
do
I
mean
by
diagnostics
here?
M
So
the
kind
of
definition
here
is
evaluation
or
evaluations
of
the
results
of
a
model
simulation
which
could
be
comparison
with
previous
observations,
time,
series
of
some
diagnostic
to
ensure
that
values
are
realistic
and
then
it
could
be
a
model
comparison,
and
why
do
we
care
about
these
diagnostics,
so
they're
crucial
to
understanding
how
these
models
are
performing
or
they
could
possibly
provide
key
scientific
insight
and
could
potentially
lead
to
it's
new
knowledge.
M
So
a
couple
of
questions-
we're
kind
of
after
too,
is
like
how
have
diagnostics
typically
been
developed
and
then
what
current
packages
or
workflows
exist,
and
so
some
of
the
traditionally
used
packages
within
csm
are
the
following,
so
sort
of
each
component
or
each
working
group
has
their
own
diagnostics
package.
So,
for
example,
amwg
diagnostics,
package
I'll
go
ahead
and
click.
M
So
these
are
a
lot
of
the
traditionally
used
packages
and
sort
of
what's
within
the
current
csm
workflow
and
so
another
one
that
I
mentioned
here
at
the
end
is
the
cbdple.
M
So
this
is
the
climate
variability
diagnostics
package,
that's
made
to
work
with
large
ensembles,
and
this
is
an
automated
analysis
tool
similar
to
the
other
ones,
data
repository
for
exploring
these
sort
of
the
variability
time
variability
climate
change,
so
it
computes
modes
of
variability
and
trends
in
these
different
climate
indices.
The
user
specifies
data,
sets
computes
these
ensemble
means
and
spread
and
provides
this
quantitative
comparison
to
observations
they
can
breed
in
monthly,
cmap
or
csm
time
series.
It
saves
them
out
in
that
cdf
files
and
it's
written
in
ncl.
M
Currently
the
calculations
are
being
written
into
python
and
then
the
the
ncl
story
is
kind
of
the
overall
story.
With
our
current
diagnostics,
the
csm
pulse
processing
is
ncl
based,
which
can
sometimes
be
difficult
to
port
to
non-end
car
machines,
it's
serial
in
nature,
and
it
can
be
tough
to
scale
to
finer
resolutions
and
basically,
the
the
furthest
extent
to
to
scalability
is
being
able
to
sort
of
process
each
variable
separately.
M
But
if
you're
looking
at
single
variable,
you
wouldn't
be
able
to
to
kind
of
include
or
enhance
the
performance
there
and
then
also
ncl
is
in
in
maintenance
mode,
and
so
the
sizzles
geocat
team
is
working
on
transitioning
ncl
functions
over
to
python
and
then
again,
that's
through
the
geocat
efforts
which
I'll
talk
about
here
in
a
little
bit.
M
So
the
kind
of
the
problem
is
that
a
lot
of
this,
a
lot
of
this
code
bases
is
written
in
ncl.
We
like
to
move
away
from
ncl,
but
obviously
that's
that's
a
lot
of
diagnosis
packages
and
again
so
most
of
the
community
is
also
transitioning
to
python,
leading
to
several
different
efforts.
So
again,
the
geocat
team
is
developing
this
python
toolbox
for
geosciences,
so
mention
a
talk
yesterday.
M
The
adf
or
the
amwg
diagnosis
framework
is
a
new
effort
from
the
atmos
group
and
then
there's
a
couple
other
listed
here,
such
as
klim
preg,
which
is
a
lead
time,
dependent
diagnostics
and
then
this
model
diagnostic
task
force,
which
is
a
little
bit
more
process
oriented
but
I'll,
get
to
that
in
a
bit
and
so
kind
of
a
summary
of
the
current
packages
and
proposed
new
development,
so
kind
of
breaking
here
down
component.
M
As
you
can
see,
a
lot
of
these
use,
the
csm
post-processing
package
and
in
terms
of
the
new
development,
really
the
the
only
component.
That's
sort
of
committed
to
an
effort.
So
far
is
the
adf,
the
atmosphere
group
but
they're
still
uncertainty
in
terms
of
some
of
these
other
components.
So
hopefully
that's
something
that
we'll
sort
of
make
some
progress
here
coming
soon
and
then
the
cbd
p
le
calculations
are
moving
over
to
python
as
well.
M
So
an
update
kind
of
on
geocat.
Again,
because
I
know
a
lot
of
people
are
heavy
ncl
users,
so
ncl
computational
functions
are
being
migrated
over
the
scientific
python
ecosystem
through
this
geocac
comp.
So
this
is
the
the
computational
library
and
it
builds
on
sort
of
some
cornerstone,
pango
components
such
as
x-ray
desk
and
jupiter
notebooks,
it's
relatively
popular
popular.
So
far
and
again,
the
motivation
here
is
because
ncl
utilities
are
in
maintenance
mode
and
the
other
kind
of
component
of
geocat
is
the
geocat
examples
guide
similar
to
the
ncl
plotting
gallery.
M
So
a
lot
of
these
use,
matpot
lab
and
cardify
for
visualization
they're,
presented
in
jupiter
notebooks,
with
detailed
documentation
and
they're
partially
supported
by
this
project
pythia,
which
is
trying
to
provide
the
training
for
people
kind
of
making
this
pivot
to
python,
so
example
of
this
geocat
examples
page
so
similar
to
the
similar
to
the
ncl
gallery.
M
They
provide
these
sorts
of
examples
and
kind
of
provide
a
one-to-one
from
ncl
to
to
geotech,
and
the
geocat
team
is
very
much
focused
on
embracing
over
development,
so
community
user
contributions,
especially
within
the
csm
community,
providing
feedback,
helping
identify
and
prioritize
functionality
needs
so,
especially
some
of
the
climatology
related
functions.
It's
good
to
know
kind
of
what
people
are
needing
or
using
quite
a
bit
responding
to
questions
from
other
users.
This
was
a
big
cornerstone
of
the
ncl.
M
Development
was
just
having
a
very
strong
support
system,
and
so
that's
something
that's
very
important
to
the
geocat
team
and
they're
reporting
problems.
So
especially
if
you're,
if
you're
using
some
of
these
tools
within
the
geo
within
geocap,
make
sure
to
report
any
issues
you
run
into
because
that's
that's
really
important
and
then
also
being
open
to
community
developer
contributions,
so
helping
to
develop
new
functionality
or
identifying
existing
functionality
and
then
also
correcting
problems
and
sort
of
taking
that
community-based
approach.
Where
people
can
kind
of
contribute.
M
So
an
example
of
sort
of
geocat
in
action
specifically
related
to
open
development
is
ncl's
meant
to
p,
which
I'm
sure,
if
you've
ever
worked
with
atmospheric
data
coming
out
of
csm.
It
comes
out
out
on
those
hybrid
sigma
coordinates
which
a
lot
of
the
time
you
want
to
convert
to
pressure
vertical
coordinates,
and
so
this
was
already
on
a
geocat
roadmap,
but
couldn't
necessarily
be
prioritized
so
on.
The
left
here
is
a
screenshot
of
zulub
chat,
which
is
similar
to
slack.
M
Some
of
the
scientists
in
cgd
were
able
to
put
together
a
pull
request
and
contribute
to
to
the
geocat
code
base.
You
can
see
the
acknowledgement
there,
brian
medeiros
and
matthew,
long
and
deepak
sort
of
acknowledged
there.
So
this
is
an
example
where
the
geocat
team
kind
of
prioritized
and
implemented
this
with
the
help
of
scientists
within
cgd
and
car,
so
collaborations
like
this
obviously
are
going
to
be
very
important,
moving
forward,
especially
related
to
diagnostic
effort
and
looking
forward
to
continuing
to
collaborate
with
the
geocat
team.
M
So
geocat
provides
a
lot
of
the
core
functionality
that
will
be
used
within
diagnostic
framework.
M
So,
as
mentioned
before,
this
is
sort
of
the
the
first
first
group,
that's
sort
of
dedicated
to
sort
of
modernizing
and
moving
forward
with
these
new
diagnostic
efforts.
So
again,
if
you're
interested,
I
know
that
there's
talk
yesterday
about
this
during
the
atmosphere
section
of
the
the
atmospheric
working
group.
So
if
you're
interested
in
that
check
that
out
so
the
amw
diagnosis
framework
is
this
package
that
can
be
used
to
generate
standard
climatology
comparisons
as
well
as
variability
diagnostics,
sort
of
all-in-one.
M
It's
python
based
it's
again,
it's
a
replacement
for
the
amwg
diagnostics
package,
it's
modular
where
analysis
scripts
can
be
stored
within
these
modules
and
then
you
sort
of
have
a
main
driver.
That's
going
through
and
putting
everything
together.
M
So,
there's
a
link
to
the
repository
there,
which
is
again
very
much
under
active
development
and
sort
of
the
main
aspects,
are
averaging
regretting
plotting
and
then
looking
at
variability,
and
it's
able
to
sort
of
look
at
and
convert
from
history
to
time
series
and
it's
able
to
integrate
all
the
several
other
external
packages
such
as
mbtf
cbdp
and
any
other
relevant
packages.
M
So
the
idea
is
that
the
user
would
only
have
to
import
this
this
this
framework
and
it
would
go
ahead
and
take
care
of
a
lot
of
that.
M
M
It's
able
to
the
current
emphasis
at
end
cars
on
sub-seasonal,
the
seasonal
forecasting
s2s,
but
should
be
adaptable
to
other
time
scales
such
as
medium
range
and
annual
and
decadal,
and
there's
planned
work
on
conditioning
other
large-scale
states
such
as
nao,
piana,
pna
and
so
on,
for
state
dependent
predictability
and
it
uses
das,
which
can
read
in
data
from
disk
or
the
cloud
and
really
helps
with
the
performance
using
distributed
computing.
M
This
is
going
to
be
really
important
for
sort
of
working
with
those
lead
time,
dependent
diagnostics
and
so
some
overall
current
collaborations,
so
we're
trying
to
find
common
components
of
this
workflow,
so
example
of
history.
Time
series
so
have
an
easy
to
use
function
for
this
another
example
would
be
regretting
so
working
with
the
geocache
group
and
broader
python
community
in
order
to
make
regretting
a
little
bit
easier
and
then
also
exploring
interactive
web
pages
in
terms
of
visualizing
some
of
these
diagnostics.
M
So
what
exactly
is
earth
system
data
science?
So
it's
a
socio-technical
network.
I
would
strive
to
enable
this
collaboration,
so
it's
more
of
kind
of
getting
people
together.
Solving
these
problems,
sorry
there's
a
boat
come
by,
so
the
keys
here
are
finding
key
points
of
collaboration,
adopting
this
agile
approach
in
terms
of
prototyping,
so
many
solutions
and
finding
out
what
people
are
interested
in
and
then
sort
of
the
main
components
right
now
are
using
this.
M
The
zoola
platform
is
chat
platform
using
the
pangeo
discord
having
these
these
weekly
meetings,
where
we
can
kind
of
talk
about
some
of
these
prototypes
and
again
kind
of
iterate,
both
with
software
engineers
and
scientists,
we
have
a
variety
of
blog
posts,
kind
of
updating
the
community
and
what
we're
working
on.
M
So
these
are
hosted
on
this
website
and
this
link
will
be
available
after
presentation,
so,
for
example,
here's
an
example
of
building
intake,
esm,
catalog
for
csm2
history
files
and
then
basically
being
able
to
produce
these
different
packages
such
as
this
ecg
tools,
which
I'll
mention
briefly
after
this.
So
really
it's
it's
trying
to
find
these
key
points
of
collaboration
again
moving
forward
on
some
of
this,
so
a
concrete
example
of
esds
in
action.
M
So
one
of
the
kind
of
key
key
aspects
of
any
diagnostics
workflow
is
being
able
to
have
an
easy
way
to
sort
of
read
in
your
data,
so
we
leverage
some
key
components
of
the
pengio
community
and
the
geo
packages,
and
so
on.
The
left
here
is
examples,
so
we
have
all
these
different
components
of
model
output.
We're
able
to
take
this.
M
This
package,
which
basically
puts
together,
takes
all
these
files,
puts
together
this
data
catalog,
where
we
can
easily
query
our
data,
set,
look
for
certain
components,
streams
a
certain
case
if
we
want
to
look
for
a
certain
frequency
or
even
a
certain
variable.
So,
for
example,
if
you
want
to
look
for
temperature
from
this
data
set,
we
have
the
query
this
this.
This
basically
database
of
files
and
within
a
couple
lines,
be
able
to
read
this
in
and
get
a
quick
plot
of
our
data.
M
This
is
from
history
file,
outputs.
This
even
eliminates
the
need
to
generate
time
series
files.
So,
if
you're
interested
in
looking
at
this
example
and
interesting,
this
package
has
been
released
and
sort
of
a
write-up
of
this
is
provided
at
this
link.
But
again
this
is
this
could
be
a
component
that
would
be
used
within
these
diagnostic
packages,
where
you
could
basically
parameterize
being
able
to
read
in
the
data
across
its
sort
of
component
agnostic.
M
So
that's
again
very
important
in
terms
of
developing
this
next
series
of
diagnostic
packages
and
sort
of
another
collaboration,
so
this
is
more
sort
of
external
as
well
as
internal.
So
the
model
diagnosis,
task
force
or
mbtf
diagnosis
package
is
a
collaboration
with
noaa,
ncar,
ucla,
gfdl,
csu
llnl
and
then
doe
so
pretty
white
and
then
there's
several
other
universities
and
and
institutions
that
are
involved
with
this.
So
this
is
a
diagnostics
package.
M
It's
more
so
focused
on
process
oriented
diagnostics,
as
you
can
kind
of
listed
across
here
across
the
figure,
so
mjo
teleconnections,
dieno
cycle
of
precipitation,
mgl
spectra,
so
sort
of
more
focused
on
someone's
process
oriented,
as
opposed
to
mean
or
variability
diagnostics
in
the
this
effort.
So
this
diagnostic
package
currently
allows
for
multiple
environments,
languages
such
as
both
python
and
ncl.
M
So,
as
you
can
tell,
there's
a
quite
a
few
efforts
going
on
and
the
diagnostic
community
overall
is
moving
more
towards
these
scalable
workflows
within
the
python
ecosystem,
and
several
groups
have
already
started
this
effort,
so
geocat
kind
of
putting
together
some
of
the
basic
tools
to
be
used,
adf,
providing
kind
of
leading
the
way
in
terms
of
putting
together
this
framework
and
then
cbd,
ple
in
terms
of
some
of
the
variability
diagnostics
and
especially
working
with
some
of
these
large
ensembles.
M
So,
overall,
we
need
to
continue
to
find
key
components
of
collaboration
within
our
workflows,
such
as
we
can
reduce
the
amount
of
duplication
of
effort,
as
we
push
forward
so
again,
there's
relatively
limited
resources
towards
some
of
this,
so
hopefully
some
of
that
collaboration
will
lead
to
hopefully
improving
and
making
this
a
little
bit
more
efficient.
M
And
then
we
want
to
continue
to
train
other
software
engineers
and
scientists
contribute
to
these
efforts
and
find
external
collaborators
too
so
kind
of
even
looking
outside
the
end
car
organization,
especially
the
csm
community
people,
to
help
with
some
of
this
again
because
it's
a
large
undertaking
and
something
we're
looking
forward
to
collaborating
on.
So
at
this
point.
M
So
after
after
this,
I
also
got
to
take
a
couple
questions,
but
I
just
wanted
to
sort
of
introduce
after
this
we'll
go
ahead
and
go
into
some
small
group
discussion
kind
of
answering
some
of
these
key
questions.
So
how
do
you
incorporate
diagnosis
within
your
workflow
and
what
diagnostic
package
or
packages
do
you
currently
use?
What
features
do
you
think
are
required
before
you
would
use
a
new
diagnostics
tool
and
given
how
much
of
the
diagnostic
development
comes
from
volunteers
in
the
user
community?
B
Thanks
a
lot
max
for
that
that
introduction,
there's
there's
quite
a
lot
of
questions
in
the
chat
already.
I
can
go
ahead
and
read:
read
some
of
those
to
start
off.
Well,
let's
see,
there's
first,
a
clarification
from
dave
bailey.
He
says
the
cesm
post-processing
uses
python
packages,
pi
reshaper
and
pi
averager
to
create
climatology
and
time
series.
These
are
parallel
and
then
the
mcl
code
is
used
mainly
for
plotting.
That's
also
task
parallel.
That
is
multiple
plots
can
be
drawn
at
the
same
time.
M
Yeah-
and
I
do
know
that
so,
for
example,
the
pirate
shaper
and
pi
averager,
a
lot
of
that
is
so
yeah.
It's
able
to
it's
parallel,
like
it's
run
in
parallel,
but
again
at
the
core
of
it
too.
You
can
only
do
like
one.
You
can
only
do
one
variable
at
a
time
so,
especially
if
you're
working
with
some
of
these
large
ensembles,
for
example,
a
little
bit
more
challenging
but
yeah.
B
All
right,
let's
see
scrolling
faster
than
I
can
get
it
okay.
Here
we
go
from
alice
to
vivier.
She
said-
maybe
I
misunderstood
this,
but
I
thought
we
were
moving
away
from
having
history
files
available
and
wanting
everything
to
use
time
series,
because
those
are
smaller
to
store.
Is
that
right
or
is
that
a
misunderstanding.
M
Yeah,
so
I'm
not
I'm
not
really
sure
what
the
the
stance
is
on
that.
The
idea
with
sort
of
using
history
files
in
that
example,
was
to
sort
of
show
that
that
you
wouldn't
necessarily
need
to
do
that
conversion.
But
it's
flexible
enough
where
it
could
work
with
time
series
as
well,
so,
whether
working
with
time
series
or
history,
at
least
that
that
tool,
it
doesn't
really
matter
as
much
but.
B
Okay
lisa
asks
are
all
the
diagnostics
that
you've
discussed.
Are
they
all
being
run
offline,
that
is,
they
run
after
the
modeling
system?
Has
written
output
to
disk
or
some
of
them
in
line
with
the
model
runs.
M
N
Well,
I
I
already
typed
it
in
the
actually.
The
csm
post
processing
is
built
into
the
see
the
run
workflow,
so
you
can
actually
launch
it
at
any
point
in
time.
During
a
run,
and
that's
often
what's
done
is
if
we're
running
like
100
year,
production
run
sometimes
it'll
automatically
kick
off
the
post-processing
50
years
into
the
run.
Just
that
we
can
assess
and
decide
whether
to
keep
running
or
not.
B
D
I
was
going
to
make
some
clarifications,
I'm
not
sure
I've
kept
up
with
everything
here,
because
that
was
a
little
while
ago.
I
think
that
the
person
asking
about
running
or
doing
the
diagnostics
during
runtime
it
does
depend
on
how
you
consider,
during
the
run
dave
bailey,
is
saying
you
know,
like
50
or
100
years,
into
a
run.
You've
stopped
the
model
at
that
point.
You're
looking
at
the
history,
that's
been
produced
up
to
that
point.
You
can't
really
run
these
on
history,
that's
currently
being
produced
by
a
model.
D
That's
actually
running
it.
While
it's
going,
I
can't
remember
what
else
I
was
going
to
say
so
I'll
just
put
my
hand
down.
M
Yeah-
and
I
just
want
to
make
a
correction
so
yeah,
pyro
shaper,
which
is
being
used,
can
convert
history
to
time
series
in
parallel
using
mpi
and
all
variables
are
done
at
once,
so
that
was
kind
of
the
way
it
was
designed
so
yeah.
B
Let's
see,
there's
some
questions
and
comments
going
on
about
how
much,
how
much
and
whether
there's
actually
space
saving
going
from
history
to
time
series
and-
and
I
think
my
understanding
from
the
chat
is-
is
that
actually
there's
maybe
a
slight
increase
in
going
from
history
to
time
series
if
you're,
if
you're
using
the
whole,
if
you
still
want
the
whole
data
set,
but
the
advantage
of
the
time
series
is
that
you
can
you
can
transfer
individual
variables
just
the
ones
that
you're
interested
in
others
can
chime
in?
N
A
there
is
a
subtle
difference
here
too,
that
each
of
the
history
files
contain
the
grid,
information
and
the
metadata
in
every
single
one
of
those
files.
And
so,
when
you
run
the
time
series
on
it,
then
you
end
up
with
just
one
copy
of
those
variables
in
each
time
series
file
and
that's
actually
a
significant
savings.
F
And
if
I
can
interject
there's
another
issue,
which
is
that
data,
that's
written
straight
from
the
file
and
history
form
sorry
data,
that's
written
straight
from
the
model
in
history
file
format,
those
things
are
not
compressed,
the
pi
reshaper
can
compress
them,
and
so
usually
what
happens
is
in
the
conversion
from
history
file
to
time
series
what
you
end
up.
Getting
is
lossless
compressed
net
cdf
out,
which
is
smaller,
usually
than
what
you
started
with.
F
But
the
real
problem
in
terms
of
data
usage
is
the
fact
that
you
keep
both
of
them
history
and
time
series.
Therefore,
you
know
a
little
less
than
doubling
your
data
usage
to
keep
both
formats.
D
I
Sure
yeah,
so
I
don't
know
much
about
post-processing
of
data,
but
I'm
on
a
project
where
there's
some
discussion
about
whether
we're
going
to
time
series
or
keeping
history
and
I've
been
having
this
in
the
comments
discussion
with
kevin
and
the
answer
for
why
you
might
want
to
go
back
is
that
if
we
have
communities
that
can't
open
like
so
there's
some
question
can
matlab
read,
you
know
zar
files,
which
are
time
series?
Can
we
go
back
from
a
czar
and
recreate
a
net
cdf
history
file
from
that.
F
If
you
want
to
go
czar,
there's
no
reason
that
it
has
to
be
time
series.
It
could
be
something
in
between
time,
series
and
well
okay.
So
what
you're
talking
about
with
zar
is
the
chunking
of
the
files,
the
chunk
files
and
there's
no
reason
why
you'd
have
to
chunk
it
in
a
time
series
like
format.
F
I
I
think
it's
a
very,
very
difficult
question
to
answer.
I
mean
the
the
real
question
is:
why
do
you
want
to
keep
changing
the
format?
What's
I
mean,
what's
motivating
that.
I
Yeah,
so
I
think
that
in
this
case
it's
not,
it
might
be
a
case
where
80
of
a
community
is
served
with
one
format,
but
20
might
need
another,
and
so
it's
a
I
just
simply
didn't
know.
If
you
could
go
back
and
convert
between
the
two,
if
you
can
it's
not
a
problem,
you
do
what's
dominant.
If
you
can't,
maybe
that's
a
problem.
F
Right
so
the
pie,
reshaper
is
a
one-way
operation,
but
once
you've
converted
it
to
czar,
you
can
re-chunk
at
will,
which
is
one
of
the
advantages
to
czar.
F
So
if
you
want
to
change
your
sk,
your
chunking
scheme
from
what
essentially
looks
like
a
time
series
operation
to
something
that
looks
like
a
history
operation,
you
can
do
that.
There's
nothing
that
prevents
you
from
switching
them
at
any
moment.
F
But
yeah
I
mean
if,
if
you're
trying,
if,
if
80
of
the
community
needs
or
is
best
served
by
one
particular
format
and
twenty
percent
in
as
in
your
example,
is
served
by
a
completely
different
format,
then
I
might
recommend
the
twenty
20
producing
those
on
the
fly
for
a
particular
analysis
and
then
deleting.
N
Yeah,
there's
there's
other
one
another
monkey
wrench
in
this
and
gary
strand's,
not
here
so
I'll,
bring
it
up,
and
that
is
the
extra
step
of
then
making
things
cmap
compliant.
N
You
know
which
is
another
ugly
step
in
the
process
and
and
and
you
know
so,
it's
standardizing
the
time
axis
and
it's
converting
variable
names
to
standard
c
names,
and
you
know
things
like
that,
and
and
so
you
know
it's
just
that's
something
else
in
this
time
series
post-processing
that
often
sort
of
gets
left
out,
and
you
know
and
and
it's
you
know,
some
scientists
are
more
used
to
using
the
cmap
compliant
formats.
N
N
Of
the
best
strategies,
I
think
and
we've
been
talking
about
for
years,
but
I
just
wanted
to
contribute
that
back
to
the
discussion.
B
All
right,
given
that
it's
the
top
of
the
hour
there
are
still,
I
think,
a
couple,
more
questions
or
comments
in
the
chat,
but
should
max
do
you
want
to
do
you
want
to
move
on
to
the
discussion,
and
do
you
want
to
kind
of
interview.
M
Yes,
yeah
I'd
like
to
move
on
discussion
if
and
if
people
want
to
bring
those
up
after
and
sort
of
come
back.
This
larger
group
discussion
that'd
be
good
but
yeah.
So
I'd
like
to
sort
of
break
off
from
these
small
groups,
so
yeah
I'd
like
to
start
up
the
breakout
rooms
so.
D
M
Assigned
to
those
breakup
rooms-
and
then
I
just
I'll
just
ask
that
the
the
moderators
that
I
have
assigned
that
you
go
to
the
number
of
a
breakout
room
that
you
were
assigned.
So
I
can
go
ahead
and
drop
the
document
there
again
all
right,
cool
yeah.
I
don't
know
if
you'll
get
the
ability
to.