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-2010 Andrew Selle, Andy Lutimirski, Avi Robinson-Mosher, Bridget Vuong, Christopher Allocco, Craig Schroeder, Don Hatch, Douglas Enright, Duc Nguyen, 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, Mark A. Wicks, Michael Lentine, Michael Turitzin, Mike Rodgers, Neil Molino, Nick Rasmussen, Nipun Kwatra, Paul, James White, Rachel Weinstein, Ranjitha Kumar, Robert Bridson, Robert Travis, Ron Fedkiw, Ryan Kautzman, Sergey Koltakov, Sergey Levine, Silvia Salinas-Blemker, Tamar Shinar, Unnur Gretarsdottir, Wen Zheng, Zhaosheng Bao. All rights reserved.

    Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
    1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    2. 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, Craig Schroeder, Douglas Enright, 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, Michael Lentine, Neil Molino, Nipun Kwatra, Rachel Weinstein, Robert Bridson, Sergey Koltakov, Silvia Salinas-Blemker, Tamar Shinar, Wen Zheng, Zhaosheng Bao

    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.