Background & History
PhysBAM was started in 1998 by Ronald Fedkiw when switching from Fortran to C++,
with the intention of writing code that could be shared by all of the various
projects he was involved in at the time. When he came to Stanford in 2000
together with his first group of mathematically inclined students they laid out
an organizational structure for numerical analysis, scientific computing and
physics based graphics simulation. Much of this persists to the present day in
the form of choices for data and algorithm structure and implementation. His
second group of students were much more inclined towards computer science which
led to a enhanced software abstraction on top of the mathematical abstractions,
templates, policies, iterators, etc. as well as parallel implementations such as
MPI. After Fedkiw received tenure, addressing the end of Moore's Law on
commodity hardware, he became more interested in the future of PhysBAM as it
relates to future architectures. This prompted a major organizational change of
the code into various smaller libraries (also beneficial as the code had grown
too big to compile on a 32 bit Windows platform), along with a more of a
kernelized view of the workhorse algorithms of the library.
The Current Goals ...
In 2010 a new vision for the future development of the code base was put
together in conjunction with plans to start releasing the code to the community
in a number of phases. Realistically speaking, the best way to grow the code
base to the next level seems to be through decentralization. At the present time
there are three avenues for accomplishing this:
SOFTWARE PIPELINE - PhysBAM had already undergone a first draft of the
rewrite that would be needed to achieve this breaking the library into different
components including numerical analysis tools and data structures, geometry
algorithms, and various simulation libraries, but the feeling was that a
pipeline reorganization might also be helpful. The first straw man version broke
the pipeline into Mesh Generation, Simulation Dynamics, Rendering, Sound, and
Virtual Characters where the bulk of the existing PhysBAM would be under
simulation (albeit meshing, rendering and articulated character simulation also
already exists in the library). Then if each piece of the pipeline was
spearheaded by different researchers at different universities, having a
champion would help foster the development of these independent parts of the
pipeline. In addition, the fact that people would use the pipeline from
beginning to end would foster interactivity between the various groups.
USER BASE - The second major change was to decentralize the ownership of
PhysBAM itself. Even among Fedkiw's own students there was some branching that
occurred when people graduated, and constantly folding those branches back in
lost feasibility over time. A large centralized library needs infrequent and
modular modification to fend off large disruptions of one's research. The last
rewrite of PhysBAM already went a long way towards addressing the modularity to
reduce conflicts in code development, although more is needed. And branched
projects with subsequent reintegration has proven a productive model. The
current straw man decentralization model was to stress the ownership of the
projects that exist in PhysBAM. Instead of small projects being seen as vehicles
to test the code, larger projects owned by one or many individuals would be seen
as research thrusts. The group of people involved in a certain project would be
responsible for all the code in it, and would be vested in the parts of PhysBAM
(and other libraries) that they make use of. Initial straw man projects were the
UCLA level set library, the Facial Simulation and Technology codes (FTS), and
the Water project for scalable water simulation.
SCALABILITY AND HARDWARE - The third aspect of current development concerns
the mapping to various architectures. Already much of PhysBAM works with MPI and
threads, and there have been concerted efforts to extend this to a greater
portion of the library as well as to ensure that MPI and threads work
efficiently together for data parallelization across nodes and algorithm
parallelization amongst shared memory cores on a node. In the end PhysBAM can be
seen as a software pipeline with a base of super users, and part of the goal is
to insulate those users from the underlying mapping to hardware as much as
possible. Currently in collaboration with Pat Hanrahan and Intel we are working
to explore, define, write and test a layer of code that would sit underneath
PhysBAM and serve this purpose.
Disclaimer
The purpose of PhysBAM is to serve as a respository for research ideas and to
foster the sharing of these ideas. However, as this library has been modified
significantly over time and will continue to evolve constantly in the future,
the state of the repository at any time may not accurately represent the full
capability of the code base. This means that people should refrain from
attributing any results obtained from this sample code to the behavior of the
PhysBAM library. In particular, statements of this sort in academic papers will
be heavily frowned upon.
For example, it will be meaningless to check out some version of PhysBAM, make
some changes to a certain project, run timing comparisons, and report these in
an academic paper, as certain parameters may easily be set incorrectly and
result in inaccurate representations of the performance.
Copyright
Copyright 1999-2018 Andrew Selle, Andy Lutimirski, Avi Robinson-Mosher, Bo Zhu, Bridget
Vuong, Christopher Allocco, Craig Schroeder, David Hyde, Dmitriy Karpman, Don Hatch, Douglas Enright, Duc
Nguyen, Ed Quigley, Eftychios Sifakis, Eilene Hao, Elliot English, Eran Guendelman, Fen
Zhao, Frank Losasso, Frederic Gibou, Geoffrey Irving, Huamin Wang, Igor Neverov, Jared
Go, Jeffrey Hellrung, Jeong-Mo Hong, Jerry Talton, Jiayi Chong, Jonathan Su, Jon
Gretarsson, Joseph Teran, Joyce Pan, Justin Solomon, Kevin Der, Kevin Li, Linhai Qiu, Mark A. Wicks, Matthew Cong, Michael Bao, Michael
Lentine, Michael Turitzin, Mike Rodgers, Minjae Lee, Mridul Aanjaneya, Neil Molino, Nick Rasmussen, Ning Jin, Nipun
Kwatra, Paul, James White, Rachel Weinstein, Rahul Sheth, Ranjitha Kumar, Robert Bridson, Robert
Travis, Ron Fedkiw, Ryan Kautzman, Saket Patkar, Sergey Koltakov, Sergey Levine, Silvia
Salinas-Blemker, Tamar Shinar, Unnur Gretarsdottir, Wen Zheng, Wenlong Lu, Winnie Lin, Yue Yu, Zhaosheng Bao, Zhenglin Geng. All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE PHYSBAM PROJECT ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE PHYSBAM PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Contributors
Faculty
Ronald Fedkiw
PhD Students
Andrew Selle, Avi Robinson-Mosher, Bo Zhu, Craig Schroeder, David Hyde, Dmitriy Karpman, Douglas Enright, Ed Quigley, Eftychios Sifakis, Elliot English, Eran Guendelman, Fen Zhao, Frank Losasso, Geoffrey Irving, Igor Neverov, Jared Go, Jeffrey Hellrung, Jerry Talton, Jonathan Su, Jon Gretarsson, Joseph Teran, Kevin Der, Kevin Li, Linhai Qiu, Matthew Cong, Michael Bao, Michael Lentine, Minjae Lee, Mridul Aanjaneya, Neil Molino, Ning Jin, Nipun Kwatra, Rachel Weinstein, Rahul Sheth, Robert Bridson, Saket Patkar, Sergey Koltakov, Silvia Salinas-Blemker, Tamar Shinar, Wen Zheng, Wenlong Lu, Winnie Lin, Yue Yu, Zhaosheng Bao, Zhenglin Geng
Postdocs
Duc Nguyen, Frederic Gibou, Jeong-Mo Hong
Masters/Undergraduate Students
Bridget Vuong, Christopher Allocco, Eilene Hao, Huamin Wang, Jiayi Chong, Joyce Pan, Justin Solomon, Michael Turitzin, Mike Rodgers, Ranjitha Kumar, Sergey Levine, Unnur Gretarsdottir
Others
Andy Lutimirski, Don Hatch, Mark A. Wicks, Nick Rasmussen, Paul-James White, Robert Travis, Ryan Kautzman
How to Fix a Bug
PhysBAM is a large library worked on by many people simultaneously, and bugs are
an inevitability. That said, when you believe you've found a bug, chances are
several pairs of eyes have looked at the same piece of code already. Therefore,
it is adviseable that one consults with others more familiar with the code
before declaring it a bug.
See FIXING_A_BUG.txt in the Documentation directory (see the code organization chart for where to find this)
for more details.
More details soon ...
Proposed Cosmetic Changes
As the library is intended to be used by many people across several
institutions, sweeping changes to the library will have the potential to affect
many people. As such, large changes will need to be proposed to the PhysBAM
user base. Purely cosmetic changes will be frowned upon, whereas those that
improve the library by making it more modular, etc. will be strongly
considered.
See PROPOSING_COSMETIC_CHANGES.txt in the Documentation directory (see the code organization chart for where to find this)
for more details.