►
From YouTube: Medical image processing with OpenShift and OpenStack
Description
Boston Children's Hospital and the Massachusetts Open Cloud (MOC) are using Red Hat OpenShift and Red Hat OpenStack Platform to democratize medical image processing.
In this session, we'll give a deep dive of ChRIS (Children's Research Integration System), dig into how the MOC's model for cloud computing is creating an open ecosystem where the best ideas can win, and show how both ChRIS and MOC are benefiting from Red Hat technologies.
Learn more: https://agenda.summit.redhat.com
A
Hi
everyone
welcome
I,
so
I
guess:
I
want
to
start
with
a
quick
poll
here
just
get
an
idea
of
who's
in
the
audience,
so
how
many
of
you
showed
up,
because
we
put
OpenStack
in
the
title,
okay
couple
of
people,
how
many
of
you
showed
up
because
openshift
is
in
the
title?
Okay,
what
about
the
medical
image
processing
part?
Are
you
in
healthcare?
Do
you?
Actually?
This
is
great,
so
are
you
actually
in
healthcare?
Do
you
actually
do
metal
image
processing
as
part
of
your
work,
so
how
many
of
you
are
just
healthcare
related?
A
Okay?
What
about
you
actually
do
stuff
related
to
pinnacle
image,
processing
in
your
jobs,
I!
Guess
it
in
the
healthcare
field
at
least.
That's
great!
No
help
a
lot
so
I
just
give
me
an
idea,
so
I
hope
most
of
you
saw
yesterday
dr.
Ellen
grant
talking
with
our
CEO
Jim
Whitehurst
about
the
Chris
project
and
that's
what
we're
gonna
dive
into
a
little
bit
here.
Well,
we'll
tell
you
a
little
bit
about
the
Chris
project
itself.
I
mean
a
lot
about
how
Chris
uses
right
technologies
to
be
able
to
do
its
job.
A
So
up
on
stage
here,
we
have
where
we
have
three
groups
represented,
so
we
have
real
fear
from
Boston
Charles
Hospital,
which
is
the
leading
on
Children's
Hospital
in
the
US
and
odda
from
the
Massachusetts
open
cloud,
which
is
very
computing
facility.
Well,
we'll
talk
about
both
those
here
through
the
presentation,
so
I
should
start
by
saying
that
I
am
in
no
way
an
expert
in
medical
image.
A
Processing
I
started
working
on
this
project
with
I
did
all
four
other
folks
about
a
year
ago,
and
everything
that
I
might
say
that
sounds
like
I
know
something
about
medical
image
processing.
It
almost
certainly
came
from
rudolph
and
the
other
folks
in
the
project.
So
if
you
do
want
to
dig
it
deep
dive
into
that
topic,
Ralph
is
a
much
person
better
person
to
talk
to,
but
what
I,
what
I
have
experienced?
I
guess
in
that
past
year
is
I,
have
met
a
lot
of
people
in
the
in
the
space.
A
A
They
get
whatever
results
they
get,
they
might
use
it
within
their
own
research
institutions,
but
even
if
the
the
code
that
they've
written
is
open-source,
it's
very
likely
that
the
next
person
that
comes
along
is
not
going
to
start
from
that
codebase
they're
gonna
start
from
something
else,
because
the
way
that
the
first
person
built
it
was
not
meant
to
was
not
meant
to
pass
along
and
betterly
the
the
ecosystem.
So
my
name
is
Dan
McPherson
and
I.
Am
a
software
engineer
for
Red
Hat.
B
All
right,
good
morning,
everyone
so
over
at
Boston,
Children's
we've
been
developing
this
system
that
we've
now
come
to
call
Chris
for
a
couple
of
years
now,
and
the
first
versions
of
Chris
lived
on
a
couple
of
laptops
and
workstations
and
eventually
spread
to
an
HPC
and
now,
in
its
current
version,
it's
actually
spreading
to
the
cloud
and
that's
where
the
collaboration
with
Red
Hat
and
the
mo
see
comes
to
play.
So
in
a
nutshell,
what
the
point
of
Chris
was
to
make
it
easy
for
people
to
run
any
kind
of
medical
imaging
based
compute.
B
It's
comprised
of
a
whole
bunch
of
open
source
projects.
These
are
kind
of
containerized
kind
of
micro
services
are
communicate
with
each
other,
with
REST
API
s,
I
want
to
leverage
a
little
bit
of
what
Dan
just
said
about
reinventing
the
wheel.
That
is
a
real
problem
in
in
computational
research.
People
are
always
writing
the
same
back-end
over
and
over
again,
and
one
of
the
reasons
this
happens
is
because
there's
no
reward
in
research
to
write
a
good
system.
B
The
only
thing
that
really
matters
is
getting
some
kind
of
result
and
it
doesn't
matter
if
this
takes
a
week
to
get
the
result
or
not
getting
a
paper
applying
for
grant
funding,
that's
kind
of
a
cycle
that
works.
So
now
we
began
to
realize
that
this
actually
is
a
barrier
to
innovation.
You
can
only
innovate
so
far
if
you're
always
working
on
the
infrastructure.
So
what
we've
been
trying
to
do
is
to
make
the
infrastructure
absoulte
problem
for
a
researcher.
B
So
what
we
trying
to
do
is
develop
a
community
around
this
kind
of
Chris
infrastructure,
and
we
want
to
be
able
to
ultimately
get
to
a
point
where
we
can
process
data
very
very
quickly
and
get
it
out
of
the
hospital
on
to
the
cloud.
Do
some
very
fast
compute,
pull
it
back
into
the
hospital
and
put
it
kind
of
in
front
of
a
clinician
who
needs
that
information
very,
very
quickly
seconds
and
minutes
is
much
much
better
than
hours
or
days
and
weeks.
B
So
we
retry
to
make
research
imaging
research
clinically
relevant
as
well.
There
is
about
two
decades
worth
of
amazing
tools
that
exist
in
the
research
community,
but
these
almost
never
make
it
out
on
to
the
clinical
frontlines,
and
this
isn't
just
because
of
FDA
regulations
and
stuff.
It's
really
because
no
clinician
is
ever
gonna
fire
up
a
Linux
terminal
type
in
some
commands
figure
about
SSH
and
SCP
and
log
into
a
class.
That's
never
going
to
happen.
B
C
C
All
right,
I'm
gonna
talk
a
little
bit
about
Massachusetts,
open
cloud.
This
all
this
framework
is
running
on
on
our
cloud
and
Massachusetts.
Open
cloud
is
or
like.
Moc
is
a
very
unique
entity.
We
are
a
collaboration
between
academia,
industry
and,
and
the
government
which
you
don't
see,
often
specifically
Boston
University
in
Northeastern,
University,
UMass,
Harvard
and
MIT
came
together
and
build
a
data
center
to
be
able
to
do
research
in
innovation
on
the
cloud
and
they
figured
out
that
to
be
able
to
do
real
research.
C
You
need
to
have
a
real
environment
and
real
production
scale,
workloads
so
thats
how
emo's
he
started
and
then,
with
the
support
from
Commonwealth
of
Massachusetts
and
the
US
Air
Force
and
the
industry
partners
most
not
to
be
two
sigma:
Intel
Cisco,
Lenovo,
net
HAP,
brocade
and
and
Red
Hat.
We
formed
the
MOC
consortium
and
when
I
say
production
scale,
I
want
to
mention
a
little
bit
about
about
our
infrastructure.
We
are
operating
over
a
data
center
that
is
15
megawatts
of
that.
C
That
is,
that
is,
that
has
a
capacity
of
15
megawatts
and
we
have
two
acres
of
compute
space.
So,
just
to
give
you
a
perspective,
our
data
center
is
around
half
of
the
size
of
an
average
Google
Data
Center.
So
that's
the
even
though
MOC
is
not
using
the
whole
data
center.
As
of
now,
we
have
that
capacity
to
it
to
to
utilize
a
more
C's
man.
It
is
slightly
different
or
totally
different.
C
We
believe
that,
as
dr.
grant
mention
in
his
in
her
key
keynote
speech,
you
believe
that
hospitals
will
not
be
able
to
maintain
and
analyze
their
data
because
they
are
generating
more
and
more
data.
And
do
these
applications
have
to
move
to
the
cloud,
and
you
want
to
have
healthcare
applications
running
on
MOC
so
that
we
can
have
more
industry
level
applications
on
our
system
that
we
can
analyze
and
learn
from.
C
That's
why
we
are
interested
in
the
healthcare
space
in
general
and
in
the
Cris
project
specifically
and
our
collaboration
that
rudolf
started
three
years
ago.
He
kindly
accepted
to
mentor
a
group
of
students
in
one
of
the
classes
that
I
teach
in
Boston,
University
and
northeastern
on
cloud
computing
and
that
initial
proof
of
concept
implementation,
which
tried
to
bring
Chris
platform
to
MOC,
is
now
in
the
last
year.
Especially.
The
involvement
of
redheaded
is
not
turning
into
a
product
that
other
people
can
use
and
now
you're
trying
to
build
a
community
around
it.
C
C
A
Well,
at
the
same
time,
being
able
to
prove
out
our
entire
technology
stack
from
in
to
end
and
hopefully
do
that
in
a
way
which
makes
it
easier
for
the
next
person
that
comes
along.
As
a
group,
though,
we
have
a
few
combined
goals
that
we're
trying
to
accomplish
so.
The
first
of
those
is,
if
you
look
at
a
lot
of
these
metal
image,
processing
applications,
they
can
take
as
long
as
a
day
or
more
to
run
in
some
cases,
and
so
that
tends
to
make
them
so
that
they
become
not
clinically
relevant.
A
A
It's
a
pretty
tedious
process
of
the
patient
will
first
get
the
images
taken
and
then
have
to
come
back
days
later
to
actually
find
out
what
the
results
were,
and
so
what
we're
doing
is
using
openshift
and
OpenStack
to
be
able
to
broad
a
platform
which
is
capable
of
enormous
scale,
to
be
able
to
take
the
image
processors
and
run
them
on
many
many
instances
simultaneously,
as
well
as
using
more
advanced
Hardware
things
like
GPUs,
like
I
just
mentioned.
A
The
other
main
goal
that
we're
trying
to
accomplish
here
is
is
really
democratizing:
the
application
development
for
these
image
processors
and
and
again
it's
about
creating
in
the
ecosystem,
a
place
where
anyone
who
wants
to
build
one
of
these
processors
they
know
they
can
go.
They
can
create
the
logic
to
be
able
to
run
at
scale
and
do
so
in
a
way
which
has
a
chance
of
running
in
more
than
just
one
location.
A
They
can
run
it
in
in
a
production
environment.
The
next
component
here
is
open
shipping
kubernetes.
The
primary
piece
that
we're
using
from
open
shipped
is
the
the
scale
job
framework
and
that
lets
us
which
we'll
talk
about
this
in
some
detail,
but
that
lets
us
take
an
image,
processor
and
scale
it
from
either
one
instance
or
essentially
infinite
instances,
depending
on
the
size
of
your
cluster.
Now
we're
also
taking
heavy
advantage
of
the
resource
management
capabilities
inside
of
openshift.
A
It's
a
very
big
scheduling
problem
of
how
do
I
take
image,
processors
and
decide
which
ones
get
priority
over
others.
What
sorts
of
scale
are
they
allowed
to
run
at
it's
one
of
the
big
something
big
things
that
we've
worked
on
and
adding
to
Chris
is
the
ability
to,
as
both
a
plugin
writer
or
an
image
processor
writer,
as
well
as
an
administrator
of
the
cluster,
deciding
exactly
what
prior
to
each
each
item
gets
when
it
runs
in
the
system
and
then,
as
usual,
OpenShift
really
brings
a
lot
of
operational
characteristics
to
it.
C
Yeah
I
want
to
mention,
in
you
know
an
mo
CV
make
heavy
use
of
OpenStack
and
OpenShift,
and
especially
the
the
the
ability
of
open
shift
optimized
for
density
and
utilize
slack
resources
very
important
to
us
in
MOC
in
MOC,
like
any
other,
potentially
any
other
cloud,
we
have
a
set
of
resources
that
are
reserved
and
a
set
of
resources
that
are
free,
not
used
and
open.
Open
chef
enables
us
to,
and
also
of
course,
some
of
these
desert
resources
are
consumed
fully
utilized,
and
some
of
them
are
not
utilize.
C
They
are
slack
resources
in
some
sense,
an
open
shift
enables
us
to
exploit
these
Civic
resources
and
schedule
jobs,
or
not
only
free
resources,
but
also
on
these
slack
resources,
improving
the
density
of
our
cloud
and
this
matters
to
Chris
application,
because
we
can
now
scale
the
Chris
application
not
only
on
our
free
resources,
but
we
can
enable
it
to
utilize
more
resources
than
it.
That,
then,
is
free
available
in
that
sense.
C
But,
of
course,
this
requires
the
application
developer
to
be
aware
of
utilizing
this,
and
this
is
this
option
of
utilizing
slack
resources
so
change.
A
change
in
the
mentality
of
application.
Development
is
required,
and
part
of
the
Cris
project
is
bringing
that
bringing
that
awareness
into
the
healthcare
application
developers
showing
them
if
they
design
their
applications
and
to
be
able
to
exploit
this
opportunity
to
improve
their
performance,
to
improve
the
performance
of
their
applications.
A
Yeah,
it's
a
the
other
area
of
overlap
here
between
hope
and
shift
into.
Chris
project
comes
around
some
newer
technologies
and
artificial
intelligence
and
machine
learning,
so
at
Red
Hat.
This
is
an
area
we've
been
doing
a
ton
of
research
on
lately,
so
there's
projects
like
rad
analytics
that
are
out
there
that
have
been
proving
out
technologies
like
spark
and
tensorflow
running
on
top
of
openshift.
This
same
areas
has
a
lot
of
overlap
with
what's
happening
in
the
image
processing
space
as
well.
I
Rudolph
here
can
can
talk
to
you
afterwards.
A
If
you
want
to
dig
into
the
details
there,
but
essentially
large
amounts
of
research
are
happening
to
to
use
email
type
Tecna
technologies
in
in
the
image
processing
space.
It
is
pretty
early,
though
it
there's
not
a
lot
of
a
lot
of
ml
being
used
in
production
scenarios,
but
everyone
can
see
that's
sort
of
the
way
that
it's
heading
and
a
lot
of
innovation
is
happening.
There.
C
So
kubernetes
and
an
open
chef
not
directly
so
the
the
core
underlying
infrastructure
problem,
the
the
classical
infrastructure
needs
of
compute,
networking
and
storage
and
and
providing
a
scalable
platform
to
run
on
to
run
these
applications
as
as
is
handled
by
OpenStack
in
our
own
platform.
And
we
are
really
happy
with
OpenStack,
because
not
only
because
of
its
open
source
nature.
But
it's
also
because
of
its
modular
nature.
C
Using
OpenStack.
Different
research
teams
in
the
MRC
can
work
on
different
components
and
make
it
provide
solutions
and
innovation
in
the
cloud
space
and
make
it
available
to
the
upstream
community
to
a
larger
community
than
a
set
of
researchers
and
that's
very
important
to
us,
because
we
want
to
be
able
to
not
only
do
one
of
research,
but
we
want
to
be
able
to
do
research.
That
has
an
impact
and
that's
why
we
are.
B
B
The
first
one
is
registration,
which
is
where
you
take
one
image
and
you
match
it
into
the
space
of
another
image,
and
that
is
very
important
to
do,
because
this
is
usually
used
to
take
ground
truth
that
you
have
in
a
template
and
discover
where
that
might
be
in
the
in
the
image
you're
looking
at.
It's
also
a
measure
of
difference
between
two
different
image
sets
and
also
importantly,
if
you
have
acquired
multiple
images
and
you
want
to
compare
them
with
each
other.
B
The
first
thing
you
typically
have
to
do
is
register
to
some
common
space,
often
times
you
know,
some
images
might
be
skewed
this
way
or
differen
angle
of
whatever
the
case
may
be,
and
you
can't
do
meaningful
compute
unless
you
have
them
all
lined
up
correctly
together
and
great
registration
typically
looks
like
this.
You
have
an
original
image
and
to
show
you
over
here.
This
is
just
a
single
slice.
This
is
a
whole
volume
that
you
actually
register.
This
is
one
of
many
slices.
B
Another
hot
topic-
that's
developing
right
now,
of
course,
is
classification
with
AI
and
ml,
and
just
to
show
you
here
now
the
idea
would
be
to
have
some
image
recognizer,
classify
figure
out.
That
here
is
a
tumor,
but
you
have
different
contrasts
as
well
different
scans
and
if
you
look
very
carefully,
you'll
actually
notice
that
these
two
images
don't
even
line
up
properly,
so
registration
again
comes
into
play
before
as
a
first
step
of
machine
learning
to
get
them
in
the
same
common
space.
Another
example
that's
been
used.
A
lot
is
metabolism.
Okay.
B
What
we
can
do
is
we
want
multiple
simulations
of
light,
as
it
travels
through
brain
tissue
and
how
it
is
dispersed
and
reflects,
reflects
and
refracts
and
eventually
is
detected,
gives
an
indication
of
how
oxygen
is
consumed.
Now,
for
example
over
here,
you
have
a
source
over
here
and
the
detector
over
here
and
you
shine
light
and
it
propagates
through
the
brain
tissue
depending
on
what
is
picked
up.
You
have
an
indication
of
metabolism
now.
This
is
a
good
example
of
how
it
can
be
clinically
relevant
on
the
research
side.
B
This
kind,
of
example,
can
take
maybe
an
hour
or
two
to
simulate
for
one
or
two
wavelengths
of
light.
If
you
do
this
on
a
GPU
at
the
MOC,
it's
now
reduced
to
seconds
now.
Suddenly
you
can
have
information
back
at
the
bedside
in
a
minute
or
two
versus
multiple
hours.
Another
example
that
has
a
nice
picture
at
least
is
something
called
a
fusion
image
processing
which
is
called
tractography
and
what
you
do.
I'm,
not
gonna,
explain
the
process
in
detail,
but
you
take
a
whole
bunch
of
pictures
from
different
angles.
B
These
are
all
volumes,
one
slice
and
a
volume,
but
they've
all
been
scanned
from
a
slightly
different
direction
and
they
measure
water
diffusion.
And
if
you
take
all
of
these
images
together
and
you
solve
the
diffusion
equation,
you
can
build
this
wonderful,
3d
image.
That
looks
like
this
now.
This
doesn't
actually
tell
you
exactly
where
the
white
matter
fibers
are
the
wiring
of
the
brain,
but
it
gives
you
a
good
indication
of
where
water
diffuse,
which
probably
is
where
the
white
matter
fibers
are.
So.
Why
is
this
important?
B
Well,
if,
if
there
is
a
tumor
again
and
it
has
pushed
by
the
brain
aside
and
the
surgeon
needs
to
go
and
resect
that
tumor,
it's
a
very
good
idea
to
know
where
to
go
in
to
not
disrupt
a
major
fibre
areas.
Again
the
importance
of
having
quick
image,
processing
available
so
I'm
going
to
take
a
step
a
little
step
down
now
and
give
you
just
some
of
the
overview
of
what
Chris
looks
like.
B
So
it
consists
of
a
couple
of
components:
there's
some
kind
of
data
source,
typically
something
inside
the
hospital
and
there's
some
kind
of
compute
environment,
which
would
be
like
the
MOC.
And,
of
course
you
can
have
multiple
compute
environments
and
you
can
have
multiple
data
sources
and
essentially
all
the
Chris
really
does.
Oh
there's
one
more
component,
which
is
a
store
which
contains
all
of
these
plugins.
B
These
compute
that
you're
trying
to
run
now
what
Chris
does
is
it
takes
input
from
the
data
source,
pulls
it
to
itself
and
then
pushes
us
out
to
the
commute
environment.
At
the
same
time,
it
queries
the
store
for
a
whole
bunch
of
available
plugins
to
run
and
selects
one
of
these
which
it
calls
down
into
the
commute
environment.
B
This
crunches
produces
output,
which
isn't
pulled
back
into
Chris,
allowing
an
end
user
to
view
and
interact
with
these
two
data
sources,
both
the
input
and
output
and
in
the
same
vein,
you
can
have
more
data
sources
come
through
different
compute
environments
and
the
one
central
source
of
Chris
is
able
to
orchestrate
between
all
these
different
environments.
So,
in
the
case
of
the
MOC,
we
have
OpenStack
over
here
and
then
the
compute
controlled
by
openshift
and
a
little
more
detail
about
that.
A
Yeah,
so
at
the
top
here
we
have
bch
that's
sort
of
the
front
end
of
Chris
burning
inside
of
bch
and
the
bottom.
We
have
the
MOC
again
open
for
any
on
OpenStack,
and
so
the
way
this
process
works
is
first,
data
is
sent
to
to
open
shipped
through
a
component
called
the
I/o
handler
inside
of
Chris.
That's
a
component
running
on
open
shipped,
and
then
the
data
is
stored
inside
of
Swift.
A
I
would
do
that
because
we
want
to
separate
each
of
the
data
stores
on
the
back
end
so
that
each
individual
job
that's
running,
can't
access
the
from
any
other
job
and
so
we're
using
Swift
for
the
segmentation
there.
The
next
thing
that
happens
is
that
a
process
manager
thing
gets
it
an
operation.
That
operation
is
of
the
form
of
some
docker
image
to
run
as
well
as
a
command
then
run
against
it
and
that's
the
actual
processing
that's
taking
place.
The
first
thing
the
process
manager
does.
A
Is
it
launches
a
job
that
job
has
some
number
of
pods
in
it,
I
mean
each
of
the
pods.
Have
this
structure
so
they
have
first,
an
init
container
that
launches
in
kubernetes
that
a
NIC
containers
job
is
to
set
everything
up,
so
the
rest
of
the
containers
can
then
have
what
they
need
available
and
in
this
case
the
thing
that
it's
setting
up
is
pulling
data
out
of
Swift.
Writing
it
to
some
local
volume
and
making
it
available
for
the
next
container
to
launch.
A
In
that
case,
the
next
container
is
the
image
processor
itself
or
its
plugin,
and
the
image
plugin
now
does
whatever
work
it's
going
to
do
so
it
took
it,
takes
the
data,
that's
written
to
a
local
disk
from
an
input
directory.
Does
it's
it's
crunching
of
that
data,
writes
the
output
to
an
output
directory
and
then,
at
the
same
time
it
was
launched.
Another
container
was
launched,
which
was
a
published
container.
A
That
publish
container
has
this
entire
time
since
it
was
launched,
been
watching
against
the
open,
shipped
API,
to
figure
out
when
the
image
processor
is
done,
and
once
it
is
done,
it
will
take
the
result
from
the
output
directory
and
publish
it
back
to
Swift,
and
then
what
once
that's
done?
The
Chris
front-end
is
now
able
to
call
back
into
the
I/o
handler
to
get
the
results
and
show
them
into
into
the
front-end
UI.
So
that's
the
basic
process.
A
The
reason
that
we've
developed
it
this
way
with
the
the
extra
two
containers
around
the
image
processor
is
it
makes
it
to
the
image.
Processor
itself
doesn't
really
have
to
understand
the
logic
around
it.
Pretty
much.
Every
image
processor
that's
out
there.
Now
they
are
written
with
some
basic
assumptions
of
they
can
read
and
write
their
output
to
disk,
and
that's
really
all
we
you
have
to
know
here
you,
you
package,
your
image
processor
as
a
docker
image,
and
you
are
told
what
your
input
directory
is.
You're
told
what
your
output
directory
is.
A
Since
his
is
essentially
the
same
work
I
simply
specify
what
size
you
want
it
to
run
at
and
have
your
plugins
coordinate
with
each
other
to
do
a
portion
of
the
work
so
deep,
diving
a
little
bit
into
what
it's
like
to
to
parallel
as
a
job
instead
of
kubernetes.
There
are
a
few
different
options
as
far
as
how
you
can
you
can
do
the
parallelization
all
right.
A
Each
of
those
containers
would
be
launched
to
a
separate
node,
and
in
that
way
we
can
get.
You
know
additional
compute
added
to
the
equation
this
in
this
case
it's
four,
but
it
could
be
a
hundred.
It
could
be
whatever
number
you
can
specify.
The
hard
work
here
really
is
is
not
so
much,
though,
actually
scaling
the
hard
work
is
writing
your
code
in
a
way
that's
capable
of
breaking
the
algorithm
up,
and
it
really
depends
on
what
the
algorithm
is
as
to
how
difficult
that
may
be.
A
A
A
What
priority
do
I
want
to
set
for
a
plugin
as
it
runs
so
I
might
tell
you
know
a
particular
plug-in
should
run
at
a
high
priority
and
it
would
get
closer
to
its
maximum
of
threads
allowed
or
it
may
be
a
low
priority
and
get
its
minimum
number
of
containers
allowed.
So
we
learned
a
lot
from
doing
this
again,
how
we
scale
in
the
system.
A
It
also
often
comes
down
to
this
sort
of
problem
where
most
of
the
time,
the
algorithm
looks
something
like
this,
where
there's
a
sort
of
a
set
up
phase
where
everything
gets
in
place,
you
sort
of
a
sign
out.
You
know
which
workers
are
gonna,
do
what
part,
and
maybe
some
part-
that's
not
parallelizable,
then
you
get
to
the
actual
parallel
parallel
processing
part
and
then,
after
you've,
you've
done
your
parallel
processing.
You
need
to
you
need
to
coalesce
your
results.
A
If
the
ratio
looks
something
like
this,
you
have
a
pretty
good
chance
of
achieving
better
results.
However,
if
you
have
you
know
ten
hours
of
processing
and
only
one
hour
of
that
processing
is
parallelizable,
then
you're,
obviously
not
going
to
get
any
better
into
the
nine
hours,
no
matter
what
you
do,
and
so
it
really
depends
what
the
what
the
situation
is
as
to
how
much
advantage
you
can
get
out
of
it.
In
this
case,
with
ants
we
we
did
see
a
pretty
good
ratio
of
of
improvement,
but
it's
gonna
vary.
A
The
other
big
piece
of
work
that
we've
done
is
with
GPU
enablement.
I/O
just
gave
everyone
an
idea
of
what
the
the
topology
looks
like
for
GPUs.
This
is
trying
to
break
down
what
the
setup
looks
like
inside
of
the
MOC,
with
a
single
host
example
running
on
OpenStack.
So
with
that
hosts,
we
have
two
beams
assigned
here.
The
host
itself
has
three
GPUs
that
are
available
to
it
and
to
get
those
GPUs
assigned
to
the
VMS.
A
So
it's
a
simple
scheduling
problem
today,
where,
as
a
container
is
launched,
it
is
it
declares
that
it
needs
a
GPU
to
the
Chris
system
and
then
to
OpenShift,
and
at
that
point
we
are
able
to
find
a
machine
that
has
those
GPUs
and
allocated
to
particular
containers.
I,
there's
work,
that's
happening
to
be
able
to
virtualize
GPUs,
both
an
open
stack
and
in
open
shift.
But
as
of
today,
it's
it's
a
simple
pass-through
mechanism.
It's
worth
noting
that
the
the
work
with
GPUs
the
the
real
innovation
here,
the
thing
that's
so
helpful.
A
I
I've
experienced
at
least
over
over
the
past
six
months
of
working
on
this,
that
I'm,
getting
GPU
set
up
and
working
is
an
incredibly
typical
thing.
If
you,
if
you
start
from
you,
know
a
machine
and
tell
someone
you
know,
get
it
to
the
point
where
you're
able
to
run
a
meaningful,
GPU
or
cloade.
I
it's
a
lot
of
work
involved.
The
biggest
part
of
the
innovation
here
is
is
giving
someone.
A
That's
scheduling,
algorithm
as
part
of
the
platform
makes
it
so
that
you
can
simply
request
a
GPU
run
your
program
and
a
diffuse
handed
to
you.
That
by
itself
is
an
incredibly
major
major
helpful
thing
for
anyone.
That's
trying
to
build
one
of
these
plugins
and
again
the
same
thing
applies
really
to
the
to
the
AI
and
mo
work
that
I
talked
about
before.
Ok,
so
I
as
far
as
in
in
openshift,
we
use
the
the
Vice
plug-in
mechanism.
A
So
that's
tech
preview
at
3.10
that
we're
currently
using
hopefully
we'll
go
da
soon
and
the
out
of
them
out
of
them
is
very
simple.
We
simply
specified
whatever
number
of
containers
we're
going
to
launch.
They
are
scheduled
to
know
to
what
tab
GPUs
available
and
we
get
to
take
advantage
of
all
of
that
power.
A
So
we
want
to
show
you
a
couple
of
examples
here
to
give
you
a
rough
idea.
The
types
of
performance
improvements
you
can
expect
from
using
GPUs
the
data
is
not
incredibly
important
for
you,
because
you're
not
gonna,
run
this
particular
program
most
likely
in
whatever
you're
doing,
but
it
is
probably
useful
to
get
an
idea
of
why
you
would
go
through
this
effort
of
using
GPUs,
and
so
in
this
case
this
was
a
image
processor
that
was
converted
to
be
able
to
run
on
top
of
Chris.
A
It
does
prostates
segmentation
and
we
tested
it
against
two
different
cases.
We
the
first
case
that
you,
the
first
bar
there
is
against
a
56
core
system.
We
can
get
you
the
specs
on
that.
If
you're
really
curious
and
you
can
see
it
took
I
think
52
seconds
to
run
and
against.
We
compare
that
against
ready
to
get
stay,
single,
nvidia,
tesla,
p,
100,
and
it
took
six
seconds
to
run.
So
that
gives
you
a
rough
idea
of
the
type
of
improvement
you
can
get
between
a
pretty
massive
machine
and
a
single
GPU.
A
B
So
again,
nothing
revolutionary
in
this
slide
just
to
belabor
the
point
of
GPU
improvement,
as
opposed
to
the
previous
one.
Here
taller
is
better,
but
again
with
that
example
of
the
light
propagating
through
the
brain
on
a
CPU.
We
have
throughput
around
about
this
level
and
running
these
two,
the
GPUs
different
types
of
GPUs
over
here
we
just
see
a
massive
improvement.
B
We
can
do
a
lot
more
stuff
in
amount
of
time
and
get
results
back
so
much
quicker,
so
we're
gonna
quickly
shift
over
to
a
demo
just
to
show
you
a
little
bit
of
a
flavor
for
what
we
have
there.
So
here,
I've
just
logged
into
a
test
version
of
our
system
back
at
Children's
in
Boston
and
I'm
just
going
to
quickly
show
you
the
flavor
a
little
bit
I
don't
want
to
necessarily
get
stuck
into
the
UI.
B
B
An
open
storage,
open
Swift
in
this
particular
case
and
the
UI
over
here
does
provide
you
a
view
to
be
able
to
look
at
it
directly
in
the
in
this
system
like
this,
but
now
what
you
would
typically
do
is
you
would
select
the
data
of
importance
and
you
would
select
an
analysis
to
run
upon
them
over
here,
where
you
would
choose
a
next
step
of
some
kind
of
processing.
So
we've
done
that
now
and
if
you
were
to
do
that,
let
me
just
close
that
out
and
execute
the
processing.
B
It
will
open
up
a
Chris
viewer
in
a
new
tab.
It's
running
it
should
be
running
it
now,
and
the
data
should
be
coming
back
in
a
second
or
two.
There
we
go,
and
this
was
just
showing
the
result
of
that
registration,
so
I'm
just
going
to
pull
them
in
a
little
bit.
So
here
we
have
our
original
image
and
I'm
gonna
pull
in
annapolis
over
here,
and
let
me
just
to
show
the
registered
volume
over
here,
I'll
just
close
this
one,
a
little
bit
and
again,
as
I
mentioned
a
bit
earlier.
B
So
these
aren't
just
slices
actually
rachels
register
the
entire
volume,
which
consists
of
multiple
slices,
and
now
we
can
navigate
through
the
different
slices
such
as
this.
We
can
compare
the
original
to
our
registered
by
linking
them
together
and
navigate
through
the
volume
space
in
a
in
a
combined
fashion
such
as
this.
Just
to
give
you
a
quick
flavor
of
how
the
system
works
and
how
easy
it
is
for
a
clinician
to
actually
begin
to
interact
with
these
very
sophisticated
back-end
services.
Yeah.
A
So
it's
worth
mentioning
that
a
end
user
of
this
will
never
really
see
open
chips
on
the
back
end,
but
just
to
give
you
a
rough
idea
of
what
this
looks
like.
So,
if
you,
if
you've,
got
to
open
ship
itself,
this
is
one
of
our
test
systems
that
we
use
and
it's
running
I've
mentioned
the
IOA
number
four,
that's
a
PF
io
h
and
the
process
manager,
which
we
call
P
man
both
running
on
open,
shipped
here
and
then
the
actual
jobs
themselves.
You
will
see
running
as
pods,
and
so
it's
comes
up.
A
B
All
right
so
as
we're
wrapping
up
a
couple
of
takeaways
and
parts
forward,
so
at
least
for
the
Chris
project.
We
are
very
excited
about
the
work
we've
been
doing
with
the
MRC
and
Red
Hat
down
in
our
lab.
We
have
a
very
small
team
of
developers
and
there's
no
way
we'd
be
able
to
scale
to
this
level
without
technology,
but
also,
importantly,
without
connections
to
the
ones
we've
made
at
Red
Hat
and
the
MRC.
C
And
I
want
to
stress
on
the
democratizing
and
enabling
impact
of
Chris
Chris
is
by
no
means
finalised.
We
are
still
working
on
expanding
it
by
building
a
larger
community
around
it
by
working
with
different
hospitals
and
different
healthcare
application
groups,
and
in
the
last
spot
we
had
a
haircut
turn
around
it.
C
There
were
a
lot
of
professionals
it
from
the
image
processing
space
that
came
and
built
plug-ins
for
for
the
application
for
the
Chris
platform,
but
also
students
from
my
class
came
in
and
manage
to
build
plug-ins
for
the
Chris
platform,
so
that's
kind
of
showcasing
the
power
of
Chris
and
also
I'm
going
to
mention
a
little
bit
about.
This
is
the
first
half
of
the
process.
For
us
this
is
enabling
competition
and
bringing
it
to
the
fingertips
of
of
clinicians.
C
That's
what
we
are
trying
to
do
so
all
different
types
of
image,
processing,
applications
that
are
built
out
there
by
different
researchers.
Now
they
could
be
consolidated
in
one
platform
and
operated
over
using
a
single
standard,
uniform
framework,
but
also
we
want
to
do
the
address
the
inverse
part
of
this
problem,
which
is
bringing
the
data
to
the
application
developers.
So
we
are
trying
to
build
there.
C
We
are
hoping
to
build
a
dataset
repository
that
that
will
have
anonymized
clinically
relevant
data,
that
people
can
work
on
to
do
and
test
area
applications
and
to
also
have
clinically
relevant
problems
that
are
proposed
by
clinicians
and
to
be
able
to
work
on
real
problems
as
computer
scientists.
So
that's
the
second
part
of
our
of
our
journey
that
we
hope
to
work
on
yeah.
A
So,
just
to
add
a
little
bit
to
it
with
a
hackathon,
so
I
think
my
best
memory
of
working
on
this
so
far
was
at
that
hackathon.
Seeing
people
who
get
were
entrenched
in
building
a
particular
image
processor
and
whenever
they
discovered
the
Chris
system
and
what
it
can
do
and
when
their
words
were
something
along
the
lines
of
oh
wow,
I,
never
thought
about
being
able
to
scale
my
plugin
before
and
hearing
that
and
then
realizing,
like
the
innovation,
that's
possible
now
I'm.
A
A
It's
been
amazing
to
see
it
and
I
think
it's
a
really
good
example
of
being
able
to
take
the
right
technologies
to
start
with,
in
this
case,
open
ships
and
OpenStack,
and
it
really
being
able
to
leap,
frog,
leap,
frog,
the
innovation
but
I
just
want
to
say
thank
you
to
and
Rodolphe
here
and
to
the
rest
of
the
team
as
well
who's
out
there
who
works
on
this
project
every
day.
It's
been
a
great
experience
and
with
that
I
think
we'll
take
any
questions.
People
have
yes
right
here.
C
Yeah,
the
reason
that
we
want
to
work
with
OpenStack
in
MOC
is
is
because
of
its
modular
nature,
but
in
this
project,
specifically
open-open
shape
does
not
address
the
the
infrastructure
requirements.
We
have
like
the
networking,
the
storage
and
the
compute.
That's
for
that
for
managing
that
in
an
elastic
manner.
A
You
couldn't
achieve
it
nearly
as
easily
right,
so
you
could
absolutely
build
OpenShift
on
top
of
bare
metal,
but
you'd
have
to
somehow
go
provide
your
own
object
store.
You
have
to
provide
your
own
block
storage,
all
the
all
the
different
pieces
OpenStack
brings.
It
just
makes
your
life
a
lot
easier
right
and.
C
C
C
As
of
now,
this
is
not
HIPAA
compliant
all
the
data
we
have
is
anonymized
and
we
are
working
towards
that
or
the
solution
that
that
we
we
are
working
towards
the
solution.
Very
weakly
can
build
on
claims
for
different
Hospital
that
are
protected
and
there
are
HIPAA
compliant
for
those
systems
and
also
working
to
over
encrypted
data
sets
and
being
able
to
do
multi-party
computation
so
that
people
do
not
expose
their
data
sets
to
other
groups.
Those
are
all
in
their
roadmap.
B
Well,
I
mean
the
most
obvious.
One
is
twofold:
the
first
one
is
making
it
very
easy
to
get
new
features
at
the
bedside
right.
It's
without
having
to
have
anyone
deal
with
the
complexity
of
setting
any
of
this
up.
It's
available
for
the
complexity
of
opening
up
your
phone
and
going
to
web
browser,
and
the
other
part
of
that
is
also
speed.
B
Ideally
speaking,
the
same
plugins
that
would
take
a
certain
amount
of
time
on
a
local
resource
inside
the
hospital
can
now
benefit
from
much
better
Hardware
out
in
the
cloud
and
provided
that
the
latency
of
pushing
data
out
there
and
pulling
it
back.
Isn't
that
bad?
You
have
a
new
tremendous
speed
up,
so
you
can
get
stuff
back
in
seconds
or
minutes.
Well,
let's
say
minutes
versus
hours,
and
that
makes
a
very,
very
big
difference.
So
those
are
them.
B
Those
are
the
main
components
and
allied
to
that,
at
least
is
also
something
that
Ellen
mentioned
it'll
be
on
stage
yesterday,
which
is
also
important.
Is
that
I
provide
a
web-based
container
technology
like
this?
All
it
needs
really
from
the
front
end
is
a
cell
signal.
You
can
be
sitting
out
anywhere
in
Africa
and
wherever
in
the
world
you
might
be,
and
cell
signal
is
amazing.
It's
it's
everywhere
and
you
are
able
to
now
transfer
images.
You
are
able
to
at
least
interrogate
datasets
wherever
you
might
be.
So
that's
also
very
exciting
for
us.
A
A
A
So
yes,
so
the
the
thing
there
is
the
contract
with
the
image.
Processors
needs
to
be
block
storage,
and
so
we
don't
want
the
image
processor
that
processors
have
to
have
a
library
is
added
to
them
and
teach
them
how
to
read
and
write
from
objects,
doors
and
that's
why
we
abstract
that
away
from
them.
It's
worth
noting
through
the
NFS
years,
they're
temporary.
They
basically
come
and
go
as
each
job
comes
and
goes
so.
It's
not
important
storage.
It's
just
an
artifact
today
and.
B
I'm,
not
a
Kleenex
just
to
follow
up
on
that
most
of
the
developers
in
in
this
field.
They
don't
know
rest
api,
is
they
don't
know,
opens
you
know
any
kind
of
storage
makers
like
this?
They
just
no
files
and
directories.
So
we
want
to
make
it
as
easy
for
them
as
possible
to
not
have
to
learn
new
models
in
terms
of
developing
their
compute.
Most
people
just
write
this
stuff
in
MATLAB
right
so
that
they
just
want
an
input
directory
or
an
output
directory.
A
Okay,
so
it's
not
how
you
answer
the
question:
I
saw
they
I,
guess
speaking,
it
train
it
your
boats,
so
there's
I'm,
sorry
yeah.
So
as
far
as
people
in
the
project,
there's
probably
two
answers.
There's
the
answer
of
how
many
people
work
on
the
Chris
platform
and
then
there's
the
answer
of
how
many
people
are
building
image
plugins
to
run
on
the
Chris
platform.
I
think
I
can
probably
answer
the
first
one
of
how
many
people
are
working
on
the
project.
A
B
A
Yeah
so
as
far
as
it
depends
of
what
you're
describing
there,
so
if
you
mean
you
can
run
this
on
your
laptop,
the
entire
thing
on
your
laptop
and
that
takes
a
matter
of
a
few
minutes
till
launch
it
from
nothing
to
the
whole
thing
running.
If
you
want
to
stand
it
up
in
the
MOC,
it's
a
little
longer,
you're,
probably
talking
the
matter
of
a
few
hours
to
stand
the
whole
thing
up,
but.
B
We
need
you
just
have
to
go
to
get
to
a
git
clone
and
then
run
the
make
file
and
it'll
fire
up
all
the
containers.
It'll
be
ready,
it'll
be
waiting,
you'll
have
the
entire
system,
except
with
the
open,
stack
and
open,
but
the
entice
is
running
on
swarm
inside
your
local
machine.
So
you
can
develop
your
plugin
there
and
you
have
the
exact
same
experience
as
you
would
deploying
it
out
to
to
the
cloud.
C
So
far
so
far
like
what
we
did,
the
process
we
did
is
just
running
these
hackathons
and
inviting
people
so
that
they
can
build
plugins
and
they
can
put
it
into
our
image
repository
and
it
is
not
a
hospital
specific
solution
that
we
have.
The
the
other
end
of
this
is
like
adding
another
front-end
other
than
Boston
Children's
Hospital
to
this
a
crisp
content
that
can
tie
into
this.
C
B
It
kind
of
comes
from
2
to
2
levels
right
to
the
bottom
up,
which
would
be
developers,
researchers
benefiting
from
this
system
in
different
institutions,
and
then
it
becomes
it
grows
from
that
level,
but
also
from
the
top
from
operational.
You
do
have
to
engage
with
hospital
admin
and
decision
makers
to
get
them
on
board,
with
seeing
the
benefit
of
sharing
their
data
and
collaborating
in
a
broader
scale,
which
is
much
more
difficult.
Those
are
the
two
angles.
C
Yeah
I
a
mother,
try
to
mention
it
like
I
leave.
We
are
teaching
this
cloud
computing
course
in
Boston
University
and
not
Northeastern,
University
and
Rodolphe,
kindly
accepted
to
be
a
mentor
to
a
student
group
and
his
suggested
project.
Was
this
bringing
crest-2
to
the
cloud
to
a
public
cloud
at
that
time
it
was
just
running
in
in
a
specific
cluster
and
his
specific
HPC
cluster
in
the
hospital
and
I
mean
it
that
class
project
he
started,
but
within
the
last
year
we
turned
it
into
a
real
product.