Hello,

I agree completely with Merryn. Development is costly; dissemination, maintence and support even more so. The dilemma is that codes invariably get better when they are part of a coherent community. Perhaps, IMAG should contmeplate ways to support and participate in some worthy projects. There are a few NIH mechanisms designed for support and maintence of softwares. I am sure you are aware of them. I have added a few of our codes to Trent's list and will make binaries available to members of the IMAG group that want them. However, the topic of sharing should be one that we discuss a bit more generally. Maybe Jeff can speak to the SimTK experience, which could be a model for dissemination - but of course they got a boat load of money to do it.

Dan



Dear all,

As you will have seen if you read the additions I sent to Trent's document, I am involved in development of software for bioengineering simulation. This is a software package that has evolved though the efforts of numerous graduate students and research staff over approximately 20 years. My Institute has the attitude that open source software is a good way to accelerate model development, so about a year ago we started a project to reimplement our proprietary software in an open source version. We already had the graphics component of the software as open source. We hope that the end result will be a powerful computational package that will be useful to the biomedical modelling community.

This experience has highlighted a few issues that are relevant to our
discussion: 1. it is difficult to get funding to support infrastructural projects; 2. devoting time to such projects can lead to an initial decrease in concrete research outputs!

In terms of my goals for multi-scale modelling in mechanics, I am fortunate that the software tools I have at my disposal do an excellent job and I have access to the code to modify (hopefully improve) where necessary. I plan on archiving some of my model components in the cell ML repository, but this can only be done after the work is published (a first step in quality control for the repository).

Merryn


Dear All,

Maintaining whatever open source tools we have, continuing developing them and most importantly starting to glue them to each other seems to be a priority to progress research in modeling. This is not necessarily a computational priority but a priority within the social context of research.

I seriously believe that open source tools are very important, particularly for research development. E.g., I am using ABAQUS for simulating tissue deformation of the foot. The package has a lot convergence problems due to rigid body movements between bones. These issues have not been resolved by ABAQUS support, therefore we do some simulation tricks to make it work (in a cumbersome way). A large company such as ABAQUS, whose customer base is mostly industry, will not necessarily spend developer time to fix this issue. If ABAQUS is open source, I can go ahead and try to fix the problem myself. That's a bold assumption but having the possibility is very important for me. Another reason that makes open source software development important is the increased capacity to disseminate not only the simulation software but also the models. E.g. I can give you my ABAQUS input deck for the foot model. If you don't have ABAQUS, you need to find a converter to represent the model for your solver. And hopefully, your solver will have the capabilities to run the simulation. 

SimTk (www.simtk.org) at Stanford had a great initiative to establish this, particularly in the areas of neuromuscular and cardiovascular biomechanics. Jeff (Reinbolt), please add any areas if I forgot. I am aware that Jeff Weiss at University of Utah has an ongoing development of a finite element analysis package (FEBio) and other related software. 

It seems to me that development of open source simulation software has a different business model that generic open source software development.
For example, for generic software, you can start a site at sourceforge.net and if people are interested in, they start contributing. For simulation software, usually investigators start developing the tools in their labs, bring it to a mature state and then later make it public. In the generic case, collaborative development involves designing the software architecture where as in the simulation software, collaborative development can be simply to build plugins for the core.

Continuing maintenance and support are issues with open source. In addition, there are some legal issues, particularly when our institutions want to have our code to be proprietary. 

Obviously, all the information I have provided here is my personal opinion. Please correct me if I am wrong. I am simply hoping that this will trigger some discussion.

Best,

Ahmet