Notes from Feedback Sessions of August, 2002 Workshop
Rob, Blythe, and Darby
- Learning how to use modules to calculate the forward solution:
Modules aren't intuitive-relied upon DMW for module descriptions; need
more documentation organized by function with cross reference lists.
Managing fields required knowledge of things that aren't intuitive at all
but are very necessary, e.g., interpolants. FieldReader so general that
you need to go what's going downstream, but you need to know where its
going.
Rob: notion of SCIRun as a language, so you have to know the grammar,
syntax of that program-complex details.
- Input/output capabilities
There is a need to read more data file types directly, i.e., without the
need for converter programs.
- Interaction problems
It is often difficult to know what SCIRun is doing-when is it stuck or
when is it just busy? When you touch a UI button, what is it doing while
it's firing. You think its done, but it is not always there and ready
for output. There is a need for more robust global indicators of state,
the green bar on modules does not seem to work consistently or evoke
confidence in the users. It would be good to have better ways to monitor
the state of the program.
Dave: New version of the program will do this-auto execute is a great
added feature. When moving widgets, move things quite a bit before it
executes instead of on the fly. Choose when you want that and when you
don't. Keep interactivity high, but not to re-execute every time.
- Curved elements:
Is there somewhere to incorporate these? All of our geometric elements
have hard edges. SO to include anisotropies one must use straight sided
elements for everything, but to make it active you need to use higher
order elements that use a great deal of overhead.
- Quantitative visualization in SCIRun
Having more quantitative information in visualization would be useful.
Would be good to be able to look at numbers more easily. No contour
plotting in current version, though we do have banded shading to show the
contour between the bands.
- Documentation of data types and module functions
It would be good to have more information about which kind of data one
can use, what are the data types and how can one use them? Also
essential is more documentation about algorithms and the functional
options for each module.
- Documentation of modules
More explaination on the algorithms used (i.e.,the kind of
interpolation). Make more references to papers regarding
purpose, concepts and implementations. I know we have papers on our
main site, but they should be mentioned in our documentation
more.
- Documentation of develop information
There is a lack of documentation on developer side-module level and data
class, something in between viewing code and complex module description.
- Datasets
People wanted to know more about the contents of the data files, where
they came from, what they were.
- Science content in the workshops
It would be useful for some to have more science in the workshops rather
than just software description and practice. Rob: we plan to have
separate workshops to address the science interests of SCIRun/BioPSE
users in the future.
- Applications in other domains
Other areas of application could also benefit from SCIRun if we could add
some basic functionality for those fields. Examples include geophysics.
Especially interesting would be the expanded use of VR techniques to
allow users to interact with multidimensional datasets in interactive
manner. Even the creation of module interfaces that were
three-dimensional would be possible and allow more flexibility.
In the workshops, use more real applications, clinical applications,
special cases, real world examples.
- Meshing and segmentation tools
This is a large problem in SCIRun and there needs to be better support
for both steps.
- Linear algebra support
There needs to be more flexibility in the kinds of equations that SCIRun
can address and solve. In a related question, how much more
performance can one gain using SCIRun over Matlab solvers?
Rob/Dave: there is some support via PETSC, which we have linked to SCIRun
in the past (although there remains some question about SGI installation
problems). We have also built the bridge to Matlab to offer this
flexibility-we could add other bridges to numerical codes but we have
not yet found a robust replacement for PETSC.
- Using graphics cards for computation:
With the growth of power graphics cards comes the option of using their
on board computational power for simulations within SCIRun
- Event management in SCIRun
In response to a question about synchronized execution of network, Dave
gave an overview of the problem with existing system and why the new
scheduler-or something like it-is necessary to provide the necessary
level of control.
- Macro-modules
There is a need for tools to create and optimize networks, and to combine
functionality of existing modules into a macro-module with customizable
UI. Useful would be profiling tools to determine where the network is
spending its time. Similarly, would it be possible to define pieces of
networks that one could include in a master network description so that
.net files could become reusable?
- Time signals
Is it possible to attach a time signal in data? Dave: the Showleads
module shows a selection of leads over time-showfield shows a single
instant of one data value mapped over nodes.
- Flow control
There are not if, else statements the would permit more flexible control
of execution sequence with condition checking.
- More workshops
We should do more workshops in the future.
- Documentation:
-
- Developers asked for more documentation of the structure
of SCIRun, data structure, file formats, scheduling, etc.,
- There need to be listing of modules organized in different
ways so that users can identify the module they need.
- Inside of module descriptions, give a sample net or group
of modules where this module would be used.
- The sample networks need better documentation.
- Data types are poorly described both for users and
developers.
- Have a document that walks the user through the Field
files explaining exactly how they are structured
(especially things like where not to add spaces).
- Direct access to the source code does not seem to be
working and it was not clear how we support this at the
users end when when they do their own installation.
- The release notes on the web site do not contain enough
detail about changes in the new version.
- SCIRun could be expanded into the 3D environment. This would
include allowing a user to walk around his/her data in an immersive
environment or move a widget with a VR device.
- Migration to new versions:
- Developers asked that we make sure to
provide a clear migration path when we come out with new versions.
We should provide some external access to our discussions as we
move toward change so that external developers can follow and
perhaps even contribute to the discussion.
- Data interrogation:
- We should provide more flexible and detailed
access to the data, support more quantitative feedback, and allow
addition of new data on the fly.
- User feedback:
- the program does not report its activities
clearly enough; there are pauses in function in which nothing is
happening to tell the user what is going on
- Workshop content/organization:
-
- There should have been more detail about making modules.
- A tutorial similar to the users' for making modules would
be useful
- Integrate the lectures and the hands-on more closely so
that people can try out what they hear more quickly.
- Developers wanted more lab time, i.e., both days rather
than just on second day
- If possible, merge the users and develops so that the
developers get three days and the users two.
- Include some more realistic demos that show a more
realistic rendering of the design and use of the program,
e.g., create a network, build in a bug, detect and fix it,
perhaps the same when writing a module.
- Develop 2-3 levels of workshop for beginner, intermediate,
and advanced stages of developers
- Beta testing:
- Develop a set of beta testers who can take the
code pre-release and find problems for us.
These are specific comments about the Users' Tutorial
- In building the chapter 3C and chapter 4 nets, the
streamlines are automatically turned off in the ViewWindow object
list. Until the bug is fixed, we should tell the user to check the
object list and possibly have to turn on the Edges.
- If the user builds the chapter 5 net and executes it
without setting the SolveMatrix UI settings, SCIRun crashes. This
has been logged as a bug but should be noted in the tutorial until
then.
- Need a new image of the StreamLines UI (Figure 3.6)
with max steps as 200 not 2000.
- Make Figure 4.1 (the color-coded modules from chapter
3) a clickable image. A lot of users built their net from looking
at this image and and it would be much easier if they had a larger
image to look at.
- Re-shoot/create Figures 1.2.1 and 1.2.2 that makes the
directory structure more obvious. We can change `scratch' to be
something like path_to_my_data and have it be in red. Then users
will for sure know that they need to set it to be the path on their
machine. We also need to clarify about where this is.
- The sentence ``You should save this net as C.net,
which'' should be moved to after the UI settings have been set so
they are saved for future loads.
- Mention early on that it is a good idea to save your
nets frequently. Maybe do this in chapter 1 when we teach them how
to save a net. A lot of users lost a lot of work when SCIRun
crashed and they hadn't saved their net.
- We need to explain the tcl sliders better (i.e. the
ShowField Node Size slider) and how they work with the `+' and `-'
buttons.
- In the 3C net, the DirectInterpolate module now has a
UI (it doesn't show that in the figure) and the UI and settings
need to be explained and referenced in the tutorial.
- In building the tutorial chapter 3C and chapter 4 nets, the
streamlines are automatically turned off in the object list of the
ViewWindow. The user turns off nodes and faces and then thinks
that their streamlines didn't work. But really they are just
turned off. Until this is fixed, we should mention it in the
tutorial (see Documentation #1). This has been logged as bug
#421.
- The SolveMatrix Target Error defaults to 1.0. I don't know if
this is realistic, but when the user builds the chapter 5 tutorial
net, if they happen to execute the net before they change that
Target Error, SCIRun locks up just after attempting to bring up a
tcl error. Until this is changed, we should stress in the tutorial
the importance of setting this ui setting before execution (see
Documentation #2). This has been logged as bug # 422.
- Sometimes the tcl error comes up that it ``can't find the
$module_group variable''. This was very confusing for people at the
workshop. It has been logged as bug #423.
- Two of the pre-defined Views in the ViewWindow are the same. This
has been logged as a bug.
- One user connected a FieldReader, Gradient and ShowField and when
he tried to visualize the nodes, SCIRun threw an exception from an
Assert. One way to learn is to try and experiment with different
modules and data. But if you send something unexpected, SCIRun
crashes or throws exceptions. This may include looking at all the
Asserts and possibly changing them to a module error message.
- Component Wizard: when entering the Datatype for a port, have
drop-down menus of the SCIRun fields and an option to enter their
own.
- Component Wizard: The action of right clicking on the port to
edit the port information needs to be better documented or mention
inside the wizard. It is kind of a gotcha. If the port
information isn't filled out, the user gets a tcl error that is
very vague.
- It is unclear what the sample net files accomplish. There is a
place to fill out notes for a network. We need to make sure all of
these are filled out for our sample nets and that it is mentioned
in tutorial how to view these notes. Also, Dave suggests ways to
annotate a net. These could simply be labels attached to a module
or pipe. The user could add these to label parts to be specific to
the problem they are running.
- In order to test smaller parts of a net, users want some sort of
port plug. This would be some sort of visual representation that
the data will not flow downstream. Then a section of a net can be
tested without the time required to get new incoming data.
- There is no reliable way to tell the state of a module. The
convention is that question marks for the time mean that the module
doesn't know how much time it will take to finish, a yellow
progress bar means the module is waiting for data, and green means
that it is complete. Many modules don't use this. They just
linger in the question mark state and users had trouble telling if
things were compiling, still running, or if SCIRun had locked up.
- There was a request for more mesh generation tools for model
construction and manipulation.
- In general, users didn't like when modules would auto execute by
default. For example, if a ShowField UI setting is changed, the
module defaults to automatically execute. If the ShowField is
connected to a FieldReader, and the user hasn't specified a file,
the ShowField causes the FieldReader to execute and it receives an
error message. Dave suggested that if a module hasn't been
executed yet, that changes in the UI should not cause execution.
But after it has been executed once, it can re-execute with UI
changes. This could be accomplished with a GuiVar that is hidden
to the user. The automatic re-execution should also be a UI
setting similar to the one in the Isosurface UI. This also brought
up an idea to have the ViewWindow do partial rendering of geometry
as it is rotated or shifted.
- Bonnie said SCIRun needs more quantitative information for
visualizing.
- Bonnie also would like more meshing tools (I think to create
meshes) so they don't have to come with their own.
- Dave discussed the Macro Module idea.
- Conditional branching in dataflow.
- Datatypes with limits (subsampling).
- Have a GUI enhancement to be able to grab all connections from a
port, say an input port, and move them to another port. This would
be extremely helpful in building the Tutorial nets in places where
a new smaller net replaces a module (i.e. net to calculate solution
rather than just a FieldReader to read one in).
- Rob M mentioned having a ``Network of the Month'' in which we
described a new problem, and showed the appropriate modules to
solve the problem. This would build up our sample nets.
- Have Marty's talk about building a module/package be
interactive.
- Many participants use Matlab and wanted to know more about how to
integrate Matlab and SCIRun, what aspects of their work should be
done in Matlab vs. SCIRun (which solvers to use), and converting
their Matlab data to SCIRun data (the geometry) and vice versa.
For reference and as a reminder, here are the recommendations from the past
two years of the EAB.
March 5th 2002
Membersof the external advisory board who attended the meeting in SLC:
Prof Jim Bower, Cajal Neuroscience Center, Univ. of Texas, San Antonio
Dr John George, Los Alamos National Laboratory
Prof Peter Hunter (chair), Bioengineering Institute, University of Auckland, NZ
Mr Bill Lorensen, Electronic Systems Lab, GE Corporate R&D Center, NY
In March 2001 at the first meeting of the advisory board, several
recommendations were made which have clearly influenced the subsequent
developments of the Institute.
A major focus of the previous EAB's recommendations was to establish
stronger links to the collaborating investigators in particular and to the
user community as a whole.
Specifically,
- EAB suggestion
Convening an initial users meeting, where representatives of labs
see the software's use in a ''hands-on'' environment.
Response
Potential users have been invited to visit and see the software in
action and receive instruction in use and programming. There will
be a users' and developers' meeting for training and feedback in
May 2002.
- EAB suggestion
Dispatching staff to the labs of collaborators to help with the initial
installation and instruction.
Response
Local staff members have been assigned to collaborators,
preconfigured computers have been sent to collaborators, and
collaborators have visited Utah in order to learn and to feed into
the development of the software.
- EAB suggestion
Scheduling regular meetings with collaborating investigators,
staff, and students so that limitations and deficiencies of the
software are well understood by the program's own faculty and
staff. This ``customer-based'' feedback will be essential guidance
for future software development.
Response
The mechanisms of Bugzilla, email lists, and individual email
contact is being used to automate the receipt and processing of
user feedback in a way that ensures consistency and feeding of the
comments into the development process.
- EAB suggestion
The ties between SCI and commercial bioelectric ventures need to be
pursued more aggressively.
Response
A spin-off company (Visual Influence) has been created to manage
the commercialization of SCIRun/BioPSE and mechanisms have been
established with the University's Technology Transfer Office. For
example, a biomedical device design company has recently licensed a
version of BioPSE, through Visual Influence and the Technology
Transfer Office, to perform defibrillation device design.
- EAB suggestion
The group should work to achieve through publication in
peer-reviewed journals recognition of both their computer science
achievements and their collaborative scientific results.
Response
Reports of computer science results have been presented and
published in leading conference proceedings and peer reviewed
journals. The software is now reaching the level of sophistication
that is required for productive collaborative research and many
publications should result this year.
- The Center has been very good at adapting to change--in particular
the recognition of the need to move their software to Linux PCs with
the fast graphics cards now available. The EAB strongly supports
continuing efforts to make the software robust across platforms and
operating system versions.
- Whenever practicable, the Center should make use of guidance and
(open source) software from other research labs. It is important
that the Institute developers be aware of similar developments
going on in other labs. For example, the MRI geometric distortion
and field bias correction might benefit from a close connection to
developments in other laboratories.
- While recognizing that the Center has an objective of undertaking
basic research and transferring these developments to the
biological user community, a balance has to be maintained between
developing new algorithms in house and exploiting the work of other
groups. The EAB commends current attempts to incorporate third
party tools. We feel that in implementing a problem solving
software environment, a sustained effort to incorporate algorithms
from the community will be necessary. The success of the Center
depends on achieving a working relationship with other development
centers as well as biomedical scientists and clinicians, and
working with these groups will help propagate the use of the
software. An area of opportunity for BioPSE is the development of
techniques and applications that capitalize on the capability to
model realistic anatomy and conductivity tensors.
- The EAB endorses the Institute's clear desire to reach the
biological user community. However, to do so will require that the
software interfaces be less computer science oriented. Specifically
the control network interface may be unnecessarily complex for
initial use. We recognize that one level of user includes
bioengineers and others who do appreciate the technical aspects of
the user interfaces, but we strongly encourage the development of
pre-packaged applications for biologists which only present
biologically relevant information, but still allow the interested
user to delve down into control structures and code. Map3d appears
more user-driven and this has been under development for longer and
BioPSE should move in the same direction.
- The Center is to be commended for taking on board someone with an
industry background of delivering software to users, but it should
also consider taking on someone whose role is to represent the user
community. As the use of BioPSE grows it will be increasingly
important to have a specifically assigned user advocate within the
group to keep track of usage patterns, monitor the need for
backwards compatibility and to anticipate the changing needs of the
biological users.
- The group has clearly responded to the need for user/developer
documentation. One technical point is that the user group mailing
should be moderated, and the FAQ archives and mailing list (in fact
the whole website) should be searchable. However, with rapid
growth, outside developers and a growing user base, the need for
documentation will grow significantly. Therefore the group will
need to develop more dynamic documentation techniques including the
development of web-based/living documents, technical writing
expertise and other means to keep up with anticipated fast-paced
developments.
- There are clearly very good links with the cardiac community but
the EAB feels that the group needs to develop stronger connections
with the neural community.
- The Institute members are presenting their work very effectively
to the cardiac, visualization and bioengineering
communities. However, the EAB recommends increased presence at
neural conferences, such as the Society for Neuroscience annual
meeting, the annual Human Brain Mapping meeting, the Cognitive
Neuroscience meeting and the Computational Neuroscience (CNS)
meeting. Joint publications with biological users are important to
demonstrate the real use of the software.
- The real success of the Center will depend on having a growing set
of users who are independent of the Institute and the Center needs
to nurture this development. This inevitably means that the Center
will need to increasingly focus on education and training. One
strategy for gaining wide spread acceptance of BioPSE may be to
develop educational components for the software, for example, using
the software to train medical students in cardiac
electrophysiology.
Overall the EAB feels that the group is meeting their goals and progressing
very well. In particular the software engineering and management is
excellent and we feel has great potential with continued growth of the user
community. The development efforts should continue to focus on the existing
scientific base in the cardiac and neurophysiology, but these efforts could
very well expand into other application areas in the future, as driven by
the biomedical user community.
Notes from Feedback Sessions of August, 2002 Workshop
This document was generated using the
LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 3 -no_white -link 3 -no_navigation -no_math -html_version 3.2,math -show_section_numbers -local_icons notes
The translation was initiated by Rob Macleod on 2003-07-19
Rob Macleod
2003-07-19