►
From YouTube: LSST DESC 2nd Data Challenge Image Simulation Campaign with Parallel Python Workflows, A Villareal
Description
The Vera Rubin Observatory LSST is going to provide the astrophysics community with an unprecedented amount of survey data with which to contain the evolution of the universe through time. In order to leverage this dataset, we will ultimately require extensive simulations in order to validate scientific pipelines ahead of the survey ever seeing light. The LSST Dark Energy Science Collaboration (DESC) Second Data Challenge (DC2) represents the largest simulated sky survey of its complexity. Generating such a simulation required managing a complicated and rapidly changing workflow across multiple compute resources. We demonstrate how we utilize containerization and the Parsl parallel scripting library in order to create a portable and scalable workflow to meet the challenges of this computational task. With this workflow we were able to generate a simulated survey volume covering 300 square degrees and five years of image depth, utilizing 100M hours of compute and up to 2000 Cori KNL nodes at a time. We discuss possible improvements that could be made to the workflow for future survey simulation, both from the standpoint of utilizing the increasingly common workflow nodes at high performance computing (HPC) centers and that of how the underlying image simulation code may be altered to benefit more from computing at these scales.
A
B
B
B
What
are
the
next
steps
for
both
the
parcel
team,
the
imsim
team?
That's
doing
this
image
simulation
as
well
as
for
just
sort
of
general
lsst
desk
goals,
and
I
was
asked
to
to
talk
a
little
bit
about
what
is
this
all
like
as
a
first
round
postdoc
with,
in
my
ex
personal
opinion,
very
little
experience,
but
that
might
be
the
imposter
syndrome
talking.
So
I'll
talk
a
bit
about
that.
B
So,
let's
start
by
talking
about
what
the
vera
rubin
observatory,
lsst.
Second
data
challenge
in
simulation
campaign
is
and
why
I
had
to
make
this
section
header
so
dang
long
so
to
the
left.
You
can
see
a
image
of
the
vera
rubin
observatory,
it's
a
large
telescope
being
built
in
chile
before
the
purpose
of
doing
a
survey
of
the
entire
night
sky.
B
B
So
this
is
going
to
be
an
unprecedented
amount
of
data
in
the
field
of
astrophysics.
This
telescope
essentially
surveys
the
entire
night
sky.
Once
every
three
nights,
that's
an
enormous
amount
of
data
and
over
the
course
of
the
entire
observational
run,
it
will
be
generating
petabytes
of
data.
It
is
auto
advancing
on
me,
it'll
be
close
enough,
so
our
focus
here
is
studying
the
cosmology
of
the
universe.
B
The
plot
to
your
right
is
plonk
measurements
of
the
cosmic
microwave
background,
with
temperature
fluctuations
mapped
out
as
a
function
of
angular
scale
on
the
sky,
and
what
you
can
see
is
that
these
have
error
points,
they're,
very,
very
tiny.
It's
a
very
high
precision
experiment
and
you
can
fit
that
very,
very
complicated
signal
with
only
seven
cosmological
parameters,
which
is
a
little
absurd
in
some
ways,
and
so
that's
sort
of
become
codified
in
this
lambda
cold
dark
matter.
Cosmology,
the
lamp
has
dark
energy.
B
Cold,
dark
matter
means
it's
dark
matter
that
doesn't
move
very
fast
and
that,
while
tensions
do
exist
with
this
model,
it's
very
difficult
to
find
models
that
can
address
all
of
the
data
that
we
have
in
the
universe
simultaneously
and
just
fit
so
the
desk.
This
dark
energy
science
collaboration,
wants
to
understand
the
evolution
of
the
universe.
B
If
you've
been
to
a
cosmology
talk,
you've
seen
the
pie
chart
on
the
right
countless
times
this
one's
from
astrokaty
on
twitter
who's,
a
fantastic
science
communicator
universe
is
made
of
5
visible
matter
that
we
can
see
27
strange
gravitational
attraction
that
we
call
dark
matter
and
roughly
70
strange
gravitational
repulsion
that
we
call
dark
energy
and,
like
I
said
that
model
fits
incredibly
well.
So
we
want
to
find:
is
this
the
correct
model,
or
does
the
model
break
down
somewhere
near
ribbon?
B
Observatory
lets
us
basically
push
on
that
by
pushing
down
the
statistical
errors
considerably,
but
in
turn
we
also
need
to
push
down
the
systematic
errors.
We
have
to
be
really
sure
that
we're
not
having
any
systematics
that
will
throw
us
off
because
we're
measuring
very
small
deviations
at
this
point
to
test
this
we
need.
Well.
We
have
a
simu
survey
of
unprecedented
scale,
so
we're
going
to
need
simulations
of
unprecedented
scale
as
well,
and
so
that
brings
us
to
the
data
challenges
that
lsst
desk
has
been
doing,
culminating
in
data
challenge
2..
B
B
On
me,
okay,
so
dc2,
it's
status,
challenge
2.,
it's
a
very
large
simulation.
The
panel
on
the
left,
all
that
red
area
is
the
part
of
the
sky
that
we
expect
lsst
to
be
covering
that
small
teal
square
is
the
data
challenge
to
survey
area.
It's
300
square
degrees
of
the
night
sky
covered
for
five
years
of
death.
B
It
has
a
wide,
fast,
steep
component,
which
will
be
enabling
large-scale
structure
studies.
That's
just
area,
that's
covered
with
the
normal
lsst
cadence,
and
then
there's
going
to
be
a
deep
drilling
field
in
which
we
hit
these
same
areas
over
and
over
and
over
again
in
order
to
enable
transient
studies
through
objects
such
as
supernova
or
quasars.
That
change
over
time,
it's
being
done
in
six
bands
of
colors
that
matches
up
with
the
telescope,
exactly
so
that
this
will
essentially
be
giving
us
the
exact
outputs
we
expect
from
the
real
telescope,
but
entirely
simulated.
B
B
We
start
with
just
these
seven
cosmological
parameters
that
I
was
talking
about
previously
and
some
other
junk,
and
we
put
it
into
a
numerical
simulation
run,
essentially
with
only
gravity
and
from
that
we
can
see
how
dark
matter,
structures
in
the
universe
from
the
we
know
that
galaxies
live
in
the
center
of
these
dark
matter
structures,
so
we
can
take
where
the
structures
are
located.
We
can
take
observational
data.
We
have
from
other
surveys
on
how
galaxies
look
and
plug
it
all
together
to
make
a
catalog
full
of
galaxies
in
the
universe.
B
B
What's
the
dust
looking
like,
and
so
we
can
put
that
all
into
a
single
output
that
is
called
an
instance
catalog,
and
this
catalog
is
basically
everything
that
our
image
simulation
code
needs
in
order
to
simulate
a
telescope
quality
image.
It's
basically
telling
where
all
the
galaxies
are,
what
you're
looking
through
etc,
and
so
that
brings
us
finally
to
our
core
application
that
this
high
performance
computing
campaign
is
on,
which
is
imsim.
D
B
B
Now
that
being
said
in
our
particular
case,
it
actually
doesn't
really
matter.
We
don't
need
the
universe
to
be
correct
in
any
real
sense.
We
need
it
to
be
correct
enough
that
people
can
run
the
science
pipelines
and
see
where
things
break,
so
we're
never
actually
worried
about
them.
Recovering
this
original
cosmology
we're
just
worried
that
they
can
actually
reasonably
try.
B
It
would
be
actually
very
exciting
if
they
could
recover
the
original
cosmology,
but
we're
not
there
yet,
but
yeah.
So
really,
this
halo
galaxy
connection
is
probably
the
biggest
step
for
what
you
would
classify
as
an
error,
but
we
basically
designed
it
to
be
as
close
to
observation
as
possible
for
a
lot
of
signatures
so
that
people
can
test
their
science
reliably.
B
C
B
Okay,
so
we
have
our
catalog
of
objects.
We
now
have
an
image
simulation
code
called
imsim.
It's
essentially
a
python
code
that
builds
off
of
an
open
source
project
called
gal
sim,
and
all
that
does
is
it
takes
that
previous
instance
catalog
we've
said,
and
now
it
takes
all
the
information
about
the
telescope
and
for
every
single
sensor
on
your
camera.
B
B
So
how
does
that
look
in
practice?
So
the
image
simulation
gal
sim
is
handling
the
simulation
of
the
objects
under
the
hood,
or
we
have
a
python
code
that
handles
the
pointing
of
the
telescope
simulation
of
lensing
and
dust
and
simulation
of
extra
galactic
objects
and
stars.
It's
essentially
a
giant
decision
tree
for
extragalactic
objects
that
chooses
between
many
different
possible
methods
from
fourier
transforms
to
ray
tracing,
to
determine
the
fastest
way
to
draw
objects,
while
maintaining
all
the
realism
that
we
need.
B
Okay,
so
that's
roughly
how
this
image
simulation
code
works.
So
how
are
we
gonna
end
up
turning
this
into
a
scalable
and
portable
workflow,
because
we
want
to
leverage
as
many
resources
as
we
can
step.
One
for
us
is
containers,
so
why
are
we
considering
using
containers
when
there's
some
overhead
associated
with
them?
B
There's
two
major
reasons.
The
first
is
that
the
underlying
software
we're
using
is
pretty
large
and
it
was
also
being
frequently
iterated
on.
We
need
to
basically
bring
in
a
lot
of
software
that
lsst
desk
has
developed
it's
very
many
different
people
contributing
to
it,
and
so
I
can
change
frequently.
Software
containers
give
us
a
way
to
basically
lock
all
that
software
in
place
and
make
sure
nothing
changes
on
us
on
surprise.
You
know
by
surprise
the
other
advantage
is.
It
lets
us
leverage,
compute
resources
across
multiple
sites
with
potentially
different
architectures.
B
C
B
Very
different
architecture
by
comparison
so
the
way
we
ended
up
approaching
this,
we
have
an
underlying
docker
container.
It's
generated
with
everything
we
need
to
run,
msim
on
it
and
shifter
and
singularity
can
pull
this
container
go
through
their
steps
of
rebuilding
it
as
they
need
to
and
give
us
something
that
we
need
to
run
the
pipeline
with
as
simple
as
a
change
of
a
couple
of
tags
in
our
our
parcel
workflow.
B
Here's
an
example
of
one
of
the
containers
we
use.
We
basically
pull
in
this
lsst
stack
container
as
the
baseline.
It's
very
large,
it's
kind
of
a
you
know,
it's
a
lot
and
then
we
just
add
specific
software
on
it.
We
tag
it
as
well
as
possible
so
that
we're
using
specific
versions
and
can
trace
back
things
in
case,
something
you
know,
goes
wrong
somewhere
down
the
pipeline
and
then
we
just
you
know,
tag
our
containers
and
we
can
pull
them
down
by
the
tags
into
our
parcel
workflow.
B
That's
all
pretty
straightforward.
We
have
an
entry
point.
We
actually
don't
use
it.
We
just
send
the
commands
parcel,
allows
us
for
the
next
step
here.
It's
a
parallel
programming
library
for
python
and
what
parcel
does
is.
It
runs
a
driver
process
that
then
communicates
with
the
compute
nodes
where
you
start
up
worker
processes
and
these
worker
processes
then
communicate
back
to
your
driver
and
ask
if.
B
For
it
parcel
stores,
this
work
is
what
are
called
applications
or
or
just
apps,
and
these
are
either
python
commands
or
just
an
arbitrary
bash
command
that
you
want
to
execute
and
whenever
a
worker
is
available
parcel
then
distributes
runtime
to
these
applications
and
when
you
know
an
application
finishes,
the
worker
says
it's
available
for
more
work.
This
is
important
for
us
because
of
the
plot
you
see
here
on
the
right,
which
is
the
distribution
of
sensor
runtimes
for
the
deep
drilling
field,
where
we're
only
adding
on
transient
objects.
B
These
runs
take
10
hours
to
simulate,
and
so
it
can
be
a
two
hour
difference
between
sensors
and
so
it's
very
important
for
us
to
be
able
to
keep
cycling
in
work,
and
so
we
just
cycle
in
new
work.
When
old
work
finishes,
we
have
checkpointing
so
that
if
the
resource
block
cuts
off
early,
we
don't
actually
lose
all
that
much
and
can
just
build
off
of
that
in
the
future.
D
B
I
would
I
usually
call
it
a
workflow
manager
in
a
lot
of
ways,
because
you're,
just
generating
a
list
of
work
and
parcel
is
handling
how
it
gets
handled
out,
but
it
also
has
some
parallel
programming
sense
to
it,
because
it's
not
actually
you
don't
have
to
use
like
mpi
to
connect
everything
it
uses.
I
think
zmq
under
the
hood
for
the
high
throughput
executors.
B
B
B
B
B
Black
line
is
just
an
image
of
how
quickly
gosh
I
wish
I
could
kill
the
timings
on
this.
Okay,
let's
just
pause
it
here.
The
black
line
is
just
for,
as
you
scale
up
the
number
of
sensors
sensors,
how
does
the
memory
footprint
go,
and
so
we
never
really
get
to
leverage
full
hyper
threading
with
this
sort
of
setup,
just
due
to
the
way
that
we've
set
up
the
code,
but
we're
really
memory
bound.
B
So
what
we
have
right
is
a
bundler,
that's
trying
to
balance
a
couple
of
needs.
Each
container
has
some
memory
footprint
associated
with
it
because
of
its
bulk.
Multiple
sensors
from
a
single
telescope
visit
can
actually
share
some
overall
memory
because
they're
all
looking
through
the
same
night
sky,
we
can
share
that
among
sensors.
Even
though
it's
paralyzed
around
sensors,
each
sensor
has
some
average
memory
footprint,
which
is
what
we've
plotted
here.
B
B
B
B
We
were
able
to
use
a
100
million
plus
compute
hours,
it's
a
little
hard
to
measure
exactly
how
much
that
is
because
we
did
have
to
redo
some
things
as
people
on
both
sides.
Realize,
though,
but
we
need
to
change
this
to
make
the
simulation
a
little
better
or
we're
missing
this,
and
so
we
did
have
to
regenerate
some
files.
B
We
were
able
to
use
up
to
2000
nodes
simultaneously
on
corey.
I
do
want
to
note
that
this
isn't
really
a
lower
or
an
upper
limit.
We
were
able
to
scale
it
up
more
on
theta,
but
we
tried
to
aim
toward
this
2000
core
wind
node
window
in
order
to
optimize
getting
through
the
queue
as
fast
as
possible,
so
there's
sort
of
balance
there
and
because
of
our
checkpointing,
it
doesn't
really
hurt
us
to
have
multiple
2000q
jobs
and
parcel
can
manage
that
five
year.
C
A
B
Yeah,
that's
exactly
the
issue,
so
it's
it's!
This
difference
in
time
that
runs
can
take
of
up
to
two
hours
and
because
we're
parallelizing
on
for
a
given
pointing
of
the
telescope
we
parallelize
over
the
sensors.
We
don't
have
a
particularly
smart
way
to
keep
a
node
just
completely
filled
at
all
times.
A
C
A
And
then
a
second
real,
quick
question,
which
was
on
the
next
slide,
where
you
said
that
you
needed
to
iterate
a
little
bit
right
that
as
people
kind
of
realized,
that
what
was
going
into
the
simulation
like
needed
change
or
like
parameters
needed?
Was
there
much
like
interactive
tuning
of
that
pipeline
chain?
Are
you
able
to
do
that
interactively
or
is
it
like?
Not
really,
you
have
to
regenerate
configuration
and
rerun
and
wait
and
like
keep
track
in
your
notebook
of
what
you
were
doing.
B
Because
if
one
object
changes
on
the
camera,
it
basically
should
change
other
objects
on
the
camera,
and
we
don't
have
a
good
way
of
changing
that
on
the
fly.
The
other
downside
to
this
is
a
lot
of
things.
Don't
get
recognized
until
you
process
the
data
and
the
processing
stack
needs
to
have
a
large
amount
of
the
data
already
handed
to
it
for
it
to
give
any
sort
of
real
results,
so
we
basically
had
to
partly
complete
runs
before
people
could
even
look
at
it
to
validate
it.
B
Thanks,
no
problem,
okay,
so
promise
to
talk
a
bit
about
the
future
perfect
time.
So
we
have
a
couple
of
lessons.
We
learned
in
particular
that
I
want
to
draw
attention
to.
The
first
is
actually
not
anything.
We
ran
against
at
nursk,
but
is
worth
mentioning
from
hbc's
standpoint,
which
is
the
parcel
driver.
B
It
can
become
disconnected.
Typically
in
our
use
cases,
it
was
run
on
a
login
node
and
if
the
login
node
goes
down,
for
any
reason,
parcel
driver
goes
down
too
and
then,
when
your
workers
launch
on
a
compute
resource,
they
look
for
the
parcel
driver
and
cannot
find
it.
It's
very
tragic.
The
workers
then
just
sit
on
the
compute
node
doing
nothing.
Everyone
is
very
sad.
B
Our
takeaway
from
this
was
that
it
would
be
useful
for
us
for
to
do
a
couple
of
things.
The
first
thing
is,
we
did
a
very
quick
solution,
which
is.
We
ran
the
parcel
driver
on
the
compute
resources,
since
we
can
tell
the
parcel
driver
everything
it's
going
to
need
to
do
in
advance.
We
didn't
really
need
to
keep
it
running
on
a
login
node
anyway.
B
That
does
mean
it
can't
communicate
across
compute
blocks
and
that's
sort
of
a
bummer,
but
it
works
to
first
order.
However,
we
are
very
interested
in
making
parcel
work
on
more
stable,
workflow
nodes,
which
I
know
a
lot
of
centers,
including
nurse,
are
looking
into
and
we're
also
looking
into
using
it
on
remote
cloud
services.
B
So,
in
particular
one
of
the
other
people
who
worked
on
this
project.
A
lot
yadu
was
exploring
running
this
running
your
parcel
driver
on
amazon
cloud
services,
for
example,
and
from
amazon
cloud
services.
You
would
then
send
out
jobs
to
different
compute
resources
that
you've
sshed
into
and
authorized,
and
so
you
could
conceivably
be
running
this
large
simulation
campaign
and
distributing
the
work
on
the
fly
to
quarry
and
theta,
and
I
don't
know,
summit
all
while
you
know,
as
soon
as
resources
become
available.
B
You
know
just
fill
it
up
with
work
and
just
basically
utilize
many
different
resources
simultaneously,
while
tracking
your
shared
providence,
it's
exciting,
it's
complicated.
It
probably
has
a
lot
of
problems
because
of
this
ssh
authorization
and
security
reasons
for
things
like
compute
nodes
at
a
at
argonne,
for
example,
computing
compute
nodes
in
argon
aren't
connected
to
the
internet,
but
it's
interesting.
B
Another
thing
we
want
to
explore
is
containers.
We
know
that
they
work,
but
there's
probably
some
costs
associated
with
this-
that
we
should
study
further
in
our
case,
because
the
average
run
time
on
a
given
sensor
is
like
10
hours,
a
10-minute
startup
time
on
a
container,
even
if
it's
that
slow,
doesn't
really
kill
us,
but
it
would
be
good
to
compare
in
the
future
how
that
startup
time
compares
to
time
saved
on,
say,
loading
in
python
libraries.
A
B
C
B
B
The
other
thing
we're
worried
about
is
things
like
when
we're
using
containers
in
order
to
load
in
all
our
python
libraries?
Are
we
actually
losing
from
running
optimized
python
libraries
for
particular
architectures,
and
is
there
a
way
we
can
work
around
that?
So
that's
the
sort
of
thing
we'd
like
to
explore
in
the
future
on
the
container
side
of
things
and
then,
like
I
said
this
parallelizing
within
each
visit,
does
lose
us
some
compute,
especially
toward
the
end
of
a
simulation
effort.
B
Just
due
to
specific,
slow
sensors
in
earlier
runs.
Actually
before
we
had
every
everything
hammered
out,
we
actually
had
sensors.
That
would
just
never
finish,
which
was
distressing,
so
the
msim
team
is
actually
doing
some
work
in
this
direction,
which
is
exploring
how
to
parallelize
within
the
sensor.
B
So
you
lose
some
memory
because
now,
instead
of
sharing
the
sky
memory
from
sensor
to
sensor
for
a
single
visit,
you're
now
to
get
telling
a
node,
please
simulate
this
one
sensor
from
this
one
visit
and
now
for
every
thread.
You
have
the
thread,
draw
a
separate
object
simultaneously,
there's
reasons
to
believe
that
that
might
actually
be
a
little
more
appropriate
because
it's
not
like
the
light
from
each
object
reaches
the
same
single
file
line.
D
Interesting,
so
I'm
not
as
up-to-date.
This
is
on
the
call,
so
they
can
comment,
but
you
know
each
job
is
is
is
as
far
as
storm
is
concerned.
It's
a
reservation
of
some
sort
and
I
know
there's
some
either
capability
or
potential
capability
and
storm
to
be
able
to
release
nodes.
If
you
don't
need
them
anymore,
within
a
job.
Does
that
does
that
capability
certainly
exist
currently?
B
D
B
A
B
D
B
Okay,
so
what
will
the
future
bring
for
us
honestly?
At
this
point,
we
need
to
see
lsst
desk
members
are
utilizing
these
data
products
to
validate
their
scientific
pipelines
and
we're
looking
into
using
this
sort
of
workflow
as
a
basis
for
other
things,
within
the
collaboration
from
image
production
to
and
by
image
production.
I
mean
processing
the
images
now
to
actually
doing
scientific
theory
pipelines,
but
we're
not
sure
if
we're
done.
B
We
don't
know
if
this
simulation
has
reached
the
point
where
it's
good
enough
or
if
we'll
need
to
do
smaller
simulations
that
are
more
detailed,
we're
pretty
sure
we
won't
need
a
larger
simulation
than
this.
We
think
for
most
cases
where
you
might
care
about
a
larger
signal,
we
can
just
kind
of
cheat
and
just
duplicate
the
edges,
but
we
might
need
a
smaller
and
more
detailed
simulation
with
more
complicated
transient
objects,
so
we
might
have
future
simulation
efforts,
but
we're
really
in
a
wait
and
see
mode
for
lsst
desk.
B
So
final
thing:
what
was
it
like
doing
this
as
a
first
round
postdoc?
So
I
just
want
to
say
my
background
coming
into
all
of
this
is
I'm
an
astrophysics
theorist.
I
worked
with
numerical
simulation
outputs
and
studied
weird
cosmological
effects
very
niche
stuff
that
seven
people
probably
cared
about
in
the
world.
B
B
Anyway,
basically,
I
had
every
new
skill
to
acquire
for
running
jobs
at
scale
on
hbc.
When
I
came
into
this
project
it
looked
like.
It
was
basically
supposed
to
be
the
mediator
between
computing
people
and
science,
people
to
make
sure
everything
gets
done
correctly.
I
started
doing
much
more
compute
over
time.
As
you
know,
I
kind
of
fell
into
it
loads.
Of
of
this
all
we
did
have
some
wasted
computing
time
at
some
points.
B
Just
due
to
various
coding
bugs
and
like
I
said
previously,
we
didn't
discover
errors
upstream.
That
meant
we
had
to
run
the
simulations
again
simple
things
like
sign.
Errors
can
slip
very
easily
when
it's
such
a
long
and
complicated
pipeline,
and
so
we
had
to
do
a
lot
of
validation
and
then
re-running
and
validation
personal
highs.
B
I
really
liked
when
they
waste
the
compute
time,
cancel
that
with
some
of
these
upstream
errors,
because
it
made
me
feel
a
lot
less
guilty
for
the
environment
and
then
I'm
really
happy
with
the
recognition
from
within
the
collaboration
and
from
outside
of
it
for
infrastructure
work,
because,
honestly,
a
lot
of
times,
infrastructure
work,
just
kind
of
gets,
pushed
under
the
radar
in
science
and
academia.
So
it's
nice
to
see
that
we're
starting
to
appreciate
it
more
as
a
community,
and
how
does
it
feel
now?
B
Because
it's
been
on
my
fourth
year
of
my
postdoc
now
because
of
covid.
It
was
hard
and
rewarding,
but
I
have
tool
sets
now
that
can
be
applicable
basically
anywhere.
I
can
take
this
partial
tool
set
and
just
take
it
wherever
I
want
and
be
able
to
run
on
a
high
performance
computing
system
fairly
easily,
because
it's
all
python
level
that
makes
it
very
very
multi-passive.
B
I
contributed
enough
on
this
infrastructure
effort
to
get
builder
status
in
lsst
desk.
So
that's
another
big
thumbs
up
for
me
and
I
love
the
mission
of
it
because
I'm
really
interested
in
understanding
the
evolution
of
the
universe.
Personally,
and
because
of
this
project,
I
basically
have
gained
a
really
good
understanding
of
how
parcel
works,
how
to
use
high
performance
computing
systems,
and
I
think
that
that
will
help
me
personally
to
move
in
a
more
informed
manner
for
developing
future
projects
and
eventually
proposing
my
own
projects.
B
B
B
D
Thank
you.
That
was
perfect.
I
have
a
question
about
the
so
you
have
these
data
products
make
sure
you
have
these
data
products
that
you
have
produced
and
people
are
going
to
use
them
for
exciting
things
like
you
said,
oh,
what?
How
does
it
work
or
is
there
an
agreement
on
attribution
from,
for
instance,
if
somebody
writes
a
paper
that
includes
all
this?
Do
you
get
to
be
a
co-author.
B
Desk
has
a
pretty
strong
publication
policy
that
handles
author
attribution
in
the
case
of
my
builder
status.
That
means
anyone
who
uses
these
images.
I
can
conceivably
add
myself
as
an
author
on
the
paper,
so
we
really
value
infrastructure
at
lsst
desk.
We
want
to
make
sure
those
people
get
credited
even
when
we
start
moving
on
to
science.
B
B
E
Cool
yes,
so
I
enjoyed
your
talk.
I
wanted
to
explore
your
thoughts
on
the
workflow
node
that
you
were
talking
about
that
you
wish.
You
know
you
wish
if
there
were
a
workflow
node
that
was
more
stable.
Are
there
other
requirements
in
that
wish
that
you
would
like
that
doesn't
go
like
for
a
single
facility
versus
that
the
grand
dream
of
you
know
multi-facility
orchestration?
What
what?
What
would
a
workflow
node
look
like
to
you
for
a
facility.
B
So
let
me
think
about
that.
So
with
the
understanding
that
I'm
not
really
good.
At
the
hardware
side,
we
would
want
really
fast
connections
to
compute
nodes
so
that
we
don't
get
overloaded.
If
we're
running
many
small
tasks
all
at
once,
I
could
see
that
being
potentially
an
issue
if
you're
trying
to
send
you
know
millions
of
tasks
in
a
short
time
for
various
machine
learning
projects,
so
you
would
want
to
be
able
to
have
plenty
of
connections
really
fast
with
the
compute
nodes.
B
B
B
I
imagine
a
workflow
node
would
probably
be
a
little
more
open
to
being
used
for
minor
compute
just
because
like,
for
example,
these
bundling
scripts.
We
want
to
be
able
to
do.
We
run
a
single
python
command
to
count
how
many
objects
are
available.
On
a
sensor
so
that
we
don't
simulate
sensors
with
nothing
on
it,
so
we
do
run
very
small
python
commands,
but
probably
larger
than
you
would
want
to
run
on
a
login
node.
D
A
Lowered
my
hands,
you
can
virtually
raise
it
again.
Well,
can
I
just
ask
my
question?
Yes,
please
do
all
right,
okay,
so
first
off,
congratulations
on
your
builder
status.
I
know
that
that's
like
one
to
two
years
of
dedicated
fte
work
before
you
get
that
the
question
I
had
was
the
thing
that
you
didn't
address
in
the
in
the
talk.
But
of
course
we
have
a
new
system
that
we're
bringing
up
right
now
and
it's
full
of
gpus,
and
so
I
had
two
questions
for
you.
A
A
On
it,
but
we
have
infrastructure
for
gpu-enabled
analytics
at
scale
and
I'm
dying
to
find
somebody
who
wants
to
like
take
a
quarter
of
the
machine-
and
you
know,
do
some
kind
of
you
know
clustering
calculation
over
that
in
real
time,
and
so
are
those
kinds
of
workloads
and
all
that
kind
of
interactivity
is
that
of
interest
to
anybody
at
all,
or
you
know,
is
it?
Is
it
is
it
just?
Are
we
just
barking
up
the
wrong
tree,
trying
to
find
people
to
do
that.
B
One
thing
I
will
say
is
that
for
the
gpu
side,
I
know
the
m7
team
is
working
on
approaches
that
will
be
more
suitable
for
using
gpus
in
the
future,
and
I
know
that
while
lsst
desk
might
not
have
another
major
image
simulation
campaign,
but
we
think
this
is
going
to
be
something
that
is
going
to
be
used
for
more
telescopes
in
the
future.
We
don't
think
it's
going
away,
basically
regarding
the
analysis,
workflow
and
using
them
on
gpus.
B
I
think
the
astrophysics
community
is
sort
of
slowly
starting
to
peel
in
that
direction,
but
it's
I
want
to
the
way
I
would
put
it
is
it's
a
little
tricky.
We
tend
to
have
things
that
require
very
large
stacks
of
information,
and
so
gpu
calculations
tend
not
to
actually
gain
us
too
much,
at
least
in
the
most
naive
approaches,
so
we're
still
trying
to
figure
out
the
best
way
to
package
together
tasks.
To
do
that.
F
B
F
B
D
Okay,
well
we're
getting
close
to
the
end.
I
want
to
thank
you
again
and
since
I
had
I
want
to
thank
roland
for
stepping
in
when
I
couldn't
connect,
for
whatever
reason
I
couldn't
connect
and
he
actually
helped
me
out
too.
I
did
have
a
couple
of
slides
at
the
beginning,
so
I
will
do
the
beginning
at
the
end
and
I'm
gonna
share
my
screen.
Real,
quick
and.
C
D
So
I
wanted
to
congratulate
you
again,
antonio,
and
remind
people
that
I
was
one
of
our
winners
of
the
nurse
high
performance
computing
achievement
awards
and,
as
you
heard
about
for
developing
innovative
workflows,
to
enable
using
hpc
at
scale
in
support
of
the
lst
desk
collaboration.
So
congratulations
and
if
you'll
send
me
an
address,
we'll
send
you
a
framed
copy
of
this
certificate.
D
And
then
the
previous
slide
to
this
would
have
been,
except
now
I
can't
make
it
events,
so
I'm
just
having
there
we
go
and
just
to
remind
people
that
this
is
the
first
in
a
series,
so
I
think
we're
off
to
a
really
great
start.
Next
week
we
have
david
vartanian
from
berkeley,
we're
talking
about
supernova,
and
these
will
be
every
wednesday
through
november
10th,
and
with
that
I
want
to
thank
you
again
for
joining
for
everybody
for
joining
us,
and
thank
you,
antonio.