►
From YouTube: SimPEG Meeting March 27
Description
Work refactoring the DC code into the new Simulation framework
A
Okay,
so
what
I'm
going
to
do
is
I'm
going
to
share
my
screen
in
just
a
sec
and
we'll
sort
of
look
at
like
what
the
current
status
of
the
simulation
is
and
then
from
there.
We
can
look
at
what
it
takes
to
refactor
DC,
we're,
probably
not
gonna,
get
all
the
way
through
it,
but
it
needs
chatting
through
a
few
of
the
steps.
I
think
would
be
useful,
so.
B
C
D
A
Okay,
so
the
goal
here
being
that,
instead
of
having
the
problem
and
the
survey,
we
then
we
now
replace
that
with
the
simulation
class
and
so
the
simulation,
what
it
has
is.
It's
gonna
have
a
few
things
like
wheat,
bread
in
this
case.
This
is
a
linear
problem.
It
has
a
G
I,
get
J
de
Becque.
All
of
the
things
that
would
be
used
to
have
in
the
problem
class
are
now
in
the
simulation,
and
one
of
the
important
things
in
grits
refactoring
is
the
fact
that
we
can
actually
serialized.
A
Then
here
we
have
the
model
map.
This
is
one
piece
that
we
still
need
to
go
in
and
make
sure
it
can
be
serialized.
So
that's
not
done
yet,
but
then
we've
also
got
things
like
the
number
of
kernels
and
then
a
couple
tuning
parameters
on
what
that
simulation
looks
like
so
here.
If
we
go
to
the
simulation,
he
said:
okay,.
E
A
That's
a
good
point
dong
and
yes,
we
can
absolutely
do
that,
so
that
is
just
a
function
then
of
how
we
choose
to
serialize
it.
So
we
can
customize
that
piece
and
what's
kind
of
nice
is
like
this
should
sort
of
be
forward
compatible
of
innocence
of
like
what
we
currently
do,
and
if
we
actually
decide
to
write
things
to
a
more
compact
form,
there
shouldn't
be
any
conflict
that
should
all
be
ended.
A
So
one
example
of
that
I
can
show
you
Rowan
gave
me
a
snippet
here
because
to
serialize
the
solver.
So
here,
if
you
look
at
the
the
solver
which
we
project
set
yet
yeah,
so
we
haven't
said
that,
but
the
solver
actually
is
a
class,
and
so
that
wasn't
like
a
built-in
property
in
the
properties
library.
So
at
first
we
didn't
know
how
to
serialize
it.
The
only
thing
that
you
actually
need
is
the
name
of
the
the
solver
and
the
class.
So.
A
Okay
and
then,
if
we
serialize
that
sorry,
then
here
what
we've
done
is
we've
said
the
class
is
parody,
stove,
it's
coming
from
the
pine
mountain,
solver
module,
and
it's
this
version,
and
so
here,
if
we
actually
look
at
the
code
that
was
all
specified
by
this
to
JSON,
and
so
we
actually
have
access
to
how
any
of
the
properties
serializes
does
that
make
sense.
Don't.
A
Okay,
let's
then
take
a
look
at
perhaps
just
we'll
do
a
quick
review
of
p.m.
because
that
sort
of
been
refactored
and
then
we'll
jump
to
like
what
needs
to
be
done
in
DC,
so
IAM
what
I've
done
just
because
this
is
such
a
big
restructuring
it.
I
didn't
want
to
just
delete
the
code
which
are
the
overriding
stuff
as
we
go.
Cuz
I
want
to
be
able
to
test
both
versions
at
once,
so
the
previous
code
is
in
old,
FDM
or
old
TDM
and
then
the
newer
stuff
is
in
FTE
m14.
A
A
So
that
hasn't
like
these
are
fairly
straightforward
changes.
If
we
look
at
the
fields,
one
of
the
things
that
changed
is
now
how
we
access
any
of
the
I
guess
properties
of
the
the
simulation.
So
this
used
to
you
know,
take
the
survey
and
then
we
would
access
everything
through
the
survey.
Now
the
fields
object
is
set
up
and
instantiated
with
a
simulation.
A
A
A
A
So
what
we
want
to
do
is
we're
going
to
inherit,
I,
guess
the
the
base
BM
simulation
and
that
actually
comes
with
Sigma
and
mu
for
DC
muse
not
needed,
but
it
still
is
relevant
to
ET
a
problem.
So
it's
still
going
to
be
attached
there.
That's
something
to
think
about
in
the
future.
If
we
actually
want
to
trim
that
down
a
little
more
so
here
we're
going
to
import
from
up
two
great
one
to
face.
A
F
A
So
in
this
survey
here
I
put
the
base
iam
source
because
it
needed
access
to
that,
but
the
survey
is
actually
quite
lightweight,
so
it
takes
just
a
source
list
and
then
here
for
the
frequency
domain,
it
had
a
few
handy
things
like
get
sources
to
buy
frequencies
on
top,
but
we
don't
actually
need
that
for
the
DC,
the
DC
is
a
little
more
lightweight
later
on.
We
can,
you
know,
implement
stuff
to
get
survey
lines
and
things
like
that.
But
for
now
we
will
keep
it
quite
true.
A
A
A
A
The
names
of
these
is
something
I
think
we
should
think
about,
because
this
statement
of
survey
geometry
like
to
me
I,
immediately
think
jockle
dipole-dipole
whatever.
Where
is
it's
really
more
a
statement
of
actually
what's
the
type
of
model
like?
Is
it
a
half
space?
Are
we
getting
it
from
the
circuits
from
a
horrible
or
something
a
little
more
general?
But
that's
okay,
we'll
leave
it
as
is
for
now,
and
then
here.
A
A
They
secure
what
I
did
in
the
e/m
cases
we
were
expecting
or
the
frequency
domain
eeeh.
We
were
expecting
a
list
of
frequency
domain,
TM
sources,
so
in
this
case,
what
we're
going
to
be
expecting
something
similar
but
it'll
be
DC
sources.
Here,
we've
got
our
swords
list
and
then
these
will
be
based
torts
instances.
So
this
would
be
a
DC.
A
A
Here
in
the
units,
one
thing:
that's
important,
that
simplifies
things
quite
a
bit
is
now
everything
is
a
keyword
argument.
So
in
this
case,
what
that
means
is
that
the
source
list
needs
to
be
set
as
a
keyword
argument.
So
previously
we
would
have
created,
could
have
created
a
survey
and
just
input
a
list
as
the
first
argument.
D
A
A
The
rest
of
this
it
looks
like
can
basically
come
over,
but
I'm
not
going
to
do
that
right
now,
because
I
think
there's
pieces
of
this
that
need
to
be
thought
through
a
little
bit
and
I
don't
actually
know
if
they
should
be
existing
on
the
survey
or
as
utilities
for
the
survey.
So
that's
that's
a
question
for
later.
A
A
A
A
I'm
here
this
J
matrix
doesn't
actually
need
to
be
a
property,
because
we
don't
want
to
serialize
it.
You
only
want
to
serialize
the
instructions,
basically
to
recreate
the
class.
So
if
we
were
going
to
try
and
run
a
simulation
in
parallel,
we
don't
actually
want
to
be
serializing
and
sending
around
the
storage
J.
We
just
want
to
save
the
instruction
that
says
when
you
are
computing
storage.
A
so
then
here
we'll
need
to
admit.
A
A
A
A
A
A
That's
this
is
actually
something
interesting
and
I
didn't
appreciate
this
before,
but
this
could
actually
sit
on
the
face
simulation
right,
because
all
of
these
pieces
are
identical
for
a
frequency
domain
and
for
a
DC
simulation.
So,
instead
of
necessarily
rewriting
this
here,
we
can
just
put
this
on
the
base
class.
That
makes
sense
when.
A
A
A
So
one
of
the
things
this
interesting
here
service,
an
interim
step,
is
we're
actually
using
this
synthetic
data
class.
So
you
we
used
to
actually
use
the
data
class
to
construct
this
just
for
ease.
I
made
one
small
distinction
between
the
synthetic
data
and
the
data,
and
this
is
something
to
chat
about,
but
with
data
once
you've
read
it
in
once,
you've
set
your
data
I,
don't
let
you
change
it?
A
B
B
C
Guess
that's
I
can
like
do
a
lot
of
like
writing,
yeah
and
I'm.
Just
thinking
of
one
of
the
thing
right
now
is
that
if
you
actually
want
to
create
I
can
know
the
data
set
with
another,
do
people
do
other
I,
don't
know
like
like
Mike
a
lot
of
synthetics
and
with
different
model
and
etc?
Is
it
possible
that
you
have
a
data
object
and
you
like
recruit
like
a
clone
with
the
stems
with
the
same
surveys,
etc?
But
the
herbs
like
not
a
sign
of
different
yeah.
A
C
A
A
A
F
Good
to
data
vectors,
you
could
read
in
yep,
could
you
set
one
and
be
like?
Oh
no,
like
there's
some
reason.
That's
not
the
one
I
want
I've
associated
with
this.
You
set
a
new
one
over
the
top
of
it
or
give
to
like
delete
clear.
The
whole
data
structure
object,
Riaan
Stan.
She
ate
a
new
one
and
reset
it
so
right
now
you
just
need
to
create
anything
which.
C
A
C
C
G
D
G
A
F
Additional
information,
instead
of
just
like
the
observed
like
the
measured
potential
difference
and
the
uncertainty
information
like
say
we
add
inject
like
current
for
each
your
current
injected
current
value
or
potential
value
that
was
also
measured
for
each
one.
So
you're
not
going
to
be
like
using
those
directly.
E
F
Ones
to
decide
how
you're
setting
your
uncertainties,
maybe
or
which
portions
of
your
data,
if
you're,
keeping
or
things
like
that,
so
at
least
I
have
found
I've
used
all
those
things
kind
of
in
the
same
context
and
in
the
same
way,
so
it
was
handy
to
have
them
in
the
same
place.
So
it
might
be.
It
is,
but
it
might
be
convenient
to
be
able
to
have
that
David
plans
would
be
flexible,
and
so
you
kind
of
add
so
thick.
F
A
A
Simple
data
structure,
very
Lunt,
I
think
perhaps
what
you're
referring
to
is
much
more
something
like
pandas
and
actually
using
a
data
frame
and
I
think
that
the
calving
utilities,
Rusted
interface
from
a
Penn
Stater
into
creating
a
simple
data
object.
I
think
that
sort
of
workflow
would
be
quite
powerful,
but
I
think
that,
at
least
within
the
scope
of
what
the
data
class
does
in
the
code,
we
want
to
keep
it
light,
weight
and
tailored
for
that
purpose.
A
A
G
C
C
F
Like
the
data
class
or
the
data
object,
it's
going
to
have
all
of
these
methods
associated
with
it
that
it
can
use
to
then
index
or
somehow
manipulate
the
data
in
the
data
object.
So
is
there
going
to
be
a
way
that
we
can
then
port
all
those
utilities
over
to
be
able
to
act
on
any
of
the
data
in
its
pandas
database,
or
are
we
gonna
have
to
rewrite
all
of
that
functionality?
Now.
A
So
I
think
what
the
way
to
do
that
is.
Then
you
write
whatever
method
it
is
can't
easily
if
we
want
to
go
in
and
grab
by
pools
by
Pikeville
space
in
true
write
that
as
a
utility
that's
attached
to
a
class
and
then
that
sent
something
that
you
can
attach
it
to
the
class
like
attach
it
to
the
data
class
in
a
way
that
it
makes
sense
with
working
with
the
data
class.
And
then
you
can
provide
the
correct
inputs
when
you're
working
with
appendices.
A
H
H
A
There's
two
ways:
you
can
work
through
that
right
now:
listen
peg,
one
thing
that
you
can
do,
but
if
you
know
that
you're
only
going
to
be
working
with
a
subset
of
the
data,
then
just
pull
that
out
and
create
its
own
data
object.
If
you
potentially
want
to
start
an
inversion
where
you're
inverting
I'm
going
to
switch
to
frequency
domain
area
MT.
Just
because
that's
the
example
in
my
head
but
say
you
want
to
start
with
high
frequencies
and
then
add
low
frequencies
as
the
inversion
for
us.
H
H
B
C
C
A
A
So,
okay,
so
we've
got
no
like
the
sketch
or
like
based
DC
simulation.
So
then
we're
gonna
make
sure
that
we
can
inherit
inherit
that
for
these
specific
simulations
right
so
for
the
self-centered
or
for
a
no
role
simulation,
so
that'll
be
a
next
step
following
that.
We
then
also
need
to
go
in
and
update
the
fields
objects,
and
so
one
of
the
things
that's
worth
pointing
out
is
the
way
I'm
instantiating
fields.
A
A
They
they
go
through
this,
and
so
because
what
I've
done
here
is
we're
gonna,
actually
go
in
and
be
able
to
check
and
make
sure
that
the
known
fields
and
the
alias
fields
they
exist
on
valid
grid
locations.
So
here
we
can
actually
go
in
and
provide
some
sanity
checks
and
basically
say
like
hey.
The
gnome
fields
need
to
exist
on
either
like
edges,
cell
centers
notes
or
whatever,
and
so
we
can
do
all
of
that
sanity
checking
on
the
base
class
and
don't
actually
need
to
implement
it
anywhere
else.
A
E
A
A
A
Yeah
this
thing
that
I
think
we
need
to
be
very
careful
with
when
we
distribute
Garber's
is
like
not
to
obscure
the
decisions
that
have
been
made
because
I
think
what's
happening
in
in
John's
case.
Is
it's
just
not
clear
what
beta
is
being
used?
What
alphas
like
all
of
those
kinds
of
things,
and
so
in
a
lot
of
ways
like
if
there's
a
useful
sort
of
inversion
driver
that
you've
written
for
yourself
to
you,
know
batch
tools.
A
bunch
of
synthetic
conversions.
A
I
would
recommend
that
you
put
that
in,
like
your
own
research
repository
and
really
focus
on
bringing
in
utilities
that
are
general
more
so
in
two
simple,
because
I
do
think
that,
like
distributing
something
that
obscures
the
decisions
is
potentially
dangerous
like
it's
fine.
If
you
write
that
for
yourself,
because
you
know
what
decisions
you've
made
in
like
where
things
are
baked
in,
but
it
is
yeah
just
something
to
be
honest
enough
and
I
think
in
a
lot
of
ways.
If
we
keep
things
close
they're
like
I,
think
the
drivers
gone
like
great
we're
really.
E
A
G
E
That's
for
that
being
said,
though
I
we
were
talking
about
it
before
right.
We
should
maybe
say
realized,
oh,
so
that
we
can
easily
maintain
the
drivers,
because
the
issue
with
with
Craig
and
I
is
that
every
time
we
change
a
base
code
then
needs
to
change
all
the
all
those
drivers
again.
So
it's
just
hard
to
maintain.
Like
scripts,
you
mean
yeah.
A
E
E
F
A
Maybe
just
quick
in
other
updates:
let's
maybe
take
a
quick
look
at
pull
requests
and
just
see.
Is
there
anything
super
vintage
to
that?
I
would
like
to
bring
in
fairly
soon
so
on
dis,
critize,
there's
the
3d
cell
mesh
and
then
in
simp.
This
guy
follows
closely:
it
includes
a
whole
bunch
of
upgrades
to
the
time-domain
code
actually
and
a
few
typos
fixes.
A
C
A
C
Like
your
implementation,
but
there's
nothing
really
fun.
So
we
still
like
all
of
us,
Joe
and
I,
which
we
still
get
a
warning-
that
something
is
pretty
definitive
in
how
we
do
the
big
detail,
the
little
stuff
so
I
was
thinking.
Maybe
I
can
use
the
same
branch
and
for
requests
to
actually
fix
that
one.
Okay,.
E
D
D
A
So,
for
example,
like
pieces
in
the
mappings
class,
early
quite
transferable,
to
other
codes
like
I,
could
see
that
being
useful
in
PI
Yemeni,
for
instance,
but
right
now
it's
not
useful
to
them
because
it
is
tied
up
in
the
same
thing.
So
it's
just
not
transparent.
What's
going
on
there,
so
I
think
like
having
a
bit
more
modularity
in
that
case
is
it's
better.
It
does
mean
that
people
have
to
get
a
little
more
comfortable
with
you
know,
maintaining
multiple
repositories
and
like
managing
branches,
and
things
like
that.
A
Yeah
and
like
I
think
what
would
be
nice
is
to
sort
of
go
towards
the
way
that
Jupiter
distributes
so
a
maintain
all
of
their
stuff.
You
know
a
whole
bunch
of
different
repositories,
but
then,
when
you
install
Jupiter,
you
get
all
of
it,
and
so
in
this
case,
ladies,
you
know
we
can.
We
can
follow
something
similar
in
where
we
break
up
all
of
the
code.
But
then,
if
you
want
everything,
then
it
should
be
just
one
install
step.
So
all.