►
From YouTube: SimPEG Meeting October 13th
Description
Weekly SimPEG meeting from October 13th, 2021
A
Another
item
is
we
have
a
some
other
simpeg
seminar
tomorrow
at
two
o'clock
in
the
afternoon,
another
one
of
those
students,
one
of
shalom,
one
of
your
colleagues.
There
is
going
to
be
presenting
tomorrow,
so
we'll
have
a
another
good
talk
by
them.
I
know
they're
they're,
you
know
they're
always
I
love
that
they're
using
syntax,
so
much,
it's
really
nice
to
see
them
using
it
nice
to
see
other
people
using
synthetic
instead
of
just
our
own
stuff
other
than
that.
A
B
A
B
I
work
for
anglo-american
in
their
exploration
division.
It's
jaime
crystal
who's,
another
another
member
of
the
family,
so
it's
all
very,
very
incestuous
yeah,
so
I've
just
been
moving
there,
but
that
wasn't.
I
only
started
with
them
recently
and
previously,
with
bhp
in
exploration
as
well.
So
but
I've
been
using
simpeg
for
years.
Actually,
first,
the
first
project
was
before
peter.
Actually,
so
he
was
he's
a
die-hard,
fortran
guy
and
he's
like.
B
A
Again,
add
yourself,
so
we're
now
going
to
some
quick
reports
generally
just
kind
of
say
what
we've
been
up
to
recently,
with
simpeg
kind
of
just
what
we've
been
doing.
I
I'll
go.
First,
I
put
my
name
on
there
so
see
this
past
week,
I
I
was
able
to
do
a
bunch
of
like
I
don't
know.
I
just
had
a
bunch
of
things
that
I
could
do
a
bunch
of
things.
I
just
came
together,
so
we
finally
got
the
discretized
documentation
together
onto
there.
A
B
B
A
At
least
more,
we
all
hope
that
it's
more
explicit
with
what's
going
on
there
but
yeah
it's
in
the
other
thing
is
I
finally
pushed
to
do
that.
Our
implementation,
the
sidon
wrapper
for
pardesos
and
mkos
pariso,
is
on
there.
I
pushed
it.
It's
been
distributed
on
condo
forge
now,
so
you
can
get
it
through
there.
Then.
A
I
also
updated
pilot
solver
to
look
for
that
specific
for
that,
for
that
one
instead
of
the
old
pi
mkl
version,
so
that'll
that
should
fix
up
the
issues
with
the
mkl
version
not
being
correct
the
easiest
way
to
get
it
will
be
to
use
condo
forge
to
install
imac
solver.
It
should
pull
in
all
the
versions,
all
the
correct
linkages
of
everything.
Let
me
know
if
it
doesn't
obviously,
but
it's
it's
all
tested
against
them
on
a
different
version,
but
it
should
just
work
so
yeah.
So
that's
up
there.
A
What
else?
Oh,
I
find.
I
got
the
code
cup
working
again.
I
think
it
seems
like
it's
worth
working
again
for
sim
tag.
Now
it
just
needed
to
I
needed
to
like
refresh
the
integration
with
github.
I
think
it
just
like
lost
its
authorization
for
some
reason,
but
got
that
in
there
I
also
say:
okay,
you
have
a
synthetic
immersion.
Some
of
I
updated
the
testing
scripts
on
diving
on
that
branch
that
you
had
there.
A
I
just
updated
them
there
and
then
pulled
them
in
to
depend
on
the
new
playmat
solver
and
all
the
tests,
just
simple
tests,
I'll
pass
with
it.
So
that's
good
with
the
updated
version
also
merged
in
a
few
of
those
small
little
bug
fixes
for
snpeg
and
I'll
go
I'll
tag
a
patch
for
at
least
later
today
or
earlier
tomorrow
early
tomorrow
morning,
and
that
should
fix
a
few
of
those
issues
that
we've
been
having
with
people
related
to
the.
A
E
A
Oh,
it's
just
like
it's.
It's
related
to
combining
gravity
and
gravity
radiometry
data.
At
the
same
time,
like
just
kind
of
laying
out
some
basic
fundamentals
like
this,
is
how
you
actually
should
do
it
just
comparing
just
comparing
how
they're
frequent
like
their
misfits
change
as
a
function
of
like
if
you
weight
them.
How
does
that
actual
function?
Change
the
result,
comparing
it
it's
pretty
simple,
but
it's
just
it's
more
in-depth
and
more,
and
it
analyzes
it
more,
but
anyway
I'll
put
up
a
free
print
somewhere.
A
D
E
A
Was
in
there
too,
but
vanished
so
I'll
put
it
in
the
notes
you
can
see
like
it's.
It
just
uses
a
simple:
it
uses
that
uses
discretize
to
build
the
cell
gradients
and
then
the
rotated
inner
product
make
the
inner
product
reaches,
has
the
rotated
information
and
then
it
regularizes
it
that
way,
which
also
led
me
to
look
again
look
through
the
regularization
functions
that
we
have
already
and
comparing
the
simple
versus
the
tekonov
one
dom.
I
know
you
were
looking
at
it.
F
A
A
We
have
to
combine
them
like
the
lane,
the
way
that
the
length
scales
were
implemented
in
it
before,
like
the
simple
one
you
still
divided
by
like
the
cell
widths,
so
you
you
had
the
cell
stencil
cell
different
stencil,
and
then
you
divide
by
cell
widths
and
a
simple
one.
So
that's
that's
the
gradient.
That's
the
cell
gradient
right
there
right
and
then
it
just
then
it's
stabilizing.
A
F
Yeah,
okay,
yeah.
That
makes
sense.
That's
that's
about
right!
Yeah!
If
you
look
at
that
pr
you'll
see
there
like
it's
much
simpler
and
I
think
we
just
need
to
be
able
to
overload
what
the
functions
are
going
to
be
on
the
on
the
sub
objectives
right.
So
in
that,
in
your
case,
you
could
probably
just
overload
what
you
want
that
function
to
be.
If
it's,
instead
of
being
just
a
straight
up
gradient,
then
it
could
be
like
any
function
that
you
know
that
you
that
you're
computing
anyway,
that's
cool
glad
to
hear.
A
G
Yeah
so
like
as
a
very
small
item
just
like-
maybe
just
like
I
just
put
a
pr
in-
but
there
is
like
a
slight
discussion
to
have-
is
that
I've
worked
I'm
working
right
now
with
falcon
data,
and
I've
worked
with
them
before
and
in
those.
So
it's
a
great
airborne
gravity,
gladiometry
system,
and
they
measure
a
very
specific
data
for
that.
G
What
that
small
pr
is
doing
is
just
adding
that
uv
component
in
the
import
and
export
utils
of
gravity
data.
So
you,
if
you
export
it
in
a
ubc
format,
even
though
it's
not
going
to
be
readable
by
the
ubc
code,
because
it
doesn't
take
that
component,
but
still
within
simplex
that
works
pretty
well.
So
for
me,
it's
just
a
convenient
way
rather
than
having
to
like
export
an
empire
array
and
like
reattributing
the
data,
coordinate
and
uncertainty
and
so
on
or
create
a
pickle.
G
G
That's
that's.
The
only
was
the
only
trick,
it's
like
it's
a
ubc
export,
but
without
having
the
ubc
code
to
be
able
to
you
to
read
it,
and
otherwise
this
point
is
more
to
for
dumb.
I've
pushed
this
morning
like
a
branch
where
I've
like
cleaned
up
all
of
the
like
different
pgi
with
and
without
cell
weights.
I
did
that
quickly.
I
will
just
look
at
the.
G
I
created
the
pr,
but
I
I
realized
that
you,
like
you,
you're
working
on
your
branch
on
mirror.
So
maybe
I
can
just
remove
that
pr
and
you
can
just
pull
that
branch
into
yours
or
something
just
because
it
it's
not
a
pr
that
I
can
merge
into
main
right
now
or
I
will
need
to.
Maybe
I
need
to
create
zapier
on
your
fork
in
in
the
mirage
geoscience
fork
of
github.
G
F
E
G
G
G
G
A
A
D
D
D
I've
actually
done
my
first
local
build
of
the
validations
jupiter
book.
So
I
guess
for
those
of
you
who
aren't
aware,
I
have
a
bunch
of
jupiter
notebooks
and
the
idea
was
to
validate
simpeg
against
analytics
solutions
and
against
ubc
gif
or
any
other
coding
packages,
and
so
we
want
to
see,
you
know,
is
it?
Is
it
accurate
or
how
long
does
it
take?
D
Can
I
run
this
problem
on
my
laptop
and
so
I've
done
ford,
modeling
and
inversion
for
the
potential
fields,
codes
for
dc
and
ip3d
and
done
some
validations
for
forward
modeling
with
the
octree
meshes
and
the
frequency
domain
time
domain
em.
So
it's
actually
quite
extensive
and
the
jupiter
book
will
let
you
take
all
these
notebooks
and
then
build
them
and
turn
them
into
a
website.
So
I
have
that
done
locally
and
want
to
make
that
available
sometime
in
the
near
future.
D
So
this
is
kind
of
the
title
page.
It
builds
I've
made
some
fun
little
pictures
so
yeah.
We
want
to
compare
simpeg
against
analytics
solutions
or
some
other
packages,
and
so
you
would
right
now
you
would
just
sort
by
whatever
method
you'd
like
to
look
at
in
this
case.
Maybe
you
want
like
frequency
domain
em,
I've
got
a
fun.
Little
schematic
tried
to
make
some
fun
schematics
for
that
and
the
two
or
the
sorry,
the
three
four
validations
I
have
right
now.
I've
got
a
conductive,
1d
layered
earth.
D
I've
got
one
where
it's
also
susceptible
and
I've
done
the
sphere
in
a
vacuum
example.
So
you
would
go
and
click
on
one
of
these
and
you
would
have
the
comparison.
It
would
show
you
some
things
about
the
the
geometry
and
then
would
give
you
a
comparison.
So
in
this
case
I
I
had
a
like
an
x,
a
y
and
a
z
magnetic
dipole,
and
I
predicted
the
x
y
and
z
component
of
the
response
so
three
by
three
grid
and
compared
the
analytics
solution.
D
The
sim
peg
octree
e3d
version
one
and
e3d
version
2.,
and
so
I've
done
this
with
yeah.
Quite
quite
a
few
things
at
this
point.
So
there's
a
there's,
even
a
magnetics
inversion,
sparse
norman
version
for
a
block
and
a
half
space,
and
you
can
click
to
see
the
actual
script
that
was
used
to
construct
this
and
yeah.
In
this
case,
I
was
able
to
recover
it
using
sparse
norms
with
each
each
code
but
yeah.
D
F
F
D
D
B
D
D
E
B
H
Surprising
that,
because,
like
all
simpac
ubc
code
has
basically
same
bias
like
because
when
you
look
at
the
sometimes
they
don't
match
with
the
analytics
and
yeah,
it's
a
bit
surprising
that
they
kind
of.
I
was
just
like
thinking
about
the
random
worlds.
Like
I
was
thinking.
Oh
some
matches
some
doesn't
match.
The
numerical
codes
are
actually
almost
same.
D
You
have
kind
of
an
analytic
solution
for
the
potentials
in
in
your
domain,
apply
the
operator
to
construct
the
right-hand
side
and
so
you're
kind
of
solving
for
the
the
anomalous
contribution
that
way
so
they're
not
the
same
code,
and
when
you
go
and
look
in
the
details,
you
find
these
things
out
so
and
I
I
made
sure
that
I
modeled
these
with
identical
meshes
to
make
sure
that
that
wasn't
the
reason
why
things
were
different.
So
there
are
some
fundamental
differences
in
in
some
of
these
coding
packages.
F
H
H
A
Imagine
that
these
are
like
these
frequency
domain
ones,
they're,
probably
the
ones
that
are
closest
in
implementation
between
ubc
and
yeah.
So
I
would
think
so
as
well
and
also
knowing
that
they're,
both
using
like
cardiso
to
solve
it
on
the
back
end
too,
like
it's.
These
are
probably
the
closest
possible
things
that
are
same.
D
But
if
you
have
topography,
that's
not
necessarily
the
best
choice,
whereas
simpeg
will
actually
approximate
the
right
hand
side,
it
will
go
in
and
do
an
integrated
source
term
and
do
all
that
business.
So
the
the
way
that
the
right-hand
side
is
constructed
in
both
codes
is
fundamentally
different,
and
that
explains
why
it's
four
percent
off.
H
D
D
D
H
Yeah
before
you
do
that
dev,
I
guess
for
the
inductive
source,
you
would
rather
consider
just
using
there's
an
analytic
solution
for
a
path
like
a
for
magnetic
potential,
so
you
would
like
kind
of
do
the
same
trick.
So
you
derive
like
a
like
a
magnetic
potential
for
a
path,
and
then
you
basically
sum
that
over,
I
think,
a
like
a.
I
could
send
you
like
a
like
some
of
the
julia
curt
that
eldad
wrote.
D
Yeah,
so
there
was
that
was
my
understanding,
too,
is.
If
you
wanted
to
have
a
frequency
dependent
or
time
dependent,
galvanic
source,
you
may
choose
to
just
use
a
line
current,
but
then,
if
you
wanted
to
ensure
that
it
was
divergence
free
and
it
was
an
inductive
source,
you
would
use
the
magnetic
vector
potential
and
then,
when
you
also
take
like
a
numeric
curve,
so
that
it's
divergence
free
numerically.
H
D
H
D
D
D
H
H
D
A
Again,
I
it's
one
of
the
things
on
my
radar.
It's
where
we
it.
We
have
like
the
normal
normal.
You
know,
1d
simulations
working
and
they
seem
to
be
working
well
like
it
suggested
all
the
test.
Passing
they're,
just
still
parts
of
the
em1d
that
will
need
to
get
migrated
in
we've
talked
about
it
before
the
the
regular.
H
H
A
D
D
D
So
there's
there's
still
some
differences,
even
if
it's
the
same
mesh
and
I
used
a
the
same
kind
of
truncation
on
on
the
sensitivity
weights
yeah,
I
think
maybe
simpeg
is
updating
the
sensitivity
weights
at
each
beta.
But
I
I
kind
of
noticed
that
the
general
shape
of
what's
returned
is
much
different
between
simpeg
and
and
dcip
autry,
and
I'm
kind
of
curious
as
to
why
that
is.
D
It
kind
of,
for
whatever
reason,
the
sim
peg,
one
of
all
the
stuff
that
I've
tried,
kind
of
wants
to
like
bleed
out
down
and
to
the
outside,
and
I
did
kind
of
notice
that
it
was
putting
stuff
in
places
when
the
cell
size
increased,
and
I
did
make
sure
that
I
was
no
longer
using
taken
off
regularization.
I
switched
to
simple
and
it's
better,
it's
a
lot
better,
but
it's
not
quite
where
I
was
expecting
it
to
be.
A
F
D
Yeah
and
I
I
tried
to
be
careful
and
I
tried
to
see
how
far
along
the
convergence
curve,
it
was
because
the
I
believe
that
the
target
misfit
and
simpag
and
the
target
misfit
in
ubc
gif
there's
like
a
subtle
difference
between
those
so
and
also
with
simpeg.
You
kind
of
start
your
initial
beta
based
on
this
eigenvalue
thing.
So
you
can't
really
hard
code.
Your
cooling
schedule
in
the
same
way
that
you
tend
to
do
with
uvc
gif
codes.
D
A
A
A
When
I
replaced
it,
so
I
switched
it
to
the
new
kind
of
regularization,
so
the
only
this
is
what
is
it's
like
this
with
my
minimum
cell
width,
so
it
should
have
scaled
them
correctly.
The
same
way
as
it
should
have
as
it
was
before
like
this
should
have
accounted
for
that
difference
in
scaling
between
doing
it,
with
the
mass
cell
gradient
mass
matrix,
as
opposed
to
the
smooth
derivatives
for
the
simple
smooth.
A
A
A
A
A
Actually,
the
this
alpha
x
is
the
minimum
cell
width
squared.
So
that's
why
it's,
the
minimum
cell
with
was
4,
and
I
put
a
16
out
front
this
new
one
is
doing
it
like
this,
so
it's
taking
the
gradient
and
then
it's
building
this
and
that
this
mass
matrix
from
the
using
the
discretized
operator
for
the
faces.
A
F
H
A
F
Yeah
that
since
you're
getting
such
different,
such
different
values
you
just
the
alphas-
are
not
the
same
you're.
Probably
you
might
be
over
over
smoothing
in
in
your
case
than
the
other
case.
Right
possibly
it
looks.
I
mean
it
doesn't
look
like
a
like
an
actually
discretization
issue.
It
looks
more
like
we're
we're
regularizing
differently
than
the
model
right,
it's
smoother
than
the
other
one.
A
C
A
H
A
H
F
Yeah
and
at
the
same
time
we
talked
right,
the
the
only
thing
that
we
would
need
to
be
able
to
do
is
to
split
those
into
orthogonal
orthogonal
components,
instead
of
being
just
one
big
block
to
be
able
to
split
it
into
direct
for
half
of
the
directionality
right
say
like
this
is
like
one
direction
and
then
two
others,
because
then
we
have,
we
still
had
the
old
knobs
to
be
able
to
push
things
in
one
direction
versus
the
other.
Otherwise
it's
just
one
big.