►
From YouTube: subsurface catch-up I
Description
First catch-up meeting since Transform2020/gostin.
A
B
C
C
C
A
bit
on
design
ideas
and
then
I
also
started
to
to
change
the
whole
structure
of
the
package.
So
today
today
would
be
cool
if
we
agree
a
bit
on
the
more
high
level
ideas
of
what
this
package
should
be
and
also
more
into
the
detail.
If
the
structures,
the
data
structures
that
I
have
in
mind
and
the
different
levels
of
abstraction
make
sense
for
everybody
or
or
someone.
C
C
Yeah,
okay,
so
very
general
basic
thoughts
that
I
was
just
writing
when
I
started
to
work
again
in
this
a
couple
of
weeks
ago.
So
the
idea
of
this
is
just
having
this
data
hub
for
scientific
geoscientific
data
in
in
python,
so
two
main
purposes
unified
geometric
data
that
most
of
the
libraries
understand
at
the
moment.
Each
of
these
libraries.
C
C
So
a
couple
of
ideas
of
the
libraries
that
I'm
having
in
mind
and
actually
I'm
using
and
so
for
input
output
segwyo
for
for
seismic
willie
is
the
one
welly
and
striplock
for
the
porthole
data,
raster
io
for
cloud
points
and
these
things
for
visualization
at
the
moment,
I'm
using
mainly
by
vista.
But
I
can
imagine
that
we
could
have
also
multiplied
for
the
2d
and
then
this
is
a
one
of
the
main
things
that
we
have
to
discuss
today.
C
It's
really
just
used
numpy
array
always
for
memory
allocation,
so
if
we
want
to
put
labels
to
those
numpy
arrays
using
data
frame
and
xray
for
attributes-
and
things
like
this
and
this
being
the
the
main
constructor
of
what
I
call
primary
structures
so
so
far
is
yes
and
structured
data
and
structured
data,
and
I
can
show
you
later
a
bit
what
this
are
made.
But
these
are
really
as
numerical
data
and
using
that
numerical
data
to
go
already
to
some
type
of
geometry,
that
I'll
call
elements.
C
So
these
are
more
something
that
vtk,
for
example,
can
understand
and
we
can
plot
easily
with
by
vista
and
then,
if
we
want
to
go
a
step
further,
we
can
just
go
to
java
objects
so
how
those
geometries
they
create,
actually
faults
or
or
seismic
lines
or
bringing
already
a
geology
concept
to
the
geometries
and
beyond
that.
If
you
want
to
add
from
which
warhol
is
is
coming
the
who
made
the
interpretation,
we
will
really
need
to
embed
all
of
these
in
in
data
structures
that
they
contain
a
lot
of
strings
and
metadata.
C
But
here
I
guess
that
is
where
omf
and
this
these
ideas
come
into
play
so
said
that
so
far
I
built
this
and
structured
data
that
is
composed
by
three
attributes:
vertex
with
the
xyz
data
edges
that
connects
the
vertex
depending
on
the
size
of
the.
So
how
many
columns
the
edges
has
is
going
to
be
either
point
cloud
lines
triangles
or
volumetric
elements
and
then
assign
attributes
to
those
edges
at
the
moment,
so
those
elements
that
they
are
connect.
C
D
C
And
and
they've
got
the
zero
one,
but
yes,
that's
not
used
okay,
but
those
are
details
of
implementation.
But
yes,
I
I
want
it
to
exist,
because
I
wanted
to
be
as
consistent
as
possible
for
all
the
the
type
of
of
data
structures.
But
yes,
in
that
case
we
wouldn't
use
so
could
be
yes,
the
indices
say
yes
from
one
to
n.
C
Yes
and
from
the
structured
data
just
make
an
x
array
same
idea,
so
if
it's
2d
will
be
structured
surfaces
if
it's
3d
these
structure
grids
and
then
the
special
case
of
a
uniform
grid
that
can
be
as
defined
by
by
the
extent
and
the
resolution,
because
the
type
size
is
the
same
yeah.
So
what
do
you
think
of.
D
E
Any
chance
mikwell,
you
think
we
could
attach
some
some
attributes
to
to
a
primary
structure.
I'm
just
thinking
it
would
be
so
awesome
if
we
could
have
if
we
could.
As
a
group
define
you
know,
a
set
of
keyword,
arguments
that
are
that
are
reserved,
for
instance,
I
don't
know
just
like
I
don't
know,
color
map
right.
I
could
attach
a
color
map
to
a
to
a
primary
structure
that
by
vista
would
see,
and
then
you
would
pick
it
up
and
plug
it
with
the
right
color
map.
C
Very
close,
yes,
so
my
idea
is
yes,
leaving
primary
structures
just
with
numerical
data
and
then,
if
you
want
to
add
more
like
exactly
what
you
have
said,
you
go
up
into
the
pilot
and
you
just
compose
a
primary
structure
within
an
element
or
within
a
geological
format,
or
something
like
that.
But
by
using
composition
for
that.
So
yes
really
leaving
primary
structures
as
it
is
that
you
may
call
data
and
if
you
want
to
add
metadata,
just
create
a
class
that
one
of
the
properties
is
a
primary
structure.
F
One
of
the
issues
you
run
into
is
metadata
that
that
I've
sort
of
seen
rear
it's
its
head
and,
for
example,
well
log
data.
So
I
think
welly
has
a
big
dictionary
of
of
what
you
know.
Gamma
ray
can
be
called,
for
example,
so
there's
capital
gr,
there's
little
gr,
there's
gamma
underscore
ray,
there's
gamma
space
right,
it's
just
the
list
goes
on
and
then
gamma-ray
final
gamma-ray
final
final,
like
gamma-ray,
clip
final,
but
you
know
that
sort
of
thing
so.
C
F
Yeah,
it
gets
so
there's
a
nsf
initiative,
that's
called
strebo
or
strabo.
I
don't
actually
know
how
to
pronounce
that,
but
they
have
an
app
and
it's
to
collect
field
data.
It's
like
outcrop
data
and
it
started
out
being
structural
measurements.
So
you
know
you
would
have
a
lat
long
point
with
you
know,
strike
and
dip,
and
you
know
a
photo
or
something
like
that
and
they're
trying
to
take
it
into
sedimentary
graphic
logs
now
right.
F
So
like
a
core
description,
and
it's
super
messy
right,
because
everyone
wants
a
different
scale
and
everyone
wants
a
different.
You
know
format.
Some
people
are
going
to
carbonate,
some
people
are
looking
at
classics,
and
so
it
gets
really.
It's
not
a
simple.
You
know
this
sort
of
geological
format
right
like
well,
you
know
what
do
you
even
for
something
simple,
like
a
fall
right
I
mean
there's,
there's
even
a
lot
of
I
mean
I
guess
that's
kind
of
what
we
need
to
do
right.
We
need
to,
but.
C
But
maybe
that
and
it's
true
that
this
I
mean
graph,
which
is
obviously
a
graph,
doesn't
represent,
but
my
idea
a
bit
is
having
it
like
an
inverse
pyramid,
where
the
only
thing
that
we
are
going
to
be
able
to
agree
is
to
the
level
of
structured
data
and
structured
data.
Those
are
really
concepts
that
doesn't
matter
what
you
build
on
top
is
the
same
as
we
are
building
or
moving
upwards
closer
to
a
human
understand
or
readable
format.
C
So
so,
instead,
just
having
several
independent
formats
that
they
built
the
whole
stack
themselves
just
trying
to
at
least
agree
on
the
basis,
and
once
you
just
go
from
from
numpy
array
to
a
representation
of
a
line
and
using
the
line
to
represent
a
porthole
and
then
the
boreholes
represent
a
data
set
that
is
going
to
diverge
and
then-
and
that's
I
don't
know
if
it's
going
to
be
part
of
some
surface
or
or
those
libraries
should
import
subsurface.
That's
a
bit
a
question
for
for
someone
as
dominic.
E
I
think
the
packages
should
adapt
to
to
to
what
we're
doing
here.
This
should
be
the
the
basis,
and
we
just
have
writers
on
our
app
on
each
other's
side,
to
be
able
to
understand
what
those
what
those
structures
are.
If
we're
talking
about
here,
creating
a
common
common
structure.
This
should
be
it
right
and
then,
because
we're
it's
going
to
be
much
harder
to,
I
think,
connect
all
our
packages
reformat
our
packages
to
all
agree
with
each
other.
We
should
just
be
doing.
C
H
H
You
can
read
in
the
the
numbers
and
everything,
but
then
there
still
needs
to
be
some
level
of
cooperation
above
your
primary
structures
in
order
to
say:
okay,
well,
you
know
pie,
gimli
is
only
I
mean,
maybe
pie,
gimli
doesn't
give
us
lines,
but
it's
giving
us
this
this
and
this
and
then
when
genpai
reads
it
in
it
needs
to
know
how
to
deal
with.
You
know
some
sort
of
a
line
coming
in
from
sub-surf
or
whatever
we
call
it.
Yes,.
C
We
we
are
going
to
need
to
to
write
custom
objects.
The
only
question
is,
we
could
just
use
anything
any
numerical,
so
any
numpy
array
in
any
format
and
just
create
this
object.
That
is
how
we
communicate,
and
by
gimli
and
gempio.
We
can
really
try
to
to
follow
a
bit.
This
idea
of
okay,
first
of
all,
it's
a
structured
data
or
is
unstructured
data.
If
it's
unstructured
data,
it's
a
line,
it's
a
triangle
is:
is
it's
a
hero?
C
E
That's
why
I
have
the
feeling
that
if
we
just
have
we're
just
allowed
to
attach
dictionaries-
and
then
we
know
that
let's
say
pygamily
can
accept
some
attribute
on
on
a
curve
object.
Then,
when
you
pass
this
this
attribute
to
the
curve
object
through
through
through
this
library,
then
you
know
what's
going
to
happen
right.
How
can
other
libraries
can
handle
this?
I
think
we
kind
of
need
to
have
this.
E
I
C
C
C
D
In
some
senses,
maybe
one
way
to
reason
through
this
is
also
perhaps
just
starting
from
actually
the
user
perspective
and
so
not
necessarily
worrying
about
where
we
are
in
the
in
the
stack.
But
I
could
see
like,
as
a
user
reading,
in
a
geo
gh5
file
and
having
either
the
option
to
read
in
sort
of
like
everything
and
basically
have
the
metadata
in
sort
of
a
dictionary
bucket
like
what
dom
has
suggested
and-
and
perhaps
that
is
a
higher
level
object.
D
Where
we
basically
have
you
know
unstructured
data
plus
meta
and
then
the
meta
is
then
we
maybe
have
you
know
a
handful
of
lightweight
methods
and
maybe,
as
a
first
pass.
It
just
is
a
dictionary
and
we
can
figure
out
if
there's
more
complex
data,
we'll
figure
that
out
later,
but
having
having
that
separation
there.
Where,
as
the
user
I
define
like,
I
just
want
the
bare
basics.
D
C
Do
five
q
h
five
pi
could
just
take
the
dictionary
and
parse
it
so
instead,
just
having
to
read
file,
maybe
subsurface
can
do
the
the
from
file
to
python
to
a
python
dictionary
a
step,
and
that
is
attached
to
the
primary
structure.
And
then
you
can
just
take
that
primary
structure
and
then
you
don't
need
to
have
the
function
that
is
capable
to
read
gocat,
because
it's
already
a
dictionary,
maybe
in
super
weird
format,
but
that
I
like
that.
I
like
a
lot.
E
B
C
C
C
C
They
have
huge
header
with
information,
and
it's
not
tabular
data,
so
something
as
well
is
is
very
good.
Well
well.
Well,
it
last
io
and
well
is
using
last
io,
it's
very
good
at
just
taking
that
header.
That
has
a
pretty
bad
format
and
yes,
it
parses
in
several
dictionaries,
not
only
one,
but
that
is
already
very
specific
use
case.
C
B
H
But
you
know,
if
we're
trying
to
build
interoperability,
it
would
be
nice
if
you've
run
something
through
welly
and
that's
past
your
head,
your
head
is
for
you,
it
would
be
nice
if,
even
if
that
is
then
just
you
know
a
dictionary
with
the
string
being
a
dictionary
already
or
multiple
dictionaries,
then
when
you
read
it
into
something
else,
you
read
the
header
and
go.
Oh
there's
a
bunch
of
dictionaries
here
and
you
can
just
pull
that
out
in
I
don't
know.
What's
going
to
use
a
gen,
pi
say.
C
C
But
the
most
important
thing
in
my
opinion
is
that
any
function
that
reads
two
sub-surface:
it
should
create
one
structure
or
unstructured
data,
but
all
the
rest
is
is
a
optional
stuff.
So
if
you
use
a
different
library
and
you
create
an
object
that
could
be
interested
cool,
but
if
not,
but
that's
why.
I
think
that
the
input
output
should
happen
to
in
a
pretty
low
level,
to
just
be
able
to.
C
C
E
C
C
I
will
create
a
function
in
general
that
is
able
to
read
and
extract
and
structure
data
and
create
gem
by
structures
out
of
that
and
the
other
way
around
for
the
output.
So
the
output
of
genpay,
for
example,
normally
structured
data.
If
you
have
a
box
sale
with
a
boxer
box
with
with
properties
per
cell,
then
would
be
jumped
by
two
subsurface,
which
would
be
an
I
structured
data
and
then
from
there.
We
could
export
it
to
different
formats.
That
is.
H
Just
a
quick
question
there
you
said
that
that
should
be
able
to
that.
The
unstructured
data
is
basically
what
everything
needs
to
do.
Are
you,
including
libraries
that
are
inherently
more
structured?
So
you
know
if
something's,
I'm
thinking
of,
for
example,
verde
which
does
a
lot
of
gridding.
So
you
end
up
with
gridded
regular
structures,
yeah.
H
C
C
C
C
B
B
B
C
C
The
interfaces
which
I
wrote
in
the
in
the
readme
that
technically
are
not
necessary
because
in
principle
is
the
other
libraries,
the
ones
that
they
are
pulling
and
pushing
to
sub-surface
and
not
sub-surface.
So
so
we
shouldn't
have
from
sub-surface
to
jump
by
in
the
subsurface.
It
should
be
jumped
by
the
one
who
is
written
from
sub-surface.
But
in
any
case
just
in
case
I
create
the
folder
here
and
the
visualization
and
visualization
at
the
moment
is
just
by
vista.
C
B
Now
payne,
because
you
commented
there
on
the
on
the
pr
of
joe
and
in
the
discretized
library,
would
it
be
sensible
to
have
here
a
discussion
about
like
an
numpy?
Has
this
d
type-
and
I
don't
know
if
here
it
would
be
an
in
this
case.
I
thought
about
m
type
for
mesh.
But
then
it's
not.
Everything
is
a
mesh
and
subsurface,
but
some
attribute
that
every
object
has
that
distinguish
it
very
clearly
something
like
d
type
but
for
subsurface.
Have
you
thought
about
something
like
this.
J
B
J
A
really
good
idea-
and
I
guess
really
where
that
gets
incorporated-
is
when
you
go
into
the
next
level
above
those
base
structures.
So
when
you
start
having
like
triangulated
surface
as
a
class
and
things
like
that,
and
so
that's
sort
of
what
I
equate
as
the
mesh
type
right
is
keeping
it
really
general
like.
Is
it
a
triangulate
service?
Is
it
tetrahedralized
volume?
C
A
C
C
So
so
I
don't
know
what
one
thing
I
really
see
of
this
library
in
general
and
these
ideas
that
we
we
have
been
discussing
today
is
that
they
are
pretty
independent
to
each
other,
which
I
think
that
makes
collaborating
this
library
relatively
easy.
So
import
and
export
to
these
basic
data
structures
are
completely
an
independent
project
that
doesn't
have
to
to
deal
with
the
core
plotting
same
story,
even
creating
your
own
type
of
of
elements.
C
If
you
want
to
just
do
a
combination
of
of
triangular
mesh
and
with
squares
or
whatever,
you
just
create
a
new
object
that
is
based
on
the
primary
data
structures
and,
and
that
doesn't
disturb
anybody.
So
so
so
the
good
thing
of
this
is
that
it's
not
to
entangle
any
function
with
any
other
function,
so
I
think
that
could
make
so
so
the
main
thing
is
having
it
central.
I
said
that
when
someone
wants
to
write
a
function
to
read
some
format
instead,
just
making
its
own
function,
they
decided
to
do
it
in
here.
B
E
The
so
just
a
greater
plan
are
we:
are
we
going
to
implement
ios
here,
or
are
we
just
going
to
leverage
the
ios
from
other
libraries
right
because
we're
not
going
to,
for
instance,
segue
right?
You
add
segway
io
like
we're
not
going
to
rewrite
this
here
here.
So
what
are
we
doing
with
all
the
other
file
types.
C
E
E
F
F
It
out
it's
going
to
make
people
super
uncomfortable,
and
so
I
you
know
I
that's
just
that's
just
the
way
you
know
they
want
to
know
the
names
of
their
faults,
for
example,
or
you
know
whatever,
and
so
that's
yeah.
I
think
it'd
be
interesting
to
to
think
about
some
use
cases
for
this,
like
from
from
specific
data
type
seismic
data.
F
I
I
One
of
the
things
that
we
learned
from
omf,
like
the
first
version
right,
I
think,
like
three
things
was
and
like
one
of
the
things
that
dom
you
said
like
when
miguel
brought
up
the
visualization
is
that
the
first
time
you
said
like
that's,
going
to
save
me
a
ton
of
work
and
that's,
I
think
what
we
want
to
like.
That's
what
we
want
to
aim
for
is
people
actually
using
this.
H
H
F
Yeah
and
that's
where
that
sort
of
pyramid
miguel
you're
saying
that,
like
that's,
where
it
starts
to
blow
up
right,
because
then
everyone
has
a
different
schema
and
a
different
hierarchy
about
how
they
do
things,
and
it
just
is
too.
We
definitely
don't
want
to
get
build,
use
cases
for
all
of
that
kind
of
stuff,
because.
C
B
Also
think
you,
we
can't
even
define
all
the
possibilities,
and
that
will
be
even
though
we
are
a
very
broad
community
and
that
will,
but
then
that
will
depend
from
one
community
to
another.
So
the
ones
that
do
gravity
might
say.
Oh,
we
need
this
or
that
attribute.
But
if
you
have
addict
and
they
can
agree
within
them
amongst
them
that
this
attribute
is
called
like
this,
then
they
can
write
it
to
and
read
it
to,
and
the
u.s
subsurface
don't
even
have
to
define
that
in
a
way.
E
Yeah,
we're
not
trying
to
merge
packages
here
right,
we're
just
trying
to
pass
information
easily
from
one
to
the
other.
You're
still
gonna.
Have
your
package
you're
still
going
to
be
in
really
doing
your
processing
of
you
just
you
want
to
be
able
to
send
something
to
vtk,
to
see
it
or
send
something
for
forward
modeling
right.
C
I
I
agree.
Maybe
then
the
better
way
to
put
it
is
it's
more
about
the
documentation.
So
it's
not
so
much
about
merchant
libraries,
as
you
said,
but
maybe
really
merging
or
centralize
some
examples
in
the
subsurface
package.
But
if
someone
go
to
the
subsurface
documentation,
they
can
say
how
to
import
something
from
subsurface
and
directly
just
put
it
in
in
gh5
and
then
do
whatever
they
want
to
do
with
that.
F
H
B
G
F
The
the
more
I
think
about
it,
you
know
what
what
what
dominic
was
saying
about.
You
know
just
like
just
transfer
some
snippets
back
and
forth.
I
mean
that's
the
the
biggest
hurdle
going
from,
for
example,
petrel
into
python
or
patrel
into
kingdom,
or
you
know
whatever,
like
working
as
a
right
there,
there's
no
like
how
do
you
read
an
eclipse
file
like
right
like
or
segway
data
is
like
the
patrel
loader
and
segway
is
awful.
It's
just
like
the
worst,
so
so
anyways
they're
like.
F
F
Maybe
you
don't
want
to
do
that,
but
but
there's
a
bunch
of
little
pieces
like
oh,
get
a
petrol
file
into
a
you
know
into
some
type
of
array
or
there's
all
kinds
of
those
little
snippets
kind
of
sitting
out
on
github
and
everyone's
libraries
and
they've
all
and
they've
all
been
done
like
12
different
times
right,
because
someone
can't
find
it,
and
so
they
recode
it.
And
it's
like
three
days
worth
of
work
so.
C
And
it's
difficult
because
many
times
you
need
to
do
a
couple
of
manipulations
to
input
data
very
specific
to
each
case.
So
so
yes
create
a
function
that
is
read
x.
That's
going
to
be
really
a
big
challenge
for
all
of
us,
but
at
least
knowing
that,
if
you
add
some
specific
code
that
maybe
you
can
just
put
it
somewhere
and
build
something
bigger
that
yeah
that
that
doesn't
get
close.
So
so
my
whole
goal
with
this
is
trying
to
create
a
place
where
we
can
just
write
those
interactions
and
they
don't
get
lost.
E
Without
increasing
the
dependencies
right,
we
go
you
don't
want
to.
We
don't
want
to
increase
the
the
requirements
too
much
either.
So,
how
do?
How
are
we
going
to
be
able
to?
I
totally
agree
with
you
zayn.
It
would
be
awesome
to
have
like
a
repository
of
like
small
snippets
of
stuff,
but
how
do
we
do
it
without
increasing
our
our
dependencies
too
much
my.
H
C
But
that's
the
goal.
So
if
we
really
start
building
up
in
a
clever
way,
maybe
in
five
years
we
are
able
to
have
subsurface,
read
and
point
into
a
file
and
that
works
and
seems
crazy,
but
with
panda.
Sometimes
you
have
that
feel
that
that
feeling
that
you
just
point
somewhere
and
suddenly
they
are
able
to
read
it.
And
it's
because
of
so
many
iterations
of.
G
Yeah,
yes,
and
what
you?
I
also
think
that
what
lindsay
said
that,
from
a
user
perspective,
it
would
be
nice
to
have
this
yeah
high
level
object
with
also
the
metadata.
I
think
it's
also
very
similar
from
a
feeling
to
a
panda's
data
frame
where
you
have
this
fully
fledged
object
with
all
the
imports
and
exports
methods
available
to
at
your
fingertips.
But
then
you
can
still
do
the
dot
values
and
get
the
numpy
array
below
it.
G
C
C
So,
gem
by
and
by
vista,
they
communicate
at
a
very
low
level
because
they
are
super
similar.
But
if
you
really
want
to
do
seismic
interpretation,
maybe
you
need
to
really
know
which
parameters
you
were
using
for
whatever
embedding
from
there
and
and
if
we,
if
everything
works
out
fine,
eventually
we
will
have
everything
to
in
all
the
levels
so
very
low
level,
just
with
numbers.
E
Even
even
if
you
know
two
libraries
talk
at
a
very
high
level
and
you
get
dumped
a
dictionary
with
a
bunch
of
stuff
as
long
as
this
stuff
is
always
coming
the
same
way.
At
least
I
have
a
way
to
be
able
to
talk
to
in
the
library
you
know
in
a
in
a
systemic
way.
You
know
I
always
get
the
same
thing,
and
then
I
know
how
to
deal
with
that.
That's
good.
J
J
J
I
think
it
might
have
some
cython,
but
I'm
not
too
sure
I
think
it's
pure
python,
but
they
did
a
really
really
good
job
of
just
generalizing.
How
do
you
define
an
unstructured
3d
map?
Like
just
you,
know,
general
mesh
data
structure?
So
it's
it's
super
general.
I
don't
think
it
will
work
for
everything
we
want
to
do
here,
but
it's
a
really
good
example
for
us
to
sort
of
look
into
of
how
they
approach
that,
but
but
yeah
so
right
out
of
the
box.
J
C
E
J
Yeah,
I
I
mean
we're
open
to
it
in
by
vista,
at
least,
but
I
think
that's
only
the
case
for
general
mesh
data
structures
right.
So
if
this
is
a
super
general
library,
you
know
we're
happy
to
accommodate
any
general
mesh
format.
But
as
soon
as
you
start
getting
into
niche
geo
formats,
I
think
it's
better
to
host
that,
either
in
subsurface,
directly
or
in
another
offshoot
project
of
like
subsurface
io,
which
can
maybe
handle
all
of
those
snippets.
J
B
B
C
C
A
C
A
J
A
F
Instead,
if
you
can
like
have
a
printout
that
says,
like
hey,
go
to
this
website
and
check
out
this
library
and
by
the
way,
the
exact
syntax
to
install
this
is
to
open
up
your
terminal
and
then
type
pip
install
like
you
know
whatever
like
right.
They
you
need
like
ver
like
the
stuff
that
you
guys
think
is
like.
Oh
yeah,
that's
like
super
simple
to
do
for
someone.
That's
not
you
know
not
in
this
world.
It's
that's!
Then
they
just
close
the
they
just
they're
like
man.
F
C
C
Okay
cool,
so
so
thank
you
for
this.
I'm
going
to
so.
My
idea
at
the
moment
is
just
adding
a
couple
of
of
input:
output
more
but
inputs,
especially
just
being
able
to
read
four
holes.
Definitely
seismic
and
probably
cloud
of
points,
because
that's
what
I
want
to
to
play
with
in
in
jenpai
after
that
I'm
going
to
slow
down
in
in
my
developing
of
subsurface.
So
that's
something
the
tricky
thing
is
also
we.
C
H
You
know
I
mean
we're
notably
missing
segway,
I
o
and
a
few
others.
I
guess,
but
we've
got
a
decent
chunk
of
the
big
ones.
So,
even
if
it
is
just
pushed
by
all
of
the
libraries
that
are
represented
here
using
it,
I
think
that's
probably
enough
to
get
it
going
and
for
people
to
take
a
bit
of
notice
of
it.
C
So
then,
I
think
that
what
I
can
promise
is
I
will
try
in
the
next
couple
of
weeks
once
I
finish
that
to
just
make
the
first
pip
release
and
maybe
even
the
sphinx
gallery.
So
yes
that
even
if
it's
very
slim
library,
it
seems
a
full
library
and
then
I
think
it's
a
good
moment.
We
just
leave
it
there
and
wait
to
see.
B
C
Yeah
but
today,
for
example,
I
was
already
importing
more
whole
data
and
visualizing
it
via
welia
and
striplock
and
visualizing
it
in
by
vista
that,
as
far
as
I
know,
I've
never
seen
it.
So
I
can
make
a
couple
of
examples
like
that,
so
that
they
can
see
that
it's
a
full
library
and
hope
that
people
get
interested
and.
E
E
E
C
Clean
things
up,
I
think
I'm
going
to
make
a
bit
a
road
map
of
tasks,
but
I
think
that
if
we
are
able
to
just
take
import
boreholes
and
maybe
topography
from
subsurface
and
an
example
how
to
do
that
visualizing
it
take
that
put
it
into
gempy,
getting
the
output
of
jump.
I
create
a
subsurface
object,
we
put
it
into
simpek
and
maybe
also
once
we
put
it
on
from
surface.