►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So,
thank
you.
So
my
name
is
Travis
Luca
I
work
at
the
jcsda
Joint
Center
for
satellite
dab
simulation
and
so
I'll
be
discussing
it,
as
has
been
hinted
already,
is
Soca
our
sea
ice
ocean
and
coupled
assimilation
system-
and
this
is
our
marine
data
simulation
system
that
is
being
developed
for
operational
purposes,
both
at
NOAA
and
NASA,
and
so
the
the
court
team
for
Soca
consists
of
me
led
by
Guillaume
and
then
also
hamade,
we're
a
pretty
small
team.
A
A
A
We
have
people
in
Europe,
and
so
we
are
dedicated
to
improving
and
accelerating
satellite
data,
both
for
research
and
operations
and
our
partner
agencies
do
consist
of
NOAA
NASA,
who
we're
working
with
very
closely
for
Soca,
but
then
also
on
the
atmosphere
side.
A
lot
of
work
is
being
done
as
well
with
the
Air
Force
and
the
Navy
some
of
the
stuff
that
we
do
so
we've
kind
of
broken
up
into
three
categories
of
jcsda
book
does
a
lot
with
observations,
obviously
being
satellite
data
simulation.
A
So
we've
Matt
talked
a
little
bit
about
the
UFO
I'll
talk
about
that
some
more
City
UFO
and
the
community
rate
of
transfer
model
is
maintained
by
jcsda
the
algorithm
developments
which
I'll
talk
about
a
bit
and
in
terms
of
applications.
We
have
groups
working
on
Marine
da
land
da
and
Atmospheric
constituents,
so
the
I'll
be
talking
about
the
Marine
aspect
of
that.
A
A
A
So,
as
I
said,
Soca
is
being
built
within
Jedi,
so
so
what
is
Jedi
so
it
shares
some
of
the
goals
with
dart.
This
is
a
Next
Generation.
It's
a
unified
data
simulation
system,
so
it's
not
just
for
the
ocean.
It's
for
any
domain
that
you
want
to
hook
up
to
Jedi,
so
we're
using
it
for
ocean
and
Ice.
It's
also
being
used
for
land
atmosphere.
A
A
Let's
share
things
and
hopefully
doing
things
in
this
unified
framework
will
increase
your
research
operations
and
o
to
r
as
well,
and
hopefully,
an
increase
in
science,
productivity
and
code
performance,
and
if
you
want
a
much
longer
description
of
what
Jedi
is,
then
what
I'm
going
to
give
here,
there's
a
link
to
a
newsletter
that
we
put
out
before
I
think
it
was
AMS
last
year.
So
it
was
a
very
long
amount
of
documentation.
A
You
can
read
the
about
high
level
stuff
about
what
Jedi
is
and
how
we're
how
we're
developing
things
so
Jedi
consists
of
some
model
agnostic
components
they
can
be
used
across
all
domains
and
regardless
of
what
model
you're
using
what
grid
you're.
Using
what
observation
platforms
you
want
to
use
and
I'll
go
over
that
in
a
little
bit.
A
So
what
we
do
is
we
create
an
interface
to
the
mom6
model
for
the
ocean,
the
size
six
for
the
Ice,
and
so
unfortunately,
right
now
that
is
not
using
the
da
Hooks
and
those
interfaces
that
Matt
talked
about,
but
we
have
talked
to
Matt
about
hopefully
kind
of
unifying
the
way
that
we
talk
to
the
model
at
some
point
in
the
future.
So
we
we
passed
that
to
Jedi.
We
have
specific
observation
operators,
but
these
live
within
the
UFO
repositories,
so
they're
available
to
anybody.
A
So
not
just
us
with
Soca
they're
available
to
the
atmosphere
group.
You
wanted
them
as
well,
and
then
we
provide
our
representation
of
what
our
background
error.
Covariance
is
like
which
I'll
discuss
later,
and
so
we
give
it
those
things
and
what
we
get
back
from
Jedi
is
quite
a
bit.
So
we
have
a
whole
Suite
of
data,
submission
algorithms
that
are
implemented,
ranging
from
3D
bar
to
Ensemble
methods.
40
bar,
if
we
had
additional
things
included
on
our
side,
would
be
available.
A
Those
algorithms
can
run
in
core
or
out
of
core
so
similar
to
the
way
gftl
is
doing
their
enkf
in
core.
There
is
the
possibility
of
doing
these
algorithms
in
core
as
well.
We
have
advanced
observation
operators,
so
not
just
you
know
simple
ones
like
constitu
temperature
and
salinity,
but
also
you
have
access
to
the
crtm.
So
you
you
can
do
you
know
the
radio
transfer
models
as
well
with
your
hvacs
and
so
looking
at
the
components
of
Soca.
So
we
are
here
in
the
middle
The,
Soca,
monstix
interface.
A
I
know
we're
on
the
right
we
use
from
gfdl
the
mon
6
and
the
FMS
repositories,
with
ever
so
slight
modifications
to
get
it
to
work
with
our
stuff
and
on
the
left
side,
our
bits
and
pieces
provided
by
Jedi,
and
so
these
are
broken
down
into
two
little
groups
of
observations
in
the
the
algorithms.
One
of
the
things
that
Matt
did
talk
about
already
was
containers,
so
we
have
Docker
images
and
things
like
that
available
with
all
of
the
software.
A
You
need
to
run
our
data
simulation
so
a
lot
of
times.
You
know,
especially
for
operational
level.
Data
simulation,
there's
a
lot
of
complicated
things.
You
have
to
compile,
get
right,
make
sure
it's
working
on
your
HPC,
but
we
provide
these
images,
and
so
these
have
actually
been
tested
on
NASA's
and
noaa's.
Supercomputers
has
been
tested
on
Amazon
AWS
and
the
performance
on
these
are
almost
the
same
as
natively
running
it
on
your
HPC,
like
you
normally
would
with
loading
modules
and
things
like
that.
A
A
So
this
is
the
unified
Ford
operator.
It's
intended
to
work
with
any
model
once
you
get
it
hooked
up
with
Jedi
so
long
as
you
provide
it
certain
fields
that
that
it's
expecting
and
so
for
for
us,
a
lot
of
this
is
pretty
simple:
we
provide
it
temperature
and
salinity
and
sea
surface
height
so
that
we
can
assimilate
retrievals
of
those
various
observations
for
altimetry.
A
We
do
assimilate
absolute
Dynamic
topography
and
I'll
I
get
some
slides
on
that
later
sea
ice
fraction
thickness
and
then,
in
addition
to
the
UFO,
the
UFO
can
use
the
cr-10
crtn.
So
we
have
access
to
being
able
to
assimilate
brightness
temperatures
directly,
and
so
this
is
something
that's
not
done.
A
whole
lot
for
ocean
data
simulation.
They
haven't
gotten
to
the
point
where,
for
atmospheric
da,
this
is
the
standard
of.
A
A
So
one
of
the
benefits
of
using
this
Jedi
system
that
I
think
Matt
hinted
at
is
we
have
access
to
generic
quality
control
filters,
so
a
lot
of
these
were
I.
Don't
think
we
developed
any
of
these
ourselves
in
Soca.
These
are
done
mainly
for
the
atmospheric
da
systems,
but
they
are
generic
enough
that
we
can
use
them
for
our
system.
A
So
whether
it's
you
know
ship
track
checks,
background
checks,
buddy
checks,
things
like
that
thinning,
whether
it's
just
you
know
the
simple,
random,
thinning
or
smarter,
gaussian
thinning.
These
have
all
been
implemented
geared
towards
the
atmospheric
da
people,
but
the
generic
enough
that
we
can
use
them
and
in
development
as
well
by
the
Jedi
team,
is
variational
bias,
correction,
which
you
know
we
do
plan
on
using
with
our
radiances
once
once.
A
That
is
ready
to
start
playing
around
with,
and
the
great
thing
about
these
there's
no
coding
required.
So
they've
been
added
to
the
Jedi
code,
and
if
we
want
to
use
it,
we
just
set
something
up
in
a
configuration
file
and
so
the
number
of
ocean
d8
people
is
a
lot
smaller
than
the
number
of
atmospheric
gay
people,
and
so
whenever
we
can
use
work
that
they've
done,
it's
a
huge
help
to
us
and
I
think
UFO,
especially
in
terms
of
using
the
crtm
and
these
quality
control
filters.
A
That's
something
that
I
think
we've
talked
about
a
little
bit
about.
You
know
this
would
be
a
great
place
to,
for
you
know,
other
people
to
share
and
and
the
code
a
little
bit
and
you
can
just
use
the
UFO.
If
you
want,
you,
don't
have
to
use
all
these
other
parts
of
a
Jedi
over
here.
So
oops
is
the
generic
data
simulation
part
of
of
Jedi,
and
so
once
we've
created
our
interface
that
hooks
up
to
Jedi.
We
have
access
to
to
all
these
things.
A
Where
you
run
your
model,
say
the
state
and
then
do
your
observation
operators
on
top
of
that
Eda,
which
is
an
ensemble
d,
a
variational
based
I,
don't
think
we've
tried
using
it,
but
everything
should
be
there
for
us
to
use
Eda
as
provided
by
Jedi.
It's
just.
We
haven't
had
time
to
test
it.
We
have,
as
as
Dan
had
mentioned.
A
You
know
it
will
calculate
and
apply
your
correlation
and
localization
functions.
You
you
give
it
an
ensemble
and
it
can
calculate
these
things
for
you
or
you
know
what
we're
doing
right
now
for
some
things
within
Soca.
We
give
it
a
correlation
length
and
it
will
apply
this
in
a
smart
way
so
for
our
B
Matrix,
which
so
as
Dan
mentioned
with
DNA
methods,
you
can
either
use
an
ensemble
to
drive
your
your
background,
error,
covariance
Matrix
or
you
can
statically
Define
it.
A
We
have
a
combination
of
those
two
and
so
just
kind
of
a
high
level.
Look
through
this,
our
our
B
Matrix.
We
use
the
saber
package
to
do
some
cool
localization
for
us
or
correlation
links.
So,
for
example,
if
you
look
at
the
the
coast
of
Japan,
so
normally
so
things
like
the
Nemo
bar
system,
that's
being
used
in
Europe
for
ocean
D.A,
they
use
a
diffusion
operator
for
these
correlations.
A
A
That
we
didn't
really
have
to
you
know
we
didn't
program
these
things
ourselves.
We
just
use
these
packages
that
were
within
Jedi
and
the
other
important
thing
we
do
with
our
B
metrics
for
Soca
is
we
have
these
variable
transforms
used
for
imposing
balance
and
so
I
think
so
we've
basically
borrowed
what
is
being
used
with
the
Nemo
bar
in
terms
of
decomposing,
your
your
Ocean
State
to
balance
and
unbalanced
Parts.
So
in
this
method
we
can
actually
do
and
I
know.
A
Luanne
had
a
question
about
this
about
being
able
to
do
assimilating
altimetry.
So
we
can
do
this
within
soca
by
using
these
balance,
Transformations
and
so
altimetry
as
an
example.
Here
you
know,
if
you
update
the
sea
surface
height
in
your
model,
based
off
of
the
observations
directly,
that's
not
going
to
do
anything.
You
need
to
impact
temperature
and
salinity,
and
so
we
have
these
transforms
to
to
do
that
and
allow
us
to.
You
know
for
any
given
Alpha
metric
observation.
A
It
can
impact
the
entire
vertical
column
of
the
ocean
for
temperature
and
salinity
and
I
know
Bob
had
a
question
about
variable
transforms
handling.
He
you
had
a
question
about
handling
negative
tracers
that
should
not
be
negative,
such
as
salinity,
and
so
one
of
the
things
that
we
plan
on
adding
into
Soca
is
a
transform
here.
A
So
that's
kind
of
a
quick
high
level
overview
of
of
Soca
and
so
as
a
I
have
a
couple
examples
of
it
being
used.
So
we,
the
past
two
years,
we've
been
doing
a
lot
of
software
development
to
get
this
working
and
and
recently
we've
started
been
doing
more
useful
scientific
type
things,
and
so
one
of
these
is
a
real-time
Soca.
If
you
go
to
this
website,
you
can
see
this,
and
this
is
running
in
near
real
time.
A
A
Has
been
very,
very
fast
and
so
they've
accomplished
a
lot
over
the
past
two
years,
basically
starting
from
scratch,
and
so
the
code
changes
all
the
time
which
is
unfortunate
for
us.
But
since
it's
so
fast
paced,
we
need
ways
to
make
sure
that
every
change
that
they
make
is
compatible
with
their
system,
but
manually
testing.
This
all
is
not
humanly
possible,
especially
since
we
have
a
lot
to
do
already.
A
So
what
we've
done
is
we
have
a
continuous
integration
and
continuous
delivery
delivery
pipeline
set
up,
and
so
just
a
quick
overview
of
what
these
things
are
so
continuous
integration.
So
this
is
something
that
the
mom6
developers
practice
themselves
already
as
it
is
where,
when
you
push
any
code
change
up
to
GitHub
it
triggers
tests,
you
know,
make
sure
things
compile
and
we
have
a
suite
of
tests
that
run
on
a
very
coarse
five
degree
ocean
to
make
sure
things
are
still
working
correctly.
A
And
so
these
tests
passed
and
you're
allowed
to
merge
your
code
in
if
we,
if
we
approve
it
and
A
step
above
that
is
continuous
delivery.
Where
you
take
these
changes
on
a
regular
basis
and
you
test
them
in
a
production-like
environment
to
make
sure
that
they're
ready
for
release
and
RK,
we
don't
have
a
real
production
environment,
but
this
is
our
real-time
Soca
system
that
we're
running
every
night.
That
is
going
to
simulate
that.
A
I
think
Matt.
You
still
have
your
mic
on,
so
this
continuous
delivery
pipeline.
If
you're
at
all
familiar
with
software
engineering
methods
devops,
you
know
you
have
a
change
of
the
code.
You
you
build
that
change
online
on
Travis
CI,
you,
you
have
specific
unit
tests
that
try
to
test
everything
within
your
code
where
those
changes
could
hit
and
that's
being
done
on
every
single
jcsda
repository
every
time
a
change
to
the
code
is
being
pushed,
so
we
can
usually
say
with
pretty
good
confidence
that
you
know
whatever
change.
A
We've
done
should
work
within
each
repository,
but
then
that
system
as
a
whole,
we
keep
going
further.
We
we
do
an
integration
test
on
all
these
repositories
together
within
the
real-time
Soca.
We
do
a
near
real-time
run
with
a
two-day
delay,
and
this
is
being
done
every
night
at
I,
don't
know,
I,
think
2,
A.M
a
mountain
time
and
and
so
what
we're
doing
with
this
system
and
so
we're
using
a
slightly
coarser
resolution,
we're
using
the
one
degree,
mod
6,
75,
vertical
hybrid
levels.
A
A
Whenever
there's
any
change
to
the
code,
which
happens,
you
know
every
day,
pretty
much
even
on
holidays,
I,
don't
know
who's
doing
that
work,
but
pretty
much
every
day,
whenever
there's
change
to
the
code,
we
go
back
15
days
from
one
of
the
current
day
is
and
do
a
new
short
little
re-analysis.
This
gives
us
some
confidence
that
you
know
nothing.
Horrible
has
changed
in
the
code.
It's
not
a
full.
You
know
multi-year
scientific
round
to
to
evaluate
the
quality
of
sofa.
A
So
those
are
all
posted
to
this
website.
You
can
look
at
that
now.
If
you
don't
want
to
watch
my
slides
and
do
something
else,
and
so
we
have
two
tabs
on
the
top
right
one's
for
the
master
Branch.
That's
our
latest
branch
that
we've
looked
at
ourselves
and
determined
to
be
in
a
good
condition
and
something
we
can
use.
But
then
you
have
this
every
night
a
new
version
is
being
run
with
whatever
the
latest
code
is
and
that's
available
under
the
release
nightly
branch,
and
so
you
can
look
at
those.
A
You
can
see
the
differences
and
O
minus
B
statistics,
and
things
like
that,
so
we
can
kind
of
gauge
whether
or
not
the
system
is
working
as
intended,
and
so
this
is
still
constantly
being
updated.
So
we're
we
plan
on
adding
a
lot
more
Diagnostics
to
this
right.
Now,
it's
mainly
just
observation
space.
You
know,
State
space
should
be
added
at
some
point
things
like
that,
so
this
is
being
updated
quite
frequently.
So
if
you
want
to
keep
an
eye
on,
you
know
what
we're
doing
with
Soca
this
is.
A
You
can
see
the
differences
between
you
know
what
your
new
code
is
and
what
the
nightly
is.
In
this
case,
I
accidentally
had
sea
surface
temperature
assimilation
turned
off
and
I
turned
it
on
and
hey
everything
worked
better
lots
of
blue
as
as
was
hoped,
and
so
we
can.
We
can
see
these
nightly
runs
as
these
other
colors
here
and
so
after
a
couple
runs,
we
can
see
okay.
This
is
consistently
performing
better
than
our
current
Master
version.
A
We'll
update
this
to
master,
and
so
the
goal
ultimately
is
to
have
this
all
totally
automatic,
and
so
this
code
will
be
the
latest.
Stable
version
will
be
tagged
automatically
based
off
of
whatever
metrics
we
we
give
it
just
to
kind
of
summarize
that
so
so
the
benefits
of
this
okay,
the
benefits
of
of
this
continuous
delivery
pipeline
is
it's.
You
know
it's
publicly
available.
A
So
the
key
to
success
to
this
is
having
good
tests.
So
there's
a
lot
of
unit
tests
that
are
within
Soca
every
now
and
then,
though,
something
slips
through
and
breaks,
and
but
this
is
good
because
since
it's
not
a
production
environment,
so
we
take
that
and
we
learn
from
it.
We
figure
out
what
broke
make
sure
we
add
in
a
test
so
that
this
is
caught
by
the
system
automatically
the
next
time.
A
So
that's
one
thing,
that's
being
done
with
Soca,
just
kind
of
on
the
on
the
side
and
a
couple
slides
here
on
other
activities
going
on
with
Soca,
so
in
terms
of
some
cool
science
being
done
so
it
is
being
used
at
NOAA,
climate,
Prediction
Center.
For
some
observation
system
simulation
experiments,
so
so
I
think
Frank
Hewitt
asked
about
you
know
using
da
for
OBS
Network
design.
A
A
You
know
ocean
color
observations
from
both
beers
and
motives,
so
we've
we've
by
we
I
mean
Gilman
and
I-
haven't
really
done
much
for
this,
but
we
do
have
what's
needed
to
start
doing
some
work
with
assimilating,
a
chlorophyll
which
should
be
fun
radius
assimilation.
So,
as
I
mentioned,
Soca
has
the
capability
of
assimilating
radiances
directly.
A
So
you
know
you
could
do
these
separately
as
it's
commonly
done
now
or
within
the
Jedi
system
of
Ahsoka,
having
both
your
atmosphere
and
the
ocean
being
run
together
in
theory-
and
this
is
something
we
are
working
towards-
is
using
these
radiances
to
impact
both
States
at
the
same
time,
given
what
what
the
background
states
are.
So
that's
a
lot
of
fun,
interesting
work
that
should
be
happening
soon
and
I
think
this
might
be
the
last
slide.
So
we
have
a.
A
We
have
an
intern
who
never
made
it
to
the
U.S
because
of
covid,
but
Francois
has
been
working
remotely
doing,
machine
learning,
and
so,
instead
of
using
a
sea
surface
salinity,
retrieval
I've
done
the
standard
way
he
has
been
working
on
using
machine
learning
to,
and
you
know
a
database
of
co-located
in
situ
and
snap
data
to
come
up
with
a
algorithm
that
can
generate
a
retrieval
based
off
of
machine
learning.
There's
a
lot
of
promising
results
from
this.
A
It
should
be
I,
think
we've
started
now
actually
assimilating
these
and
so
we'll
see
soon
how
well
these
help
out
the
analyzes
and
okay.
No,
this
is
the
last
slide,
and
so
one
of
the
things
we'll
be
working
on
soon
we
just
found
out
we
got
funding
for
this
is
working
on
the
regional
Marine
D.A.
So
the
goal
for
this
is
to
be
used
as
initialization
for
emc's
halfs,
hurricane
analysis
and
forecasting
system.
A
This
will
be
based
on
Mom
six,
the
the
work
that's
already
been
done
with
the
global
D.A,
but
being
able
to
switch
models
and
plug
in
something
else
within
the
Jedi
framework.
Isn't
too
much
work.
So
there
will
also
be
a
support
for
any
encapsulation
of
ROMs,
and
this
could
be
nice
because
ROMs
does
have
a
tangent,
linear,
adjoint
and
so
with
access
to
that
it
would
be
possible
with
Soco
to
do
40
bar
with
Mom
six
using
the
tension,
linear
adjoint
within
ROMs.
A
It
could
be
a
fun
future
project,
and
so
some
work
has
been
started
on
this.
In
terms
of
you
know,
creating
applications
within
Jedi
to
do
down
scaling
of
the
global
to
Regional
grids
and
playing
around
with
regional
configurations
to
make
sure
things
are
working,
so
I
guess
I
am
out
of
time,
and
so
that's
kind
of
a
quick
overview
of
some
of
the
things
that
are
being
done
with
Soca
at
jcsda
in
our
partner
groups
at
NOAA
and
NASA.
E
A
So
I
believe
they
are
strongly
coupled
so,
and
this
is
something
that
we're
still
playing
around
with
our
B
Matrix
for
things
like
this,
so
there
should
be
some
code
in
there
so
that
you
know
you
assimilate
your
your
sea
ice
fraction
and
it
will
impact
the
temperature
of
the
ocean
at
the
same
time.
So
in
that
sense
they
are
strongly
coupled
okay.
A
E
A
A
So
it's
not
a
true.
You
know
we
don't
really
have
the
framework
for
strong
and
a
couple
D.A.
Yet
that
is
one
of
the
things
that's
supposed
to
be
worked
on
by
the
Jedi
team
this
year.
So
the
way
we
do
it
now
is,
you
know
we
can
do
things
within
SoCal.
You
just
pass
it
in
that
atmospheric
state.
So
we
have
a
file
we
read
in.
You
know:
we've
we've
augmented
our
Ocean
State
with
you
know
the
low
level
atmospheric
variables
and
things
like
that
to
do
this
here.
D
A
So
actually
yeah.
So
this
is
another
area
where
UFO
is
very
handy.
So
within
UFO
I
believe
hamide
has
added
a
Ford
operator
that
takes
into
account
the
ocean
state
and
the
atmospheric
fluxes
to
calculate
a
cool
skin
temperature
for
for
that
and
so
yeah.
So
that's
something
that
you
know
if
you're
some
other
model
hooking
up
to
Jedi.
You
don't
have
to
worry
about
that,
because
that
operator
has
already
been
added
into
UFO.
It's
something
that
you.
C
We
kind
of
classified
changes
depending
on
whether
they
are
bitwise
identical,
whether
they're
mathematically
equivalent
or
whether
there's
something
that
probably
needs
to
be
analyzed
carefully,
because
it
might
actually
change
Solutions
change,
climate
and
under
the
first
category,
bitwise
identical.
A
lot
of
things
would
be
like
an
extension
of
a
new
capability,
but
because
it
was
never
used
in
any
existing
test
cases
you
can,
you
can
add
it
and
start
working
with
it
within
the
testing
that
you're
using
I.
C
You
know
I
when
I
hear
you
saying
you're
you're,
seeing
multiple
changes
every
day
and
are
there
attempts
to
identify
those
changes
that
require
much
greater
scrutiny
than
others
in
in
any
kind
of
formal
way
or
are
all
of
these
types
of
bitwise
identical
mathematically,
equivalent
or
truly
answer
changing?
Are
they
all
treated
equivalently.
A
So
so,
right
now,
the
the
C
tests
that
are
available
within
Soca
on
Travis
CI
they'll
run
and
they'll
check
for
their
answers,
Within,
whatever
the
the
print
statements
are,
that
we
have
I,
think
there
might
be
seven
decimal
points
or
whatever.
So
within
that
it's
identical.
Otherwise,
the
test
will
fail
if
you're
running
it
on
your
own
machine
or
a
different
computer.
A
These
tests
have
tolerances
built
in
to
take
into
account
different
machines,
not
being
able
to
do
things
a
bit
identical,
which
is
really
a
problem,
especially
when
you're
looking
at
Intel
compilers
on
on
different
machines.
Gcc
is
usually
pretty
good,
and
so
so
on
Travis
CI
the
tests
will
only
they'll
fail.
If
you
know
you
have
a
change
in
answers
within
you
know
the
sixth
or
seventh
decimal
point,
and
it's
up
to
us
at
that
point
to
look
and
see
we're
not
worried
about
that
update
the
reference
answers
and
keep
going
on.
A
So
that's
the
point
where
things
had
been,
and
so
that's
one
of
the
uses
of
this
continuous
deployment
system
is
so
that
if
you
know
something
did
change
in
terms
of
the
answers
just
to
make
sure
that
you
know
it's
not
a
horrible
impact,
you
know
you've
got
this
15
day,
reanalysis
that
runs
and,
and
you
look
at
the
stats
and
see
okay,
the
O
minus
B.
You
know,
statistics
are
pretty
much
the
same
or
better.
A
You
know
it
didn't
really.
It
didn't
have
a
negative
impact
on
our
system.
So
that's
how
we're
handling
kind
of
a
difference
between
you
know
making
sure
to
the
best
that
we
can
things
are
mathematically.
You
know
within
whatever
Precision
the
same
and
if
they're
not,
then
we've
got
this
continuous
delivery
system
running.
To
give
us
a
little
bit
more
reinsure
reassurance
that
things
are
still
good.
C
Like
quickly
follow
up,
so
we
find
in
our
tests
even
the
changes
at
round
off
tend
to
Cascade
up
within
a
couple
of
days
in
a
fully
freely
running
system.
Just
you're
running
off
some
of
the
up
and
off
time
scale
for
some
part
of
the
system,
with
the
data
assimilation.
Is
that
enough
to
constrain
things
that
you
really
can
tell
the
difference
between
kind
of
flicking
the
bits
at
round
off
versus
things
that
might
have
changed
more
substantially.
F
A
Might
not
be
I,
don't
know,
so
this
is
one
of
the
reasons
we
need
a
longer.
You
know
one
two
year
runs
of
cycling
da
system.
That's
something
we're
pursuing
with
us.
Noaa
NASA
this
year
to
make
sure
the
system
actually
still
works
on
these
long
time,
scales
correctly,
but
our
the
way
we
have
the
test
set
up.
So
we
try
to
test
each
little
component
individually
and
we
had.
We
have
code
coverage
statistics
to
make
sure
we're
they're
really
testing
all
areas
of
our
code,
and
so
we
can
see
that.
A
Okay,
there
was
a
you
know,
a
tiny
change
in
the
mom6
forecast,
probably
because
you
know
something
you
guys
changed-
we're
not
too
worried
about
that.
We
trust
that
you,
you
know,
have
tested
the
mom
six
correctly
yeah,
but
you
know
the
the
answers
are
still
identical
in
terms
of
our
you
know:
3D
bar,
you
know
en
bar
things
like
that.
So
by
having
these
tests,
you
know
totally
separate.
A
Hey
Travis
great
talk,
I
had
a
question
that
you
might
have
addressed
when
you
responded
to
go
Khan
about
the
repository
when
I
go
to
Ahsoka,
dot,
jcsda.org
and
attempt
to
access
the
repo
by
clicking
on
that
top
right
corner
link.
It
says
404
page
not
found
so
I
was
wondering.
Is
it
a
public
or
is
it
a
private
repo
yeah?
No,
so
right
now,
I
think
I
think
I
made
the
real
time
public.
A
Maybe
I
didn't,
but
unfortunately,
all
of
the
Jedi
code
is
private
right
now
it's
easy
to
get
access.
If
somebody
needs
access
to
to
look
at
it,
but
they
do
plan
on
I
believe
it
was
going
to
be
the
end
of
the
summer
to
have
a
public
release
of
Jedi,
and
when
that
happens,
then
we
can
make
Soca
public
as
well.
A
So
it
is
Our
intention
very
soon
to
have
all
this
public
yeah
and
if
there's
you
know,
if
there's
something
you
want
to
look
at
see
how
we're
doing
things
you
know
something
you
wanted
to
work
on
with
this
we
can
get
people
access
to
this
pretty
easily
sounds
good.
As
a
follow-up.
Are
you
the
namesake
of
Travis
CI
yeah,
so
I'm
Travis,
CS
I'm,
the
non-continuous
travels
cool
now
now
I
wish
they
had
used
Jenkins
instead
of
Travis.
Yet
because
I'm,
tired
of
hearing
oh
Travis,
broke
something
different.
B
A
So
right
now
that's
running
on
a
tiny
machine,
and
so
it's
only
the
3D
bar
only
the
one
degree,
but
we
are
merging
with
the
help
of
Raul
and
other
people
at
ENC
merging
some
of
the
work
that's
being
done
in
terms
of
the
workflows
so
that
the
experiments
that
are
running
on
the
hpcs
for
the
hybrid
godas
are
using
the
same
scripts
being
used
to
this
real-time
system.
And
so
the
goal
is,
you
know
in
a
couple
months
to
be.
A
This
will
be
one
system
and
then
it
should
be
easy
for
us
to
change
from
doing
the
one
degree
to
quarter
degree
or
to
the
the
ensembles
with
the
let
calf
the
end
bar.
So
we
do
plan
on
seeing
what
our
resources
are
available
to
us
on
the
NOAA,
NASA
machines
and
then
upgrading
this
year
to
higher
resolution.
Ensembles
things
like
that,
still
running
still
running
and
near
real
time.
B
Okay,
another
question
related
to
earlier
talk:
Matt
Harrison,
the
CFL
system.
They
found
a
pre-aco
period.
The
system
you
know
made
me
may
have
a
lot
of
identities.
Do
you
think
would
be
a
worthwhile
for
soccer
to
to
have
a
like
whenever
you
you
have
upgrade
their
color
you,
you
have
some
baseline
for
the
pre-aco
period.
So
you
know
if
the
system
is
improved.
If
the
code
is
stable
for
pre-alco
appeared
things.
A
A
A
B
B
A
F
C
Okay,
so
this
is
something
completely
different,
so
Travis,
you
mentioned
the
idea
of
using
the
adjoint
from
ROMs
with
Mom
six,
which
is
fantastic.
We
are
very
confident
that
we
will
not
be
developing
a
tangent,
linear
and
adjoint
model
of
mom6
because
of
all
the
non-linearities,
but
we
recognize
that
an
adjoint
gives
you
a
unique
set
of
information
about
backford's
influence
of
information.
C
A
So,
as
you
point
out,
yeah
having
different
topographies
could
have
a
dramatic
difference
in
terms
of
you
know,
biases
of
the
two
models,
and
so
it's
not
something
that's
officially
on
the
list
of
what
we
are
supposed
to
be
doing.
But
since
we
will
be
doing
the
regional
ocean
D.A
and
as
part
of
that
there
will
be
an
interface
to
ROMs,
then
it
could
be
a
fun
research
opportunity
for
somebody
in
the
future
to
do
some
work
with
that.