Introduction to a new web-based functional MRI study management system.

1. Overview of
Analysis Result Manager
(ARM)
Jeremy Magland
27 October, 2011
brainomics group @ Penn

3. Motivations for ARM
O Motivation #1:
Visualization
I wanted to be able to
SEE my fMRI data,
intermediate files, and
processing results,
and to share these
with my collaborators.

4. Motivations for ARM
O Motivation #2: Bone-Water Study
Real-time Study Subject AP-1
Data Management REAL_23 Localizer
Sample Session 1 Baseline, TR=300
Organize fMRI data text Raw fMRI series Follow-up 1, TR=300
About Anatomic localizer
on a central server, study Session 2 Bone-Water Study
Stuff REAL_36 Subject AP-1
and access it from To fill Session 1 Localizer
sapace Session 2 Baseline, TR=300
anywhere (cloud Follow-up 1, TR=300
style)

5. Motivations for ARM
O Motivation #3:
Computing Power
Utilize the processing
power of server
computers (CPU
power, RAM,
automatic parallel
processing)

6. Motivations for ARM
O Motivation #4:
Provenance Tracking
Track the processing
steps required to
reproduce each
intermediate object and
processing result.
Advantages:
* reproducibility
* auto-non-redundant
processing

7. Challenge: Richly Interactive,
Web-based Data Visualization
O Browser-based
O RemoteWidgets:
applications are very
convenient but often O Framework for
have limited developing
functionality.
O Desktop applications desktop
can have rich applications in Qt4
functionality. However with option to
there are some cons:
O software
deploy on browser.
downloads/updates
O OS incompatibility
O Security risks
O Etc.

8. RemoteWidgets: Overview
Seegull
O Write a GUI for the
web using only one ARM
programming
language: Qt4/C++
O Rapid development Pickles
of highly interactive
web applications.
O Direct access to Math Puppy
server-side
processes.

9. RemoteWidgets:
One App, Two Access Options
Seegull in Web Browser
O Web Browser
Interface (jQuery)
O Desktop Interface
(thin client
download)
Seegull on Desktop

10. RemoteWidgets: Hello, World!

11. RemoteWidgets:
Server-Side Event Handling
O Handling GUI events is as easy as
connecting Qt signals and slots on the
server… no javascript coding needed.

12. RemoteWidgets: Idea
O Interactive, desktop-style visualization tools
available from the convenience of a web
browser.

13. Analysis Result Manager
(ARM)
O Cloud-based
approach to fMRI
data management,
visualization, and
analysis.
O ARM is a
RemoteWidgets
application, and can
therefore be
accessed remotely
via a web browser.

14. Tradeoff Between
Scripting and GUI for fMRI Processing
O Scripting is way more powerful for research purposes.
And, if you have a good script interface, you could always
throw a GUI on top of it.
O But… some problems with Matlab-style scripting:
O Need to manually shuffle data around in
files/folders
O Not easy to remember exactly which parameters
were used >2 days ago
O Run a 10-hour script, and discover the last line
had a bug.

15. ARM: Script-Generated Workflows
With Robust Tracking of Provenance Data
The multi-threaded processing The script immediately sets up
module then executes each a workflow, creating all
processors as soon as all input intermediate and result objects
objects have been defined. ahead of the processing,
storing detailed information
about how objects are related
via processes.

16. Processors are Generic Plugins
C++ Wrappers (for FSL, SPM, etc)
Views are also plugins… (custom views of custom datatypes)

17. Live ARM Demonstration
O Upload Scan Data O View processing results and
O Online view, change view intermediate files.
settings O Show provenance (process
O Super-efficient browsing of huge history) of the output objects.
data files. O Explain that changing scan id’s
O Browser access to same app and even names of the
O View example script processors causes no
problems. Key assumption:
O Running script does nothing objects, once created, never
because processing has already change.
completed
O Clean up by deleting results. (In
O Change design function and re- future, intermediate files will be
run script – show how auto-removed after a period if
processes are queued and they are no longer linked to
executed in proper order (No results)
redundant processing).
O In development – share a
processing result by a button
click.

18. Live Seegull Demonstration
O It is often desirable to SHARE results with others.
But you don’t always want to give them access to a
huge system. Furthermore, since ARM is highly
dynamic, you want to be sure that a result, once
shared, is available for ever after (snapshot of a
result)
O Hence, Seegull

19. Summary and Future
O Share interactive views of data
O Taking full advantage of cloud technology
to manage, process, visualize, compare
fMRI data analyses
O Script-generated workflows
O Automatic provenance tracking
O Convenient access via web browser
O Import publicly available fMRI studies into
system (powerful meta-analyses)

20. Especially Thank You to…
O Anna Rose Childress
O Felix Wehrli
O Charlie Epstein
And…
O Benny Lam O John Detre O Chris Tjoa
O Oscar Bartra O Jesse Lupardus O Brian Avants
O Kimberly Young O Ning Zhang
O Dan Willard O Cheng Li
O Rob Fabianski O Ze Wang