►
From YouTube: SimPEG meeting July 23
Description
Presentation by Jae on his work doing joint inversions with SimPEG
A
Cool,
so
does
everyone
have
the
note
just
to
make
sure
friends
got
access
to
that
so
Jay?
The
way
we
actually
do
meetings
is
just
like
give
sort
of
a
quick
round
of
updates,
and
then
we
can
go
into
longer
discussion
items,
but
maybe
for
the
first
thing
for
for
quick
updates
today
we
can
just
like
each
do
quick
introductions
just
so
you
know
who
you're
talking
to
and
maybe
can
give
you
a
quick
overview
of
who
else
is
usually
involved
in
and
such
to
you,
okay,.
B
A
I
will
maybe
start
I'm
Lindsey
I
am
UC
Berkeley.
These
days,
I
did
my
PhD
at
UBC
in
Vancouver.
So
that's
where
a
lot
of
the
simpad
development
started,
but
now
I
work
on
basically
two
patern,
the
in
the
geosciences
I'm,
so
still
doing
a
lot
with
simple,
but
also
now
the
project
Jupiter
team
here
yeah
Joe,
do
you
want
to
go
next.
C
E
D
E
D
D
E
C
B
F
E
F
A
G
G
A
Okay,
oh
sorry,
but
heats
another
researcher,
UBC
he's
a
professor
who's,
doing
a
an
exchange
theory
student,
sabbatical,
they're,
gonna
connected
with
the
group
and
then
a
couple
other
key
people
who
are
looks
like
not
able
to
join
us
today,
so
soggy
King,
he
is
at
Stanford
also
did
his
PhD
at
UBC
and
he's
now
doing
a
lot
of
work
for
on
airborne
electromagnetics
for
for
ground
water
and
then
Tebow
a
stick.
He
is
doing
a
lot
of
work.
A
Just
a
couple
of
things
from
me
and
from
last
week
is
wrote
up
a
quick
blog
post
about
the
meeting
that
we
held
in
Montreal.
So
take
a
look.
If
you
have
extra
suggestions
or
things
that
are
unclear.
If
you
guys
have
questions,
I
mean
variably.
Other
people
will
so
happy
too
happy
to
take
those
and
provide
some
clarification
or
adjustments
or
such
yeah.
A
It
was
a
productive
conversation,
so
hopefully,
hopefully
the
vlog
does
some
justice
and
capturing
that
the
next
item
that
I
had
is
that
dieter
has
been
working
on
an
example
that
incorporates
a
few
different
open-source
Python
packages,
so
actually
starting
from
doing
some
modeling
with
gem
pine,
which
is
a
geologic
modeling
package
and
then
bringing
that
over
to
discretize.
So,
ideally,
we
can
then
start
running
simulations
on
it.
He
was
having
some
trouble
I
think
he
started
with
Mt,
and
the
MT
code
is
just
not
quite
as
mature
as
some
of
the
others.
A
E
A
A
A
A
And
then
the
last
quick
one
from
me
was
that
Craig
posted
an
issue
on
simpang
about
potentially
doing
a
user
survey.
The
timing
we
were
sort
of
thinking
after
the
simulation
release,
to
get
a
sense
of
just
like
what
pain
points
are
for
people
where
to
perhaps
focus
efforts
on
Doc's
and
examples,
and
things
like
that.
I
maybe
get
some
input
on
like
how
people
actually
want
to
interact
with
the
code
as
we
move
forward.
E
I'm
yeah
I'm
as
to
the
yesterday
today,
slowly
working
on
the
simulation
refactoring
for
potential
fields,
I
kind
of
got
lost,
though,
with
our
conversation
I
have
a
question
for
your
lens
day.
So
what
do
we
want
to
do
so?
We
agreed
that,
like
a
receiver
list
will
have
could
have
multiple
components
right.
C
E
In
case
for
magnetics,
you
could
have
TMI
and
the
gradients
all
all
attach
the
same
receivers
right
yeah,
how
we're
gonna
deal
with
cases
where,
let's
see
people
edit
out,
if
you
so
not
all
receivers,
have
all
the
components
like
are
we
gonna
have
like?
Can
we
have
an
index
like
I?
Don't
know
yeah,
boo-boo
love
a
true
or
false,
or
something
if
they
kicked
out?
What
do
you
think
yeah.
A
So
I
think
the
the
extension
we
thought
about
there
is
that
so
the
simplest
case
is
that
the
receiver
list
could
take
a
list
of
components,
just
like
you
said
so:
TMI
ingredients,
whatever
the
more
power
user
case,
would
be
that
that
thing
be
a
dictionary,
so
then
be
TMI
:,
an
array
of
pools
that
correspond
to
whichever
data
are
collected
versus
not
and
then
the
next
item
would
then
be
like
ingredient
and
then
its
value
would
be
an
array
of
pools.
Does
that
make
sense?
So
the.
E
E
So
dictionary
with
the
with
the
keys
being
there,
the
components
sounds
good
yeah
answer
the
question.
Okay,
and
if
it's
okay
with
you
I
would
ask
I
would
ask
a
potential
field
sparked
because
I
was
starting
to
bring
in
the
multi,
bringing
it
back
multi
processing
for
fertilization,
everything.
But
then,
if
we're
gonna
revert
back
vastly
there,
so.
E
A
E
A
F
E
F
E
A
F
F
D
G
C
A
F
E
F
E
F
F
A
B
A
B
Yeah
so
I
created
this
specifically
for
review,
like
what
I'm
doing
so,
like
you
know,
joint
inversion.
Some
of
you
might
already
be
familiar
with
we're
inputting
we're
like
we're,
giving
multiple
datasets
and
then
we're
inverting
them
simultaneously
to
get
multiple
physical
property
models,
but
in
a
way
that
they're
consistent
in
some
predefined
way
so
Tebow.
B
Two
and
well
for
my
research
right
now,
I'm
just
using
the
what
is
called
a
cross
radio
and
the
cross
gradient
is
defined
as
like
the
cross
product
of
the
spatial
gradients
of
two
models
and
we're
taking
the
sum
of
all
these
cross
products
over
the
whole
model
space.
And
so
we
want
this
sum
to
be
close
to
zero
for
models
to
be
more
as
like,
similar
in
structure,
and
so
what
I've
done
is
just
like.
B
I
wasn't
sure
whether
the
copying
could
go
under
our
regularization
as
in
subclass
of
regularization
or
just
soak
us
on
its
own.
For
now,
it's
just
a
class
on
its
own.
So
just
to
show
you
what
it
looks
like
what
I've
created
is
I
have
two
models,
just
know
that
are
not
not
similar
in
structure
like
there's
some
difference
in
the
structure,
and
so
what
cross
gradient?
Does
it
computes
to
a
non
zero
value.
B
So
that's
what
the
cross
training
does,
but
then
what
happens
when
the
models
are
identical
in
structure
the
the
cross
grading?
This
company
is
going
to
compute
to
zero
I
think,
but
it
also
computes
to
0
when
the
models
are
not
overlapping
at
all,
so
like
it
won't
enforce
a
structure
that
is
not
present
on
the
other
stroke
on
the
other
model.
So
just
that's,
basically
what
the
co
screening
does
and
so
yeah
the
ideal
case
would
be
that
we
run
our
joint
emergence
using
simplex
and
to
do
so.
B
So
what
I
do
first
is
I,
define
them
wire
mapping
that
basically
just
maps
from
the
stack
model
to
the
individual
models,
then
taking,
for
instance,
of
gravity
and
magnetic
stirring
the
abrasion
problem.
I
passed,
the
water
does
different
mappings
to
each
problem.
Then,
when
I
define
the
data,
Misfits
I
can
combine
them
together
as
a
combo
objective
function.
And
then,
when
I
compute
like
the
derivatives,
it
will
compute
the
derivatives
stacked
on
top
of
each
other.
B
That's
exactly
what
I
want
to
do
so
that
works
and
then
the
same
same
thing
with
the
regularization
like
I.
Think
I
just
need
to
pass
a
mapping
to
the
regularly
to
the
regularization
object
separately.
Then
I
just
combined
them
together
and
then,
when
I
take
the
derivatives,
it's
going
to
compute
the
derivatives
on
top
of
each
other
and
then
for
the
for
the
coupling.
The
coupling
is
just
a
function
of
more
than
one
of
the
two
models.
What
a
one
model
too!
B
So
the
derivatives,
the
dimension
of
the
derivatives,
are
going
to
be
consistent
with
all
the
other
derivatives
and
then
by
constructing
the
the
derivatives.
As
shown
here,
I'm
able
to
take
advantage
of
the
of
all
the
optimization
code.
And
then
it's
just
a
matter
of
small
three
things
that
I
need
to
do
to
trim
the
the
joint
abrasion
as
part
of
synthetic.
B
A
B
Like
the
data
misfit
and
the
regularization
is
taken
care
of
using
the
come
objective
function,
but
it's
it's.
The
Coptic
part
that
I'm
not
sure
how
to
include
as
part
of
whether
it
has
to
be
like
I,
wasn't
sure
whether
included
through
the
base
inverse
problem
class
or
I
to
create
a
new
one.
For
now,
I
just
created
a
new
one.
What
do
you
I.
E
A
So
that
I
think
actually
what
we,
what
we
should
do,
and
this
doesn't
stop
you
from
starting
to
putting
the
regularization
file
right
away.
But
right
now
the
regularization
file
is
enormous,
and
so
what
I
think
that
we
should
do
is
actually
just
like
break
that
into
a
folder
and
break
out
like
the
regularization
mesh
taken
off
style,
regularization,
the
sparse
stuff
that
Dawn's
done
and
then
actually
focusing
on
coupling
or
sort
of
joint
inversion,
tailored
objective
functions.
A
B
E
A
But,
but
do
you
need
to
actually
like
clear
fee,
sorry
feel
free
to
jump
in
dome
if
you
think
I'm
miss
you're
presenting
this,
but
I
think
what
Dom
is
referring
to?
You
is
that
there
are
cases
where
we
have
regularization
x'
that
actually
need
to
know
about
the
previous
iteration,
like
they
knew
about
the
previous
model.
With
this
one,
you
don't
need.
E
C
D
E
D
A
B
So,
like
the
stopping
criteria,
that
I
was
telling
you
about
it's
just
taking
like
our
current
model
and
then
the
last
model
taking
the
difference
and
then
just
like
normalizing
the
last
model.
So
it's
kind
like
a
percentage
update
the
model
and
the
way
that
I
did
it
right
now
is
just
I
added
a
new
stopping
criteria
in
the
optimization
class
because,
like
I
know
other
better,
like
I,
didn't
know
any
other
better
way,
yeah!
That's
how
I
implemented
that
yep.
A
Because
I
think
that
this
could
be
fitting
as
a
directive,
but
we
do
need
to
think
we'll
need
to
actually
think
through
how
we
compute
stopping
criteria
and
sort
of
what
are
like
the
anne's
versus
ORS
I.
Guess,
because
when
we
talk
about
a
joint
version,
another
thing
that
you
could
think
about
doing
is
making
sure
that
you
are
sufficiently
fitting
all
of
your
data
misfits,
in
which
case
you
know,
satisfying
only
a
single
stopping
criteria
for
a
single
term
like
gravity
we
shouldn't
actually
stop
the
inversion.
A
We
should
wait
until
all
of
the
stopping
criteria
are
satisfied,
whereas
you
might
also
want
to
have
a
stopping
criteria
where
it's
like
okay
fit
the
data
misfits
or
as
Jay
is
doing.
If
there
is
like
minimal
decrease
in
the
model
changes,
then
you
could
also
stop
there.
So
we'll
just
need
to
have
some
of
that
logic.
I
believe
is
in
simple,
but
it's
not
necessarily
completely
transparent.
At
this
point,.
E
Do
you
think
we
could
like?
Let's
say
we
start
reworking
optimization
that
we
should
actually
always
have
a
baby
bass
director?
Let's
say
Phi
T
star
or
something
but
it'd
be
great.
If
we
could
have,
if
you
could
add
a
fan
like
a
list
of
criteria
or
it
takes
some
out,
you
know
we're
not
having
to
go
inside
deep
inside
the
class,
the
optimization
class.
You
know
what
I
mean
yeah,
yeah,
cuz
I
know
we
hardwired
like
three
or
four
of
them,
but
it's
it's
either
not
enough
or
it's
too
much.
A
Or
some
sort
of
logic
statement
where
you
could
you
could
end
up
saying
like
the
example
that
I
just
mentioned
for
a
joint
version
is
like
satisfy
both
of
these
data
misfits
or
like
stop
changing
things
and
on
either
of
those
cases
I
will
I
will
stop
so
yeah
I,
don't
necessarily
know
how
we
store
the
anne's
versus
ORS.
Yet
you
know
I
do
I'm
saying,
but
but
with
that
yeah
I
agree
that
it
would
be
nice
to
have
have
a
list
where
we
basically
say
like.
D
E
A
A
One
directive
two,
which
is
target
misfit
on
phi
d,
2
I,
want
in
and
on
those
two
brackets
or
like
there's
minimal
change
in
the
model
updates
and
so
actually
to
be
able
to
just
write
that
out
in
code
and
say
like
Phi,
D,
1,
star
and
Phi
D
2
star
brackets
or
this
guy,
and
have
just
like
that
logic.
Written
as
you
would
write
a
statement
in
code,
yeah.
D
G
A
A
Very
cool:
are
there
other
questions
or
things
like
that?
They
came
up
as
you
were,
getting
up
and
running
things
that
you
think
they
like
are
clunky
or
that
we
need
to
rethink
I,
don't
know
if
you
followed
any
of
the.
If
you
had
a
chance
to
see
the
blog
about
some
of
the
stuff
we
are
trying
to
update
within
the
simulation
like
the
way
that
the
problem
and
survey
are
kind
of
structured
yeah.
B
A
So
what
we
could
do
is
I
think
actually
see
what
you
think
about
this
totally
open
to
suggestions,
but
I
could
start
a
branch
where
we
basically
break
the
regularization
into
folders.
So,
instead
of
just
like
a
giant,
you
know
regularization
file,
we
actually
break
it
up
into
folder
and
then
you
could
go
in
and
add.
We
can
have
one,
that's
basically
specific
to
two
joint
and
you
could
go
in
and
add
the
the
cross
gradient
term
there
would
that
be
without.
A
I
think
the
way
you
would
do
that,
if
this
is
okay
with
you
is
actually
awesomes
the
simulation
branch.
So
it's
like
one
level
beyond
where
simpang
currently
is,
or
is
that
do
you
want
to
be
able
to
work
with
the
current
version
of
simpang,
with
your
your
combo
or
sorry
with
the
across
gradient
term?.
A
What
we're
talking
about
doing-
and
this
shouldn't
change
too
much
from
the
outside,
like
from
from
the
user
perspective,
not
to
too
much
to
change,
but
what
we're
trying
to
do
is
you
know
how,
when
you
set
up
the
forward
simulation,
you
had
to
do
problem
dot
pair
survey,
we're
basically
trying
to
get
rid
of
that.
So
to
have
this
survey,
be
much
more
lightweight
and
really
only
store
sources
and
receivers
and
then
have
the
simulation
class
do
all
of
the
heavy
lifting.
So
the
simulation
knows
how
to
compute
the
fields.
A
A
We
could
just
jump
on
to
those
developments,
but
in
the
same
breath,
I'm
wondering
if
it
if
we
just
branch
off
of
master,
because
then
all
of
your
current
codes
will
still
work
and-
and
that
might
be
a
bit
easier
rather
than
sort
of
you
know,
changing
multiple
things
at
once.
If
we
go
right
off
of
master,
you
know
the
example
is
that
using
wood
still
all
work
and
the
changes
would
be
focused
very
much
to
just
the
way
that
you're
calling
the
cross
gradient
regularization.
A
A
E
A
B
A
It
should
I
mean
we
can,
we
can
take
a
look,
it
should
abstract
quite
easily
and
that's
something
we
can.
We
can
test
out
because
all
the
names
of
the
operators
and
things
like
that
are
the
same.
So
when
you
start
a
pull
request,
we
can
just
generate
generate
an
example
that
tries
it
on
the
octree
mesh
and
see
what
happens.
D
B
A
A
E
A
Cool
okay.
Well
with
that
thanks
everyone,
and
thanks
very
much
J
for
joining
us
today
and
sharing
all
the
work
that
you've
been
doing.
This
is
really
exciting
to
see
you
pushing
on
joint
inversions
in
simpie.
You
know,
we've
like
tried
to
think
through
so
many
of
the
pieces,
to
try
and
make
this
happen,
but
there's
yeah
not
too
many
examples
of
it.
Yet
so
you're
really
one
of
the
first
people
to
be
to
be
pushing
hard
on
extending
the
joint
version
capabilities.
So
that's!
It's
super
awesome.