Archive for November 2011

Open source spin-off projects

November 23rd, 2011 by Scott Cytacki

Developers at the Concord Consortium work on a wide variety of grants, and in the process we create reusable pieces of code. With a little work some of these reusable bits of code can be turned into spin-off projects that have a life of their own. In my opinion these spin-off projects have the best potential for broad long-term impact.

Recently I was reminded about these types of spin-off projects when Richard Klancer relayed a conversation he had with Jeremy Ashkenas. Jeremy has been very successful in this area during his work on DocumentCloud.

We strive to make our individual projects successful, but often their technology is complex and not easy to re-use. The impact of the individual project is the research enabled by the technology, or demonstrating the usefulness of a new concept. However, the collection of technologies used in the project normally becomes a one-off: it is no longer used once the project reaches its 2-5 year end.

Alternatively, within these complex projects are reusable pieces of code that are simple, easy to maintain, and solve a common need. Because of this they have potential to be popular outside of our organization. We do have some partial successes with spin-offs like this.

  • MozSwing – mostly abandoned, though it was used in at least one commercial product
  • Java Sensor Library – collection of JAR files for communicating with a variety of sensors available in schools
  • RaphaelViews – SproutCore 1.x library for creating fully fledged SproutCore 1.x views with Raphael
  • SproutCore TestDriver – ruby gem for running SproutCore Jasmine and QUnit tests on a CI server

None of these has become a successful open source spin-off project. To be successful, such a project needs an active community that includes both developers and users. And the amount of work required to maintain it by Concord Consortium developers needs to be small enough that it doesn’t prevent us from reaching the goals of individual grant projects.

The MozSwing project would require too much maintenance. The Java sensor project is too intertwined in our other Java code. RaphaelViews and CapybaraTestrunner don’t have the above problems, but they have not been polished and announced to the right audience. I don’t think the polishing would take a lot of effort, but making the time and finding the support to do so is hard. We are always working on the next big thing, so it takes discipline to really finish up what is already working internally.

There are more potential open source spin-off projects within the technology at the Concord Consortium that have wider audiences than the ones above. With luck, we can change our culture to encourage this work more and make more of this great stuff accessible.

Do you agree that we should be spinning off more projects? Do you have experience with spinning off projects like these? Any tips?

Soft body dynamics in the Molecular Workbench

November 18th, 2011 by Charles Xie
For a long time, some of my colleagues joked about my work on the Molecular Workbench as some trick to randomize "bouncing balls in a box." Part of their impressions came from the overly demonstrated gas simulations that are conveniently linked to some widely taught physical science concepts.

To do justice to the Molecular Workbench, I intend to write a series of blog posts that show the unknown facts about what it is capable of doing. This series is not to defend the work I have done. It is more about digging the potential of computational science and see what favor it can do for science education.

My plain answer to my colleagues' comment is that: "It is something in a box, but not just bouncing balls." One of the things it does more than bouncing balls is its capacity in soft body dynamics.

Soft body dynamics is a subject that focuses on visually realistic physical simulations of the motion of soft bodies (or deformable objects). Why is "soft body" important? The answer is that most biological systems are soft--at the macroscopic level or at the microscopic level. Without the biomechanical flexibility of human body, we would be quite different.Without the biomolecular flexibility of cells, there probably would not be life (e.g., it would not be possible for molecules to move in and out cells).

In many cases when we model microscopic interactions, we don't really need to know how every atom in the system is doing, not only because tracking every single atom in a huge biomolecule is nearly impossible but also it is not necessary to know those details for a basic understanding. Scientists often need to simplify a complex system in order to be able to focus on important aspects. The need is even more so in teaching--the cognitive load for students should be minimized in order to effectively convey the conceptual picture in a short time.

So an interesting question is how flexible biological objects can be simulated in a meaningful way. One approach is to model a soft body as a network of particles connected by elastic constraints (linear, angular, or torsional). This is often known as the mass-spring model in the computer graphics community. In the case of a 2D model, these discrete particles are placed along the edge of a 2D object. In the case of a 3D model, these particles are placed on the surface mesh of a 3D object. Physical interactions among soft bodies are then made possible by giving these particles properties such as a stiff repulsive core, an attractive force, or an electric charge. This allows many interesting phenomena to be modeled, such as self-assembly, docking, and so on.


The above animation shows a box with bouncing balls and swimming "worms," produced by the Molecular Workbench. Does the dynamics of these long soft bodies show some kind of "wormy" behavior that is clearly not that of bouncy balls?

In fact, the mass-spring model implemented in the Molecular Workbench has a number of applications in artificial life ranging from digital fish to digital cells. See this page for a nice summary.

Rainbow, iron, and gray

November 15th, 2011 by Charles Xie

Energy2D is our signature software for simulating invisible energy flow in natural and man-made systems. One of its view shows the temperature distribution calculated by the physics engine. This view renders images similar to what an infrared camera shows. Most IR cameras have a few color palettes for the user to choose. So I think we should provide those options in Energy2D, too.

This blog post shows the three color palettes commonly used in IR imagery that were implemented in Energy2D: rainbow, iron, and gray. I guess the IR folks call the second one "iron" because it looks like the color of an iron bar heated to glow.


A criticism of using colorful heat maps to visualize distributions is the possibility of twisting data and therefore creating illusions--because our perception of color does not go linearly with the linear increase of the RGB values. You can compare these three images and see if that is a problem.

I have blogged a lot about how great an inquiry tool IR imaging represents. The resemblance of Energy2D's temperature patterns to IR images indicates a learning possibility of using simulations to deliver some of the nice features that an IR camera gives--before the prices of IR cameras come down to a couple of hundred dollars.


If you would like to show how they look in real simulations, go to Energy2D's home page and explore from there.



"Heart"-shape house? "Seastar"-shape house?

November 10th, 2011 by Charles Xie
In just a few hours, two students were capable of designing ten houses using our Energy3D software, about which they had no prior experience at all. Among them there is one with a floor plan of the shape of a heart and another the shape of a sea star.


We were excited about the ease of use of Energy3D for designing complex houses. However, there are a few concerns. First, these two houses have complicated shapes that take a long time to scale up on cardstock and assemble from the cutout pieces. With a powerful CAD tool like this, students' creativity can be unleashed--they are capable of coming up with sophisticated designs. But computer models are not the final destinations. They are thinking and visualization tools that help students conceptualize their designs. Our goal in engineering projects is to have them make real systems after computer models. If a computer model is too complex, students may not be able to make the real system within a given amount of time in the classroom. On the other hand, if a computer model is inflexible and few variations are feasible, students will quickly be bored. It may be a bad idea to limit the design capacity to simple models with only a handful of features and options. So where is the balance point?

Another thing we should watch out is that students who are too focused on designing the fancy shapes like these may pay less attention to the science and engineering principles we hope to teach in this engineering design challenge--we want them to think about designs that can achieve maximum livability and be energy-efficient. What kind of intelligence can we build into our CAD tool to provide just-in-time instructions that guide their designs?