►
From YouTube: Alper Altuntas 2020 04 27
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
first,
a
couple
of
updates,
mom
6
is
now
fully
Incorporated
in
CSM
testing
and
tagging
workflow,
and
this
is
going
to
be
an
optional
component
in
the
upcoming
CSM
2.2
release
and
it's
going
to
be
released
sometime
during
the
summer
in
June,
and
we
already
have
Alpha
tags,
CSM
2.2,
Alpha
tags,
which
are
experimental
already
available
for
you
to
download
and
experiment
with,
and
currently
this
is
the
list
that
was
currently
available
in
our
configurations.
We
have
three
concepts:
cgmb
and
I'll.
Shortly
describe
what
they
mean.
A
We
have
two
forcing
sets
available
for
forced
cases,
Core,
2
and
jri55,
and
then
we
can
work
with
either
of
these
two
drivers,
MCT
and
noopsy
MCT
is
the
Legacy
driver
which
will
be
replaced
by
dunopsy
in
the
future
versions
of
cesn.
So
we
have
these
three
grids
available.
Currently,
2x066v1
is
our
Workhorse
grid
that
we
developed
for
mom6
and
cesm.
Specifically,
it's
two-thirds
of
a
degree
tripolar
grid
and
the
other
two
are
for
software
testing
purposes
on
the
gxv1.
A
V6
is
the
one
degree
pop
grid
that
we
inherited
and
then
txo25
is
the
quarter
degree
grid
from
the
mom6
community.
A
A
A
Gmail
is
pretty
much
the
same,
except
ice
is
also
active
and
be
mom
is
the
fully
coupled
case
where
all
the
components
are
active
except
the
wave
component
and
the
data
assimilation
component
and
our
future
work
actually
includes
incorporating
wave
gray
wash
3
as
well
into
this
configuration
in
the
third
slide.
I
have
the
description
of
the
cesm
repository
structure.
So
now
all
these
CSM
components
and
libraries
are
on
GitHub
and
they're
all
public
and
a
a
custom-made,
packager
called
manage.
A
Externals
handles
all
the
download
of
CSM
components
and,
if
you're
familiar
with
Git
in
this
context,
external
is
similar
to
what
a
gitsub
module
is.
So
if
I
say
Mom
6
is
an
external
of
cesm.
What
I
mean
is
mom.
6
is
a
sub
module
or
of
cesm
that
I
contain
within
the
CSM.
So
when
you
first
check
out
or
download
cesm
locally,
you
won't
get
any
of
the
components
in
libraries.
A
So
in
the
fourth
slide,
I
have
the
illustration
of
CSM
amongst
repository
structure.
Each
box
here
is
a
GitHub
repository
and
the
source
code
of
mom6
is
maintained
in
this
ncar
Fork
of
mob6
repository,
which
is
a
git
Fork
of
gfdl
mom6
repository,
and
we
periodically
synchronize
with
gftl16
through
pull
requests.
A
So
Mom
6
is
an
external
inside
one
interface
and
Mom
interface
is
a
CSM,
specific
GitHub
repository
where
we
Implement
our
superstructure
and
CSM
configurations.
One
interface
itself
is
an
external
in
CSM.
Gftl
also
has
this
mom6
examples
repository
that
are
that
is
similar
in
purpose
to
one
interface,
so,
starting
from
the
fifth
slide,
I
will
present
a
tutorial
on
using
map
16
cesm.
A
A
The
next
step
is
to
check
out
a
specific
tag
and
you
CD
into
the
cesm
directory
that
you
just
cloned
and
you
run
git
checkout
and
then
a
specific
tag
name.
The
tag
name
I'm
listing
here
is
a
CSM
2.2,
Alpha
tag
that
includes
one
six
and
the
reason
you
run
the
skip.
Checkout
command
is
to
update
this
externals
config
file,
and
that
makes
sure
that
the
components
and
their
versions
listed
in
this
file
is
are
compatible
and
stable
and
well
tested.
A
After
running
a
checkout,
you
can
now
download
all
the
components
and
libraries
by
simply
running
this
command
measure.
Externals
check
out
externals,
Dash
o,
which
is
critical
for
running
mom6,
because
Mom,
6
and
FMS
are
optional
components.
Currently,
so
you
will
need
this
Dash
o,
which
stands
for
optional
flag
to
also
check
out
maps
and
FMS.
A
So
in
the
seventh
slide,
I
mentioned
that
you
need
to
Port
CSM,
2.2
or
any
CSM
version
before
being
able
to
use
it,
and
it
can
be
pretty
much
accorded
to
any
Unix
or
Linux
machine,
and
it's
already
ported
to
many
of
the
major
Earth
system,
modeling
Community
machines.
If
the
machine
you're
working
with
is
not
in
on
this
list,
you
can
simply
follow
the
supporting
documentation
to
part
CSM
to
your
local
machine.
A
So
now,
I
will
start
talking
about
how
to
create
and
run
a
mom6,
CSM
experimentation
or
or
a
case
and
now
at
slide
eight.
So
what
defines
a
case?
It
want
to
find
the
CSM
experiment,
and
it's
very
basic
level-
is
a
comp
set
and
a
compatible
resolution.
This
is
a
list
of
Concepts
that
we
have
available
and
I've
already
mentioned:
Simon
Gmail
and
B
mom.
These
altered
versions
are
correspond
to
different
forcing
settings,
so
gmom
is
Mom,
6
and
size.
Only
core
normal
dealer
forcing
iaf
is
inter-annual.
A
Forcing
and
jrf
is
here,
a55
force
in
the
case
of
Jim
Andre.
You
have
two
compatible
resolutions
that
you
can
work
with,
and
this
resolution
expression
all
the
resolution.
Expressions
have
two
parts:
the
atmosphere,
grid,
Alias
and
then
the
ocean
grid.
Alias
tl319
is
the
atmosphere
grid
for
gra
data
set
and
2061
is
basically
our
Alias
for
the
Workhorse
grid
that
we
have
so
to
create
a
new
case.
You
run
this
create
new
case
script
inside
your
CSM
scene,
script
directory
and
you
you
need
to
pass
these
four
required
Flags
or
arguments
you.
A
You
may
add
more
Flags.
There
are
many
options
that
allow
you
to
customize
customize,
how
you
create
a
new
case,
but
at
a
minimum.
These
are
what
you
need.
You
need
the
run-on
supported
flag,
because
we
are
not
currently
fully
supporting
mom
6
cases
and
then
comes.
The
resolution
comes
set
and
the
case
name,
and
you
can
pretty
much
name
anything
you
like,
but
here
I
happen
to
name
it
see
that
resolution.001
and
when
you
run
this
create
new
case
command.
You
will
get
this
case
root
inside
your
working
directory.
A
You
will
have
some
tools
which
I'll
describe
in
the
following
site
following
slides
and
then
there
are
some
mechanisms
that
allow
you
to
customize
your
case
after
having
created
a
new
case,
you
can
set
up
and
build
the
case
by
cding
into
the
case
root
and
then
running,
case.setup
and
k-stop
build
commands,
and
at
this
point
you
can
customize
your
case
or,
if
you'd
like
to
run
the
out
of
the
wax
configuration
you
can
just
simply
submit
your
run
to
the
job
query
using
case
that
submit
tool
and
all
these
tools
again
are
in
your
case
root
and
now
I'm
on
slide
10.
A
So
we
have
three
mechanisms
on
customizing,
a
mob6
case:
XML
changes,
usernames,
mom
and
source
mods.
Each
of
these
mechanisms
correspond
to
different
purposes
in
the
case
of
XML
change.
What
XML
changes?
What
you
can
change
is
a
general
model.
Agnostics
settings
like
the
number
of
tasks
number
of
coupling
intervals,
job
crew
settings
things
like
that,
and
you
can
also
control
some
high
level.
Mom
6
Diagnostics
settings,
the
username's,
mom
or
user
NL.
A
Mom
is
a
text
file
insert
inside
your
case,
root
where
you
can
make
runtime
parameter
changes,
parameters
that
control
mom,
6
physics,
operations,
Diagnostics
and
other
Model
Behavior,
and
this
file
gets
automatically
translated
to
a
conventional
mom6
input
files
and
I'll
describe
how
that
works
out
and
the
third
option.
Source
mods
is
only
for
development
purposes
and
it
allows
you
to
override
auto-generated
input.
Files
and
I
won't
get
into
too
much
detail
in
this
mechanism,
since
its
development,
only
but
I
will
describe
XML
changes
mom
in
the
following
slides,
so
in
slide.
A
11
I
have
several
examples
of
XML
changes,
so
XML
change
command
allows
you
to
alter
the
values
of
XML
variables.
These
variables
configure
your
case.
Settings
in
the
first
cell.
I
have
three
examples,
and
by
the
way
you
can
change
certain
variables
at
specific
phases
or
before
specific
phases
in
the
first
cell.
These
variables
can
be
changed
only
before
you
build
the
case
like
the
number
of
ocean
tasks
or
whether
to
turn
on
the
debug
mode
or
whether
to
change
the
coupling
frequency
in
the
second
cell.
A
These
changes
can
be
made
pretty
much
anytime
before
you
submit
the
Run
by.
So,
if
you
have
already
run
a
startup
run,
you
can
run
XML
change
continue,
run
equals
two,
and
this
will
make
you
run
a
restart
run,
which
means
that
it
will
continue
from
where
the
previous
run
left
off,
and
you
can
also
control
the
round
Direction
by
setting
Stop
N
equals
three
stop
and
swap
ocean
option.
Equals
amounts,
and
this
will
set
the
round
duration
to
three
months
or
you
can
also
change
job
one
o'clock
time
by
default.
A
It's
12
hours,
so
it's
usually
a
good
idea
to
reduce
it.
If
you
don't
need
12
hours
and
high
level
monster,
Diagnostics
control
can
be
done
through
these
two
XML
variables.
Ocean
diet,
mods,
is
by
default
production,
and
each
of
these
options
correspond
to
different
predefined
Diagnostics
configurations.
Production
is
the
default
one,
but
if
you
change
it
to
spin
up
the
number
of
output
fields
and
the
frequency
will
be
lower
or
if
you
set
it
to
development,
you
will
get
more
output
fields
and
higher
frequency.
A
You
can
also
turn
on
or
off
the
ocean
Diagnostics
section
using
this
XML
change
command
and
just
like
we
can
change
these
XML
variables.
You
can
query
them,
as
I
s
provide
some
examples
and
to
have
a
slide
12..
If
you
run
XML,
query
XML
variable
name,
which
is
rounder
in
the
first
example.
You
will
get
the
value
of
this
round
directory
variable.
A
If
you
don't
remember
the
exact
name
of
a
particular
variable,
you
can
use
this
Dash
p
option
which
allows
you
to
or
which
instructs
this
tool
to
print
out
all
the
variables
that
has
this
string
in
its
name.
You
can
also
print
out
the
description
of
a
particular
variable
using
dash
dash
description,
option
or
dash
dash
valid
values.
Allow
you
to
print
out
the
valid
values
of
a
particular
XML
variable.
A
So
the
second
mechanism
is
username
is
Mom,
which
is
summarized
in
slide
13.,
so
you
can
again
change
all
the
month.
Six
runtime
parameters
by
adding
parameter
changes
in
this
file
and
again
it'll,
be
translated
to
Conventional
96
input
files
and
its
syntax
is
pretty
much
the
same
as
the
conventional
one
input
files
and
it's
practically
or
basically
value
equals
variable.
One
special
case
here
is
this
third
line.
Some
of
the
mom
six
variables
belong
to
modules
like
inter
type
parameter,
which
belongs
to
the
kpp
module.
A
A
So
that
concludes
the
tutorial
section.
I
will
now
give
a
little
bit
more
detail
on
how
the
runtime
parameter
management
works
in
cesn
and
now
at
slide,
14
and
15..
So
in
this
slide,
I
very
Briefly
summarize
the
conventional
16
runtime
parameter
system
with
orbital
CSM.
The
first
cell
here
is
from
Mom
6
source
code.
It's
a
typical
input,
parameter
initialization.
A
So
you
usually
have
two
input
files
for
a
particular
mom6
experimentation.
It's
not
always
the
case,
but
it's
the
convention
to
have
Mom
input
and
Mom
overwrite
files.
My
input
file
contains
all
the
non-default
parameters
that
Define
a
baseline
experiment.
So
if
you
write
h3s
equals
10,
then
when
this
subroutine
gets
called
this
local
variable
or
internal
variable
will
be
set
to
10..
A
If
you
have
this
mom
override
file
as
well,
and
if
you
overwrite
h3s
it
once
again
and
the
call
the
subroutine
code
will
set
that
parameter
to
2.5
instead
and
So
within
CSM,
what
we
did
was
to
adapt
and
somewhat
repurpose
this
commercial
and
hierarchical
1,
6
parameter
file
approach.
In
our
case,
mom
inputs
is
our
out
of
the
box.
106
configuration
and
it's
Auto
generated
and
cannot
be
changed
by
the
user.
Since
it's
the
out
of
the
box,
configuration
mom
override,
was
also
auto-generated,
but
it's
all
generated
from
username
as
mom.
A
So
user
has
the
full
control
here,
but
it
should
not
be
changed
directly
by
the
user.
It
should
be
changed
via
the
username
as
Mom
any
changes
you
make
all
in
these
connectional
files
will
be
overridden.
So
you
shouldn't
need
to
you
need
to
follow
the
mom6
mechanisms
to
make
changes.
The
hack
table
I
haven't
mentioned
yet
is
a
1
6
input
file
that
configures
the
Diagnostics?
A
It's
a
four
plan
file
for
Tran,
nameless
file
for
FMS
and
mob6
and
FMS
is
the
underlying
library
that
mom6
uses
and
generally
and
almost
always,
you
never
need
to
change
these
files,
and
so
it's
also
Auto
generated
and
cannot
be
changed
by
the
user
and
as
for
input
and
output
of
mob6
CSM
cases,
there
are
four
important
directories
that
I've
listed
here:
the
first
one
didn't
work
root
and
by
the
way
I
made
slide.
17.
A
the
the
root
directory
didn't
look
root
is
the
directory
of
all
the
component
input
data
like
the
grid
files
forcings.
These
are
usually
large
net
CDF
file
s,
and
this
is
coming
in
a
machine
all
the
users,
all
the
cases,
all
the
experiments
use
the
same
single
then
lock
route
directory.
A
The
other
three
here
are
case.
Specific
each
case
has
its
own
case
root,
which
is
a
control
desk,
where
the
user
can
control
the
case,
configure
them
or
run
them,
build
them,
and
then
the
Run
directory
is
a
temporary
directory.
That's
created
automatically
and
all
the
files
in
that
directory
is
also
staged
automatically.
It's
usually
in
a
scratch
space
and
the
outs
root
is
the
short-term
archive
directory
and
by
default
all
the
cesm
experiments
have
the
short-term
archiver
on
what
that
means
is.
A
So
this
is
the
case
route
you
have
on
the
left
and
when
you
run
usually
run
directory
is
empty,
and
when
you
run
one
of
these
tools,
all
the
input
files
will
be
automatically
staged
here.
I've
already
mentioned,
k-stop
build
case.submit
preview
name
list
is
also
very
powerful
and
useful.
It
allows
you
to
Stage
these
files
and
preview
them
them
without
having
to
build
or
run
your
case.
A
The
premium
name
list
is
also
inside
your
case
root,
so
this
slide
and
the
next
slide
I
will
describe
this
I'm
at
slide.
18.
I
will
describe
how
we
stage
these
files
automatically.
This
shouldn't
have
any
practical
value
for
end
users,
but
I
will
just
describe
this
for
background
information.
So
initially
what
we
did
was
we
had.
A
Our
current
approach
is
to
maintain
a
single
yaml
file.
Yaml
is
a
markup
language,
a
single
yaml
file
for
each
file
category.
This
is
more
of
a
c
Assam
way
of
maintaining
parameters,
and
so,
in
the
case
of
mob
input.yaml
file,
for
instance,
we
maintain
all
the
information
for
all
possible
CES
and
configurations,
and
these
files
are
dynamic
in
a
sense
that
the
parameter
values
can
be
tied
to
any
CSM
XML
variable
and
at
slide.
20
I
briefly
describe
how
that
Dynamic
Behavior
works,
so
I
have
three
cells
here.
A
Each
cell
is
among
input,
yaml
entry
and
these
entries
are
used
to
determine
the
values
of
mum.
Six
parameters
when
Mom
input,
the
actual
manual
input
file
just
created
inputer
is
a
map.
6
parameter
and
its
value
gets
set
to
this
expression
here
and,
as
you
can
see,
there
are
expandable
variables
and
these
variables
are
X,
XML,
CSM,
XML
variables
and
then
CSM
stages
from
input.
These
variables
will
be
replaced
by
their
actual
values.
A
The
second
example,
tripolar
n
is
again
a
monsters
parameter,
and
this
is
an
example
of
having
multiple
options
for
a
particular
parameter
and
in
this
case
which
option
to
select
is
based
on
logical
Expressions,
logical
constraints.
These
are
all
pythonic
constraint,
expressions
and
if
ocean
grid
happens
to
be
this
or
this
tripolar
and
gets
set
to
true
for
all
other
cases,
it
will
be
false.
A
The
third
example
we
have
the
mom6
parameter
deity
term,
which
is
the
thermodynamic
time
step
and
by
default
we
set
thermodynamic
time
step
to
a
number
of
coupling
or
a
coupling
interval
in
seconds,
and
this
formula
here
is
a
python
formula
that
evaluates
to
a
coupling
interval
in
seconds.
So
by,
if
you
happen
to
change
your
coupling
interval
through
XML
thermodynamic
time,
steps
will
be
updated
and
will
be
made
sure
to
be
compatible
with
the
coupling
interval.
A
A
So
we
also
have
this
Travis
continuous
integration
set
up
in
our
mom6
and
card
repository.
Since
it's
a
gft
out
Fork,
we
pretty
much
have
the
same
testing
infrastructure
and
testing
Suite.
We
also
have
the
same
Travis
infrastructure
for
our
mob
interface
repository
as
well,
and
we
test
we
have
some
unit
tests
for
the
mom
RPS
python
module.
This
is
the
module
that
stages
all
those
input
files.
You
also
have
some
consistency,
checks
and
we'll
enter,
but
the
backbone
of
our
CSM
development.
Workflow
is
this
CSM
testing
infrastructure?
A
It's
not
fully
automated,
but
it's
very
easy
to
use
and
very
easy
to
follow.
So
we
maintain
two
test
Suites
within
this
infrastructure,
which
is
which
are
called
oxmom
and
PR.
Mom
oxmom
is
the
comprehensive
test
Suite
that
we
run
before
pretty
much
every
month.
Six
pull
requests
and
tag
creation.
Paramount
is
a
light
version
of
that
and
then
csag
also
has
its
own
set
of
test
Suites
and
some
of
those
test
Suites,
including
the
pre-alpha
test.
Suite,
has
mom
6
tests
in
its
in
cell
as
well,
so
in
slide.
A
23
I
have
examples
of
how
to
use
this
testing
tool.
It's
pretty
similar
to
creating
a
new
case
again
cesmc
scripts
create
test
is
the
tool
that
you
need
to
run
and
actually
it's
easier
to
create
it's
easier
to
create
and
run
than
a
case.
All
you
need
to
do
is
to
provide
this
expression
here,
which
defines
your
test.
A
So,
finally,
some
reminders
and
conclusions
again:
mom6
a
functional
release
of
map.
6
is
going
to
be
in
the
upcoming
CSM
2.2
version,
but
it
will
very
likely
not
be
fully
scientifically
vetted.
Our
current
focus
is
on
gmom
gra
configuration.
We
are
trying
to
scientifically
improve
our
results
and
our
next
Focus
will
be
Beamon
case,
the
fully
coupled
case
so
early
versions
like
the
CSM
3.2
Alpha
tag.
A
It's
in
monitor,
face
GitHub
wiki
page,
and
this
is
also
an
evolving
documentation,
and
so
please,
let
us
know
if
anything
is
missing
or
unclear
and
then
finally,
we
very
recently
set
up
this
CSM
mom6
Forum
within
the
cesm
Forum.
If
you
happen
to
encounter
any
issues
or
any
have
any
questions,
you
can
just
post
that
and
we
will
gladly
have
and
with
that
I
will
conclude.