We needed new language constructs (the matrix assembly) and a new type system for matrices that ties back to the graph to make it simple and fast. It is also not limited to FEM codes. It can be used to write any application that computes on sparse systems using linear algebra. Some application areas are optimization, machine learning, data analytics, fluid dynamics, image processing, and robotics.

For more information about the language, why it is designed the way it is, why it is fast, and what applications it can be used for, see the talk I gave at Microsoft Research last Friday: https://youtu.be/raPkxhHy5ro?t=40m32s

This is really cool! You have coded up some timesteppers in Simit already; any plans to release them as a standard package which would be officially optimized, or do you mostly expect users to just roll their own as needed?

Thanks! Yes, we have an `apps` directory in the source tree that we will add programs to. These programs are tested by our test suites, and will later be our performance regressions.

I'm actually working with some people at Adobe this summer to add Local-Global Solvers for ARAP energies (an optimization code) to the set of applications we provide there. We also have an implementation of PageRank.

I really like the idea of a graph-based solver since it makes a lot more sense for matrix assembly, but I'm concerned about committing to using simit because that necessarily implies abandoning interoperability with other established software. I do a lot of evolutionary structural optimization, but I need to also be able to interface with existing software libraries in order to complete the job. I'm not sure how feasible of a port it would be, but myself and many others would be very appreciative of a simit library for an established language. Surely those custom types could be emulated with the object systems found in modern languages?

Very valid concerns. If you use C++ it's easy to interoperate with Simit, since Simit is a C++ library with an online compiler that compile the time steppers. You build the graph using a C++ api and then you run a Simit program which updates the graph. It's similar to how you'd use OpenGL or DirectX (graphs instead of meshes and Simit programs instead of shaders). See https://youtu.be/raPkxhHy5ro?t=19m32s, and http://simit-lang.org/api for more information.

You're absolutely right that we could have provided all the functionality as C++ classes instead of compiling Simit programs through the Simit C++ API, and we might at some point. The reason why we didn't do this is that the language is complex enough that we felt it would be less user friendly. I definitely tried to design it as a library without a parser.

Yea, I'm not really sure what a new language buys them here. It seems they could have just released a library (not even tied to Matlab) with their highly tuned stiffness matrix assembly routines and their kernels...

If you only want the existing kernels, this makes sense. And in the long term it would be useful to have a library of common kernels for assembling FEM stiffness and mass matrices for various kinds of commonly-used elements, etc.

Compare to GSLS; the shading language is unnecessary if you only want to use a handful of pre-made shaders, but usually that is not case.