►
From YouTube: SimPEG MT meeting November 6, 2020
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
Perfect
yeah.
Well,
thanks
for
taking
time,
I'm
excited
to
sort
of
push
on
the
mt
side
of
things
and
wanted
to
just
like
basically
connect
with
folks
see
what
your
priorities
are
and
see
if
we
can
sort
of
consolidate
efforts
or
sort
of
make
most
efficient
use
of
efforts
to
to
get
the
mt
codes
continuing
to
move
forward.
So
maybe
I'll
start
with
some
of
my
sort
of
goals
and
motivation
and
if
other
folks
want
to
jump
in
there
too.
That
would
be
great.
A
I
guess
like
most
immediately
agu
is
coming
up
and
we
put
in
an
abstract
saying
we
would
present
something
about
mt,
and
so
that's
a
good
deadline
to
have
of
a
so
hopefully
having
you
know
some
advancements
to
show.
If
we
can,
I
would
love
to
be
able
to
state
that
we've
got
even
a
first
pass
of
the
octree
code
up
and
running.
A
I
think
that
that
would
be
pretty
unique
and
pretty
exciting
for
the
community,
even
if
it's
like
on
a
branch
and
and
needing
some
work,
I
think
it
would
also
be
exciting
to
say:
we've
got
2d
because
it
seems
like
a
lot
of
people
like
definitely
use
that
for
cue,
seeing
and
it's
just
a
useful
tool
to
have,
and
so
that
would
be
nice.
But
I
don't
think
this
quite
is
well.
A
My
mind
is
not
quite
as
like,
critical
or
as
tiny
as
the
authority
and
then
also,
I
think,
finding
a
right
field.
Data
set
to
potentially
show.
I
don't
again.
I
don't
think
that's
super
critical,
but
it
could
be
nice
and
then
some
of
the
other
things
that
we've
been
talking
about
for
a
bit
of
a
longer
time
is
like
having
the
mt
or
the
natural
source
rely
on
the
fdem
simulation,
much
more
heavily
and
basically,
hopefully
have
sort
of
the
natural
source
implementation
adjust
the
sources
and
receivers
yeah.
A
But
I
will
stop
talking
and
let's
john
jump
in
because
you
were
next
to
me
on
my
screen.
B
Yeah,
so
the
mt
or
for
sorry
mt
side
yeah
the
2d.
I
I
I
personally
want
to
push
for
that
and
I
I'll
put
in
whatever
time
as
long
as
just
some
guidance
and
where
to
start
because
it's
just
a
lot
of
the
the
contracts
like
or
the
tenders
that
go
up.
Usually
the
2d
is
like
a
standard
deliverable
item.
So
that's
kind
of
the
push
from
my
side
to
get
a
tv
working
and
yeah
the
octree.
B
Actually
I
ran
the
apparent
resistivity
in
phase
just
on
the
simple
l
model
like
synthetic
and
yeah
the
x
and
x
y
and
the
y
x
work
the
off
diagonals,
but
the
xx
and
the
yy
are
kind
of
like
yeah
they're
kind
of
blowing
up,
but
probably
because
of
the
small
impedances
like
you're,
saying
lindsey,
but
yeah
once
we
have
that,
like
I've
already
got
code
to
compare
it
to,
and
I
would
like
to
start
doing
the
tiling
over
the
frequencies
too.
B
On
that
side,
that's
kind
of
my
my
goal
because,
where
dom
and
I
are
practically
there
to
start
getting
on
the
dc
so
once
the
dc
is
done,
it
should
be
easy
to
implement
the
implemented
on
the
frequency
domain
or
sorry
on
the
natural
source.
B
Not
sure
sorry,
just
getting
some
background
noise
yeah
all
right.
Sorry
right
there.
B
B
Bit,
did
you
lose
or
did
you
get
most
of
that
or
do
you
want
me
to
yeah,
okay.
B
E
Urgent
motivation
at
this
point,
but
we're
purely
interested
in
a
theoretical
standpoint,
and
I
want
to
make
sure,
like
things,
are
the
correct
way
right.
F
E
I
don't
have
like
a
real
like
motivation
on
the
work
side,
but
I
am
interested
in
this
problem.
I
actually
want
to
learn
a
little
bit
more,
so
yeah.
E
2D
implementation,
especially
specifically,
I
yeah,
I
think
I
kind
of
played
a
little
bit
as
I
got
script.
I'm
not
sure
if
it's
working,
but
I
got
a
script
run.
E
So
I'm
happy
to
help
to
the
process
and
I'm
more
like
interested
in
the
more
fundamental
problems
of
like
setting
the
boundary
conditions,
and
I
think
there
are
quite
a
few
like
a
theoretical
issues
and
that's
where
I'm
interested
in.
D
Joe
yeah,
I
mean
I'm
bored
to
help
with
whatever
I
can.
I
know
there's
at
least
the
one
day
part
is
pretty
well
going
in
there
and
it'd
be
nice
to
also
get
that
into
geo,
and
then
just
depend
on
that
in
synthetic.
D
As
far
as
like
updating
the
code,
this
kind
of
went
along
with
my
thoughts
on
devin's
thing
for
the
dc
part
about
how
to
properly
separate
out
the
the
source
and
the
in
the
simulation
side
of
it,
because,
like
from
what
I
from
what
I
see,
the
simulation
on
mt
currently
just
does
a
bunch
of
like
it's
the
thing
that
does
the
primary
secondary,
whatever
approach.
D
D
The
what
I
what
I
guess,
what
I
imagine
is
like
this
source,
where
you
just
give
it
a
function:
that'll
compute
like
a
solution
and
that's
the
thing
that
it
compares
that's
the
thing
that
it
uses
for
the
primary
source
or
the
whatever
the
fictitious
source.
So
it's
like
that's
what
I'm
imagining
this
right-hand
side
simulation
thing
to
work.
To
look
like
that
way.
We
don't
worry
about
okay.
Well,
is
it
a
layered
solution?
Is
it
a
1d
solution?
It's
like
this
source
doesn't
really
care.
G
G
I'm
just
really
curious
where
it's
at,
and
I
mean
I've,
seen
that
there's
a
lot
of
there's
been
a
lot
of
developments,
especially
deskifying,
simpac
and
kind
of
and
yeah
the
I
agree
with
making
it
just
a
frequency
domain.
G
Yeah
structuring
it
as
a
frequency
domain
thing
without
having
all
the
special
natural
source,
bibs
and
bobs,
especially
for
the
simulation
and
the
the
the
derivatives
and
stuff
like
that.
Just
will
make
any
updates
just
work,
hopefully
that
yeah.
I
think
that
would
be.
That
would
be
really
good
on
the
2d
side.
So
what
I
did
because
yeah
I
was
often
asked
to
do.
G
So
you
could
kind
of
just
put
them
in,
as
is
as
long
as
you
kind
of
were
somewhat
careful
about
how
you
designed
your
mess,
but
making
it
more
accessible
would
be
great,
and
I
guess
for
me
would
be
to
make
it
more
accessible
for
people
like
actually
adding
in
those
kind
of
nice
things
that
the
would
make
people
just
be
able
to
somewhat
jump
on
the
code
and
just
run
stuff,
and
I
do
have.
G
I
wrote
a
lot
of
stuff
for
myself
to
make
that
easier
and
it's,
I
think
the
utility
utilities
folder
within
the
natural
source
is
just
full
of
all
kinds
of
codes
that
I
just
wrote.
So
I
think
cleaning
those
out
and
making
them
such
that
they
work
for
other
people
than
me
and
and
making
like
tutorials
and
kind
of
examples,
and
I
mean
I
know
like
yeah
on
the
master
brands.
There
was
the
the
assemble
examples.
Are
I
mean
I
I
hadn't?
I
didn't
I've
never
updated
those.
They
were
all
like
all.
G
My
updates
were
in
the
brands
that
I'm
hoping
was
archived
somewhere,
because
I
can't
find
it
on
gift
anymore,
so
I
might
need
some
help
with
that.
But
and
then
lastly,
one
of
the
things
I
did
to
speed
up
the
code,
I
because
we
were
using
the
paradiso
to
solve
like
yeah
to
solve
the
matrix.
So
we
don't
have
an
iterative
solver
which
might
be
a
good
thing
for
the
empty
problem,
but
at
least
with
the
direct
solver
I
implemented
such
that
I
could
store
the
factorizations.
C
G
But
again
that
was
in
in
my
own
brand
somewhere
around
on
get
so
I
would.
I
would
really
like
to
dig
that
out
and
put
it
put
it
somewhere
more
useful,
because
I
think
at
least
for
me
that
was
something
got
there
was.
I
think
it
was
a
factor
of
5
speed
up
and
there
was
like,
maybe
10
lines
of
code.
G
G
A
Excellent
thanks
dom
we
were
just
kind
of
going
around
getting
a
sense
of
what
people's
priorities
and
interest
and
involvement
might
be.
So
if
you
wouldn't
mind,
jumping
in.
F
I'll
be
mostly
a
listener
here,
but
obviously,
what's
on
what's
on,
my
radar
is
if
we
can
start
decoupling
the
the
meshes
for
the
frequencies,
because
that
makes
the
most
sense,
I
think
so
yeah
I
just
want
to
stay
just
hear,
what's
gonna
happen
so
that
they,
just
you
know,
keep
track
of
the
changes
or
whatnot.
A
That's
good
and
doug.
C
Oh
I'm
basically
just
listening
in
got
a
long
interest
in
seeing
this.
This
developed
and
yeah
be
really
it'd,
be
really
really
nice
to
have
something
that
we
could
use
to
showcase
mt
from
simpeg
and
well
has
solved
a
whole
bunch
of
problems,
as
we've
talked
about
before
so
many
people
interested
it
sounded,
like
goodness,
already
pushed
a
number
of
issues
that
that
could
be
looked
at.
C
I
I
guess
I
was
running
just
as
I'm
sitting
here
without
knowing
anything
about
what
has
really
transpired
is
is
do
do
we
have,
I
mean
something
to
to
kind
of
build
on
to
say,
okay.
This
is
this
is
kind
of
where
we're
at
with
the
current
modeling
I
mean,
maybe
because
I
know
soggy
had
checked
with
the
l.
You
know
the
l
block,
that
was,
that
was
kind
of
a
nice
standard,
one
that
didn't
have
topography
on
it.
A
E
I
think
death
f
probably
have
it.
I
think
that's
what
I'll
I'll
ask
that
I
think.
C
C
So
there's
you
know
things
like
putting
that
l
block
into
you
know
a
background
structure
so
that
you
know
here's
now,
where
the
boundary
conditions
kind
of
play,
a
role,
and
you
know
then
there's
issues
of
topography
and
how
we
actually
address
them
yeah.
So
I
guess
I
I
was
just
kind
of
trying
to
get
a
sense
of
you
know
given
where
we
are.
What
is
it
that
we'd
really
like
to
accomplish?
C
A
So
maybe
that's
actually
a
good
place
to
start
is
just
like
a
quick
high-level
summary
of
where
we
are
I'll
start
talking,
but
john
has
got
more
experience
recently
in
the
empty
code,
so
feel
free
to
jump
in
and
tell
me
when
I'm
saying
something
that
is
off
base
so
and
joe
as
well,
because
you
know
where
the
1d
is
at
that's
when
I
do
not
have
a
pulse
on
as
much
so
recently,
devin
and
joe
rewrote
the
the
1d
implementation
actually
joe.
D
Actually,
we
just
so
already,
there
was
a,
but
there
were
1d
implement,
1d
solutions
in
there
already
like
there
was
just
a
general
electric
field
magnetic
field
solution
and
then
one
that
kind
of
did
it
in
terms
of
impedances,
measured
at
the
surface
that
one
is
a
little
bit
easier
to
use
for
inversion
purposes.
D
A
A
B
Yeah
on
regard
to
that
1d
code-
I
just
we
did-
or
we
used
it
on
this
recent
survey-
that
we
did
and
we
compared
the
1d
results
to
the
2d
auction
code
and
yeah.
It
matches
up
pretty
well
so
that
1d
code
is
working
pretty
well.
A
D
I
was
planning
on
going
through
and
speeding
it
up
a
little
bit
more
the
same
way.
I
just
did
with
these
with
the
1d
frequency
domain
stuff,
at
least
it
should
at
least.
A
And
do
you
think
we
should
move
to
relying
on
that
for
the
primary
secondary
approach
or
it's
just
doing
impedances
at
the
surface.
D
We
could
also
I
mean
what
I'm
imagining
is
that,
like
I
said,
with
these
kind
of
primary
secondary
approaches,
it's
like
you
could
almost
just
have
a
general.
You
know
fictitious
source
that
given
a
source
like
given
the
source,
location
or
some
sort
of
properties
in
a
grid
location,
it
can
generate
whatever
field
you
want.
It
doesn't
have
to
even
be
specialized.
Any
sort
of
you
know,
method.
A
Yeah,
no,
I
think
that
that's
let
me
see
if
I
can
reiterate
that,
because
I
see
I
think
that
that's
probably
something
that
not
resonates
or
doesn't
quite
resonate
with
everyone.
So
let
me
re
read,
word
and
see
joe
feel
free
to
interrupt
me
if
I'm
making
no
sense
so
the
the
connection,
but
there's
a
couple
connection
points
here,
is
with
the
dc
code.
A
Devon
recently
implemented
a
primary
secondary
approach
for
dc
that
computes
the
half
space
solution
to
then
sort
of
give
us
like
more
accurate,
receiver
or
sorry
source
a
source
term.
If
we
have
like
you,
know
a
uniform
half
space,
and
so
the
way
that
that's
implemented
right
now
is
actually
inside
of
the
simulation,
whereas
what
we've
done
more
so
in
the
frequency
domain
code?
Thinking
about,
for
example,
a
magnetic
dipole
it
is
the
primary
secondary,
is
completely
taken
care
of
by
the
source
term
and
actually
in
the
3d
mt
code.
A
That
is
how
it's
currently
done
as
well.
There,
I
don't
think,
there's
any
assumptions
in
the
3d
mt
well,
I
mean
there's
of
course,
assumptions
because
of
the
boundary
conditions,
but
there's
nothing
in
there.
That
is
assuming
like
the
primary
secondary,
doesn't
touch
the
3d
simulation
code.
It
comes
in
through
the
source
term,
which
I
think
is
like
a
bit
of
a
cleaner
way
to
go
in
terms
of
tracking
derivatives
and
also
keeping
the
simulation
code
pretty
tight
and
so
joe.
A
If
I'm
understanding
you
correctly,
the
idea,
with
sort
of
like
a
base
class
primary
secondary
source
that
could
serve
most
of
simpeg,
is
basically
like
what
you've
kind
of
said
is.
We
can
basically
define
any
sort
of
function
that
given
a
mesh,
gives
us
the
fields
that
we
need,
and
we
can
then
construct
the
right
hand
side.
Is
that
a
fair
sort
of.
D
Yeah,
that's
what
I'm
saying
like.
We
could
essentially
simplify
a
lot
of
these
classes
and
not
necessarily
simplify,
but
I
just
unify
them
a
little
bit
more
and
that
okay,
these
are
you
know
whatever
fictitious
sources
there,
and
that
class
could
eventually
be
a
lot
more
general
and
apply
in
almost
any
situation
that
we
have
some
sort
of
analytic
solution
that
we
want
to
use
as
the.
C
G
Yeah,
I
I
think
that
is
I
I
like
that
idea.
It
would
be,
I
guess
it
would
be
almost
similar
to
kind
of
the
time
domain
and
the
waveforms
it's
it's.
I
find
like.
I
found
that
really
cool
kind
of
the
decoupling
between
the
two
like
that
you
have
the
source
and
you
just
assign
a
waveform
function,
so
you
you
can
intermingle
them
as
your
heart
desire.
A
So
maybe
a
step
towards
that
because
so
I
know
I
owe
joe
comments
on
devin's
full
request
and
what
I'm
going
to
comment
in
verbal
form
is.
I
agree
that
the
source
I
should
take
care
of
the
primary
secondary,
and
so
maybe
actually
a
step
towards
this
is
like
this
already
is
the
case
in
the
frequency
domain
code
and
so
perhaps
like.
If
that
can
be
abstracted
in
the
dc
pull
request,
and
then
we
can
kind
of
take
a
step
back
and
say
like.
A
A
D
Yeah,
I
think
so
I'm
going
to
try
to
get
him
to
split
up
that
pr.
E
A
like,
I
don't
really
see
a
like
a
I
it'll,
be
nice,
like
you,
have
a
parallel
structure
and
a
software
point
of
view
right
in
a
practical
sense.
I
don't
really
see
a
like
a
great
use
case
of
in
terms
of
structure.
I
totally
agree
like
it's
much
better
kind
of
having
the
same
structure
but
yeah,
I
think,
on
the
front-end
side.
I
don't
really
see
kind
of
real
benefits
of
doing
that
anyway.
E
So,
just
like,
that's
just
a
thought,
but
like
structure
wise,
I
absolutely
agree
that
would
be
would
be
nice.
D
E
Right
so,
like
my
only
concern
was
yeah
that
the
current
structure
is
kind
of
like
a
did
it
in
an
optimized
way,
just
to
make
it
fast
enough.
So
as
long
as
we
don't
hurt
that,
I
think
that
I'm
pretty
happy.
D
My
my
imagine
like
my
thoughts
here,
is
that
it
would
be
such
a
thing
where,
like
the
simulation,
would
at
least
be
able
to
recognize
that
it
sees
a
fictitious
source,
then
do
whatever
it
has
to
do
to
translate.
Okay,
I
do
this
fictitious
source.
I've
got
to
do
this
operation
to
it,
to
get
my
right-hand
side,
so
it.
What
my
point
is
it's
decoupling,
whatever
that
fit
history
source
is
from
the
simulation
got
it.
A
So
then,
sort
of
some
of
the
the
next
pieces
just
to
kind
of
keep
moving,
so
this
is
kind
of
like
the
structure
of
the
the
sources
and
so
boundary
conditions.
Obviously,
is
a
question
that
that
comes
in.
A
I
think
that
like
for
now,
my
suggestion
would
be
perhaps
that
that's
like
a
next
a
a
little
later
down
the
road
is
that
I
would
suggest
we
focus
first
on
the
octree
and
on
like
the
match,
decoupling
and
things
like
this
and
that
getting
a
2d
code
in
place
and
then
once
those
things
are
there,
I
think
it'll
start
to
be
easier
to
think
about
boundary
conditions.
B
Yeah,
I
agree
because
that's
kind
of
where
everything
is
kind
of
at
right
now
is
yeah.
So
now
that
we've
got
the
apparent
resistivity
in
the
phase,
we
can
do
impedances
and
I've
done
like
that.
The
work
I've
done
on
desk
is
like
it
does
have
speed
ups
and
it's
it's
just
over
frequency
and
it
does
the
it
calculates
the
feels
on
the
fly
kind
of
thing,
but
it's
still
not
quite
fast
enough.
Not,
I
don't
think
it's
going
to
give
us
the
speed
up
like
we
would
in
thailand.
So
again.
C
G
I
I
would
also
say,
on
the
on
the
data
and
receiver
side
of
things.
G
It
is
fairly
inefficiently
done
in
terms
of
just
it's
constantly
looping
and
because
the
data,
the
data
in
mt,
is
all
dependent
on
all
of
the
sorry
lacking,
worse,
essentially,
all
of
the
the
components
but
but
we
we,
we
calculate
each
of
the
real
and
imaginary
components
separately
in
a
loop,
so
you're
you're
constantly
recalling
everything,
and
even
though
we
store
some
of
those
vectors,
it's
still
you're,
still
recalculating
or
retrieving
them
like
all
the
time
like
every
single
calculation
and
then
just
not
using
them.
A
G
G
E
Well,
like
initial
assumption
that
we
made
the
projection
is
cheap,
so
that
was
like.
Oh,
we
don't
care,
we
don't
care.
How
many
projection
we
evaluate,
but
is?
It
is
not
necessarily
the
case
and
also
how
the
fields
works,
even
when
you're
calling
a
single
field
actually
takes
time.
E
If
you
just
store
the
predicted
data,
because
I
think
in
the
optimization
you're
calling
the
prediction
quite
a
number
of
times,
so
I
think
in
such
a
way.
That's
how
I
did
it
in
the
dc
and
I
people
problem.
So
you
make
sure
only
a
single
prediction
for
each
field,
a
call
then
yeah,
then
I
think
that
it's
probably
it
was
okay.
E
F
And
we
can
do
the
same
trick
to
you
right
start
exclusively
historically
compute
the
sensitivities
and
store
them
instead
of
doing
the
j
of
x
gt
back
on
the
fly.
I'm
interested,
though
good
need
to
to
see
your
code
that
you're
storing
the
factorizations,
because
we
were
talking
about
it,
but
we
never
got
to
this.
G
Yeah
yeah,
I
just
just
sold
it
and
just
put
it
into
a
list
or
a
dictionary,
probably
for
each
frequency
and
then
so
as
long
as
you
were
within
your
like
ram
bounce
of
the
system,
you
were
using
it
yeah,
it
was
kind
of
it
worked
relatively
well.
I
found
yeah.
F
G
Yeah-
and
I
do
believe
paradiso
has
that
already
you
can
have
it
work
off
core
or
out
of
court
or
something
like
that.
Oh
really,
well,
yeah.
F
D
But
I
don't
even
know
if
that,
like
happens
well
in
parallel
or
anything
or
if
it
can
store
multiple
frequent,
like
I'm,
not
sure
how
it
knows
what
file
to
put
it
in.
I
don't
know
right.
I
have
to
remember
look
back
at
it
when
it
does
the
backseat,
you
mean
yeah,
I
do
know
there's
not.
You
can't
really
like
store
it
from
session
to
session,
though,
which
is
unfortunate.
D
E
Yeah
I
was
hoping
to
pickle
it
and
then
send
it
over,
but
it's
not
working.
Oh
it's.
F
E
E
I
would
just
do
on
the
fly
because,
as
joe
said,
it's
nice
to
store
it,
but
the
if
you
have
a
serial
code,
that's
fine,
but
once
you
move
on
to
parallel
code,
it's
hard
to
hard
to
do
so
so
how
to
reuse
that
authorization
you're
still
limited
by
you
know.
E
Right
and
the
gym
like
a
storing
jia,
so
I
think
it
depends,
though,
if
you
can
manage
to
decrease
the
mesh
size
small
enough,
then
I
would
actually
store
j,
but
if
the
mesh
is
still
big,
I
wouldn't
store
it,
because,
even
if
you
have
a
large
hard
drive,
that'll
be
really
large.
So,
yes,
I
think
that's
sort
of
the
choices
that
we
need
to
make.
E
But
at
this
point
I
wouldn't
worry
about
that
too
much
and
basically
like
do
a
different
mesh
for
a
different
frequency
and
yeah
do
an
octree
first
and
if
you
have
a
time
and
then
think
about
the
parallelization,
I
think
that's
probably
a
better
sort
of
order
of
operation
that
we
could
go.
Otherwise,
there
are
too
many
things
that
we
could
do.
E
B
E
Yeah
and
I
think
like
we
probably
need
to
play
a
quite
a
bit
of
okay.
What
are
the
better
mesh
for
each
frequency
right?
There
we
can
there.
We
can
actually
save
quite
a
bit
of
like
computation
cost
by
just
setting
a
right
mesh,
giving
us
okay
accuracy,
but
as
well
as
like
a
small
enough
mesh,
and
if
you
can
establish
that
there
then
yeah.
B
E
Think
that's
where
I
was
curious
about
joe.
So
so
I
think
lindsay's
point
previously
was
like:
is
it
better
to
use
a
numerical
solution
to
generate
a
source
tone
or
better
to
just
analytic
solution
and
use
that?
I
think
that
is
that,
what's
your
question
lindsay
yeah
yeah.
So
what
do
you
you
know?
What
do
you
think
my
thoughts.
D
I
mean
if
you
have
an
analytical
solution
that
matches
your
problem.
Well,
I
think
it's
better
to
use
that,
but
I
don't
imagine,
as
I
don't
like
the
thing
that
I'm
imagining
doesn't
depend
on
whether
it's
an
analytical
or
numerical
solution
for
the
you
know,
whatever
fictitious
source,
if
you
really
wanted
to
use
like
a
3d,
simple
numerical
simulation
as
your
function
that
generates
your
solution
to
compare
against
right
like
I
that's
why
I'm
imagining
this
thing
being
a
little
bit
broader
and
able
to
handle
these
things
a
little
bit
easier.
D
E
D
E
Match
I
see
I
see
I
I
misunderstood
a
little
bit
that
joe,
I
think,
in
the
secondary
field
formulation.
The
boundary
condition
is
basically
zero,
so
you
don't
really
get
that
kind
of
tissue
source
idea,
actually
solving
the
system
and
generating
a
fictitious
right
inside
yeah
after
you
do
a
fictitious.
D
E
What
the
fictitious
source
means
so
what
yeah
there's
a
little
bit
of
difference
because,
like
what
joe
is
saying
is:
okay
suppose
you
know
the
solution,
then
you
have
a
system
matrix
a
and
you
solve
for
the
true
right
hand,
side,
but
you
solve,
for
I'm
not
sure.
E
You
essentially
solve
yeah
you
solve
for,
like
the
right
hand
side.
So
so
you
know
the
solution,
so
you
basically
multiply
your
system
matrix
to
a
solution.
Then
you
get
a
right-hand
side,
that's
what
he
meant
fictitious
source
yeah.
So
it's
like.
So
by
doing
that,
you
make
sure
you
get
a
true
solution
for
at
least
for
a
given
given
setup.
E
I
I'm
not
sure
like
I
in
having
an
option,
will
be
good,
but
I
wouldn't
set
that
as
a
default.
D
A
Yes,
so
in
terms
of,
I
guess
maybe
like
next
steps,
because
I
think
before
we
sort
of
go
too
abstract,
we
want
to
get
some
of
the
like
the
a
bit
of
the
refactoring
done
and
I
sort
of
see,
I
think,
two
things
that
can
develop
in
parallel.
A
I
would
say,
like
I
think,
the
octree
and
getting
that
working
with
a
primary
secondary
approach
can
develop
in
parallel
with
sort
of
the
refactor
to
have
the
simulation
basically
be.
The
frequency
domain
code
is
so
the
I
and
I
think,
the
lift
for
the
simulation
to
be
the
frequency
domain
code
is
not
actually
too
big.
A
A
G
G
So
and
you
just
it
is
so,
the
the
natural
source
source
would
just
be
kind
of
a
wrapper
onto
two
frequency
domain
sources
that
just
returned
to
the
two
polarizations,
and
that
is
essentially
what
it
did
and
then
we
would
adapt
the
functions
that
deal
with
the
receivers
and
data
to
just
take
in
those
two
take
in
the
fields.
I
guess
from
those
two
separate
sources,
but
they
kind
of
do
at
the
moment.
I
think
it's
just
wrapped
into
a
for
loop.
G
If
I
remember
correctly-
or
I
mean
it's,
it
solves
them
independently
completely
and
then
just
at
the
end,
when
you
have
a
you
want
to
calculate
the
data
you
retrieve
from
both
both
of
them,
so
I
think
that
would
be
so
whether
it's
implemented
just
as
a
matrix
or
or
a
list
of
two
sources
or
a
list
of
two
vectors.
I
mean
that's
more
or
less
the
same
thing:
yeah
yeah
as
long
as
just
everything
is
kind
of
factored
accordingly
yeah.
A
Yeah
yeah,
and
so
I
think,
like
the
simplest
first
step,
would
be
to
just
like
treat
it
as
a
basically
a
matrix.
Now
that's
coming
out
from
a
single
source,
and
then
we
can
sort
of
maybe
re-evaluate
internally
how
that
source
is
structured.
I'm
kind
of
thinking
of
just
like
first,
let's
just
rip
out
the
simulation
code
and
see
if
we
can
get
things
working
and
then
sort
of
and
then
go
from
there,
because
then
I
think
like
that,
would
still
then
interoperate
with
the
nscm
fields
and
the
nsem
receivers
and
so
like.
A
Yeah
so,
and
does
that,
first
of
all
sound
reasonable
and
sensible
to
folks.
B
I'd
even
sign
up
for
that,
like
I
can,
I
can
make
a
head
start
on
that
in
the
coming
days
for
sure
and
yeah.
Maybe
I'd
like
to
the
reason
why
I
also
like
to
do
it
is
maybe
we
can
start
putting
x-ray
into
these
things
if
we're
going
to
start
from
kind
of
going
from
that
similar
frequency
domain
class,
I
can
start
looking
at
what
I
was
doing
with
x-ray
with
the
fields
and
yeah
build
it
up
into
a
nice
package
that.
A
Would
be
super
cool?
Where
do
you
want
to
work
on
this,
because
I'm
also
happy
to
throw
some
effort
at
this
piece
as
well,
just
on
your
simulation
mt
branches,
that's.
B
Does
that
make
sense?
It
worked
last
time
so.
A
B
A
Should
we
maybe
do
a
progress
first
on
the
apparent
so
we've
implemented
apparent,
resistivity
and
phase
now
for
receivers
as
well?
We
do
need
to
think
through
and
why
john
said
his
is
failing
when
you
have
the
on
diagonal
components,
the
xx
and
the
yy
for
the
phase,
it's
very
easy
to
have
those
gradients
blow
up,
because
if
the
impedance
is
small,
they
pull
up
that's
dividing
by
them.
A
So
what
we
could
do
is
just
implement
for
now
a
simple
like
epsilon
floor
in
the
denominator
and
that
will
keep
things
stable.
There
might
be
like
other
things
we
want
to
think
through
with
that,
but
I
think
it's
like
a
first
implementation.
That
seems
reasonable
to
me.
A
So
in
some
ways
I
maybe
suggest
that
we
like
do
that,
pull
request
just
so
that
we
can
keep
these
things
like
sort
of
tightly
scoped
and
it
doesn't
end
up
being.
You
know
like
a
10
000
line,
nsem
refactor
pull
request,
the
other
thing
that
I
did
with
that
and
we
can
dive
into
the
details,
maybe
on
the
pull
request
and
give
me
if
you
have
time
to
look
at
this.
A
I
certainly
appreciate
your
perspective
on
things
too,
so,
right
now
in
the
derivatives,
the
way
that
we
construct
the
adjoint
is
different
than
the
way
that
we
construct
or
the
cloud
like
the
functions
and
the
properties
that
we
call
is
different
than
the
the
forward
pass
of
the
derivatives
and
or
jbeck,
and
so
when
I
was
going
through
there,
I
just
like
rewrote
things
just
so
that
I
could
understand
it
from
from
my
own
perspective,
and
so
I
and
I
think
that
we
can
get
away
from
having
the
like
adjoint
properties,
as
distinct
from
the
the
forward.
A
I
think
we
can
like
remove
that.
I
think
I
think
it's
a
duplication.
I
don't
know
goodness.
You
have
anything
in
mind
that
triggers
is
like.
I
ran
into
a
whole
bunch
of
problems,
don't
go
down
this
road,
there'd
be
dragons
or
if,
if
it
was
just
sort
of
an
easy,
the
easiest
way
to
get
the
derivatives
first.
G
I'm
pretty
sure
it
was
just
the
it
was
essentially
just
what
was
done
in
the
frequency
domain
code.
At
that
point,
so
I
and-
and
I
think
we
I
think
we
decided
just
given
the
the
fact
that
the
derivatives
given
that
just
the
two
source
problem
kind
of
thing,
I
think
we
decided
just
to
write
it
completely
and
not
optimize
it
at
that
point,
make
it
work
and
then
it
worked
and
then
other
things
took
over
and-
and
I
think
now
we're
just
about
to
optimize
it
so
yeah.
G
G
I
think
I
wrote
like
a
comment
on
every
line,
just
to
remember
like
what
the
how
everything
should
fit
together
just
in
terms
of
like
sizes
and
there's
always
that
comma,
two
or
two
comma,
something
that
makes
it
just
a
little
bit
trickier
yeah,
and
I
mean
I
guess
that
kind
of
goes
for
the
the
the
data
the
receiver
as
well
like.
G
If
I
I
saw
that
you
with
the
apparent
resistivity
I
mean
it,
it
was
just
like
it's
so
much
copy
and
paste
and
there's
just
so
much
code
in
the
receivers
to
do
all
the
different
different
things
that
need
to
be
done
and
they
were
done
that
way
to
just
be
able
to
do
it.
There
was
not
a
lot
of
optimization
that
went
into
it.
So
so,
if
that's
something
people
are
interested
in,
I
would
I
think
that
would
be
worthwhile.
G
A
So
what
I
think
for
a
first
pull
request
with
the
simulation
mt
is,
if
I'll
take,
maybe
one
more
pass
of
the
receiver's
code
and
just
see
if
we
can
sort
of
maybe
have
basically
the
way
that
the
impedances
and
the
apparent
resistivity
and
phase
are
calculated
is
like,
is
just
similar
in
in
flavor,
because
right
now,
they're
they're
both
a
bit
distant
and
that's
fine.
But
I
think
just
having
a
bit
of
consistency
there
and
then
john.
I
don't
know
if
there's
anything
else
on
the
simulation
mt
branch.
B
No,
it's
just
kind
of
some
little
things
like
I
updated
the
edi
loader
gdal
was
just
it
was
just
too
heavy,
so
I
just
went
with
a
lighter
class
and
yeah
just
little
things
like
that.
So
there's
nothing!
Nothing
too
big
right
now,
other
than
the
desk
stuff.
I
guess
the
dash
stuff
hasn't
technically
been
put
onto
master
yet.
A
A
The
other
thing
that
I
think
would
be
useful
to
do
relatively
soon
as
doug
mentioned,
is
kind
of
have
the
block
model
running
just
so
that,
like,
as
we
start
to
refactor
things,
you
know,
if
all
of
a
sudden,
we
do
something
silly.
That
slows
down
the
code
by
a
factor
of
two
we
catch
that
earlier
than
later,
as
well
as
potentially
I
don't
know.
Devin
mentioned
that
there
was
a
good
field
data
set
in
the
gif
tools.
A
Cookbook
doug,
I
don't
know
if
you
have
other
field
data
sets
that
are
like
a
good
reasonable
one
that
we
should
sort
of
just
keep
on
the
list
of,
like
we've
got
a
nice
synthetic
that
we
consider
and
the
in
a
field
data
set
that
we
keep
keep
in
mind.
C
Nothing
actually
off
the
top
of
my
head.
I
mean
we've
seen
a
number
of
them
come
through,
but
this
is
probably
something
that
we
should
think
twice
and
do
once,
and
so
I
think
that's
probably
worthwhile
just
put
it
on
a
very
active
list,
but
not
necessarily
make
a
decision
right
at
this
time.
G
Yeah
I
mean
there
are
a
lot
of
cool
data
sets.
I
mean
the
the
workshops
that
ellen
jones
and
his
group
in
in
dublin
what
that
they
hosted
where
they
kind
of
tested
against
both
the
synthetic
or
yeah
where
it
was
like
testing
again
synthetic
models
we
had
talked
about
trying
to
get,
or
I
mean
you
can
just
download
the
data
and
run
it
just
kind
of
because
most
of
the
codes
that
are
out
there
have
been
run
against
those.
G
G
G
C
A
Yeah,
if
you
have
or
can
dig
up
the
l
block
code,
that
would
be
great
because
I
think
that's
like
a
very
it
seems
like
an
obvious
sort
of
benchmark
that
we
can.
We
can
keep
in
mind
with
first
thank.
B
You
sorry
always
go
ahead,
oh
no!
I'm
just
going
to
say
if
I
do
have
the
l
block
like
notebooks.
Just
I
made
it
myself,
for
I
just
did
one
for
the
pair
of
visitivity
and
phase,
and
I
got
one
for
impedance,
all
the
all
the
components
and
stuff
so
yeah.
I've
got
them
ready
if
anybody
wants
them.
E
Did
you
is
that
the
same
l
model
like
in
the
ubc.
B
I
I
just
took
the
idea
and
just
made
it
up
myself
in
the
in
a
notebook
yeah,
okay,
yeah
devon.
Put
me
on
to
it
and
he's
just
like
here
just
see
how
this
works
and
yeah
I
did
it.
I
didn't
do
like,
like
the
code
comparisons,
just
looking
just
looking
on
the
website
and
then
looking
at
what
I
got
in
the
notebooks
yeah,
everything
seems
like
the
polarities
and
everything
looks
fine.
Yeah
just
haven't
had
a
chance
to
do
a
direct
comparison
of
the
inversion
to
inversion.
A
And
then
I
guess
so
the
other
question.
So
we've
talked
a
bit
about
like
the
source,
receiver
refactor,
but
then
also
sort
of
the
octree
side
of
things.
Joe,
do
you
have
a
sense
of
like
what
we
need
to
make
that
work.
D
A
D
Kind
of
it's
it's
a
weird
thing,
you're
averaging
something:
that's
either
like
okay,
homogeneous,
yes
averaging
something!
That's
like
a
1d
solution
onto
it
is
a
little
bit
less
subtle
and
you
can't
just
use
like
a
volume.
What
you
could
do
is
you:
could
you
could
pad
it
out
to
make
a
1d
mesh?
That's
the
same
exact
extent
of
the
octree
mesh
and
then
the
volume
average
would
work
just
fine.
D
D
That's
my
my
point
is
like
that,
if
you
just
use
the
volume
averaging
it'll,
do
that,
okay,
like
the
volume
average
function,
will
do
that
all
you
need
to
do
is
just
have
a
does
that
kind
of
make
sense.
You
have
a
the
mesh,
however,
you
define
it
going
down
and
then
just
expand
it
out
to
the
same
extent,
and
it
will
do
a
volume
average.
D
D
A
D
D
E
D
D
That's
why
we
need
like
it's
easy
enough
to
do
that:
okay,
okay,
yeah,
I'm
not
talking
about
the
election
like
the
electric
field,
that's
something
else!
I'm
talking
about
the
actual
like!
Oh,
I
synthetic
model
because
you
can
there's
solutions
that
generate
the
electric
field
anywhere,
maybe
even
in
between
layers.
D
A
So
maybe
a
useful
next
step,
because
I
think
I'm
understanding
this,
but
maybe
not
entirely.
Would
you
mind
joe,
like
sketching
out
with
all
the
minds
just
in
in
an
issue
yeah
like?
I
think
I
think
I
understand
but
like
sort
of
if
we
could
see
a
pseudo
code
sketch,
I
think
that
will
hopefully
make
sure
that
we're
we're
all
on
the
same
page.
There
mental
models
are
aligning.
E
D
B
Yeah
with
the
current
empty
code-
yeah
yeah-
that's
that's
exactly
right
breaks.
I
remember
the
error
being
in
the
interpolation.
A
Okay,
so
does
that
give
us
sort
of
like
rough
action
items?
Is
that
we're
working
on
basically
getting
the
sources
and
receivers
cleaned
up
as
sort
of
or
the
receivers
sort
of
cleaned
up
to
a
state
that
we
want
as
a
first
step
and
then
I'm
quite
interested
in
actually
basically
getting
up
and
running
with
the
block
model
and
sort
of
using
that
as
a
bit
of
a
test
case
and
just
making
sure
you
know
as
we
develop,
we
can.
A
We
can
go
from
there
yeah
and
then,
if
joe
was
game
to
sketch
out
the
octree
implementation.
And
then
we
can
sort
of
keep
keep
moving
forward
from
from
there.
B
A
Cool
does
anyone
else
have
other
items?
Does
anyone
also?
I
guess
the
other
item
that
was
lingering
is
sort
of
pushing
on
the
the
2d,
but
that
might
make
more
sense
once
we
got
the
sources
and
receivers
kind
of
fleshed
out.
But
if
anyone
wants
to
start
pushing
on
that,
maybe
just
writing
up
an
issue
of
what
you
plan
to
do
and
we
can
just
because
I
just
want
to
make
sure
that
we
don't
duplicate
efforts
and
so,
if
yeah,
so
we
can
coordinate
on
slack
and
or
issues.
G
So
I
do
have
a
ton
of
examples
and
kind
of
notebooks
and
things,
obviously,
probably
not
in
the
won't
run
currently,
but
at
least
will
give
us
a
good
idea.
Is
there
a
location
that
I
could
put
them
in?
That
is
kind
of
less
intrusive
or
other
people
could
have
a
look
at
them.
A
Let's
maybe
do
a
dropbox
folder,
if
you
don't
mind
because
then
that's
just
something
we
can
all
kind
of
look
at
and
then
we
can
parse
out
which
code
should
maybe
go.
Where
would
that
work
even.
A
Yeah
well
that'll
be
valuable,
that'll
be
really
great
to
see,
because
I
know
you
also
invest
a
lot
of
effort
in
sort
of
the
data
visualization
and
interactive
things
there,
and
so,
if
we
can
revive
revise
some
of
those
things,
that
would
be
excellent.
A
Okay,
well,
we
can
sort
of-
I
guess,
sync
up
with
the
next
simple
meeting
on
brief
updates,
and
then
we
can
always
do
another
one
of
these
if
it
makes
sense
to
sort
of
check
in
specifically
on
the
empty
side
of
things,
cool
all
right
thanks.
Everyone
have
a
good
rest
of
your
friday
afternoon.