The Construct(brandonpelfrey.com)
brandonpelfrey.com
The Construct
http://www.brandonpelfrey.com/blog/the-construct/
4 comments
Was the title change really necessary? No one knows what "The Construct" is, but a lot of people know what "Fluid Simulation in 9 Lines of Code, and More on Fast Simulation Prototyping" is.
Seriously, WTF is "The Construct"? The original title was much more informative. I'm not against editing headlines, but throwing away an informative one for something my teenage brother would name a band is not helpful.
I did something far less sophisticated many years ago for my undergraduate degree. Basically a Navier-Stokes solver using finite-differencing techniques to model gas particulates in an enclosed area. This was to support a larger framework to pinpoint things like electrical fires using sensors in something like the space shuttle. Originally written in C++ but ported to Fortran 90 as my grad student couldn't read C++ (or maybe it was my C++).
The technique here which I guess is effectively finite element was far more difficult to implement at the time and reserved for professional tools like Fluent (my company today uses Fluent for this stuff today though not me directly and I'm sure we pay quite a bit for it.)
I browsed through the code and it was far better than anything I ever wrote at university. I think its deceptive to say 9 lines of code given the volume of support libraries but I would have killed to get my hands on this 17 years ago. Boundary conditions and configuring the actual volume was actually the hard part and took a majority of my time back then and I'm guessing that probably hasn't changed. Anyway cool stuff if only a few years late for me to make use of.
The technique here which I guess is effectively finite element was far more difficult to implement at the time and reserved for professional tools like Fluent (my company today uses Fluent for this stuff today though not me directly and I'm sure we pay quite a bit for it.)
I browsed through the code and it was far better than anything I ever wrote at university. I think its deceptive to say 9 lines of code given the volume of support libraries but I would have killed to get my hands on this 17 years ago. Boundary conditions and configuring the actual volume was actually the hard part and took a majority of my time back then and I'm guessing that probably hasn't changed. Anyway cool stuff if only a few years late for me to make use of.
The thing that stood out for me, and made me think "nice", was Brandon's idea of creating a vector field type. One can then apply operators directly to the field, without having to think in terms of lower level constructs. In that sense, I think the '9-lines' claim is fair.
Any comments from anyone (Brandon?), as to whether configuration and boundary conditions can be simply applied to the vector field type?
Any comments from anyone (Brandon?), as to whether configuration and boundary conditions can be simply applied to the vector field type?
ARGH. STOP WITH THE RENAMING OF EXISTING STORIES ALREADY!
A language like APL has made work of this kind far simpler for quite some time. I was doing basic fluid simulation work and planetary/orbital calculation with APL at least 15 years ago.
Starting from something like raw C or C++ means that the ability to express problems at this level of complexity is impossible without first writing a library to create the "words" and "verbs" you'll need. Then it's a piece of cake.
A language like APL gets you to a much more expressive level right away. Exploring more complex problems from that vantage point is far simpler (and a lot more fun in my opinion).
Starting from something like raw C or C++ means that the ability to express problems at this level of complexity is impossible without first writing a library to create the "words" and "verbs" you'll need. Then it's a piece of cake.
A language like APL gets you to a much more expressive level right away. Exploring more complex problems from that vantage point is far simpler (and a lot more fun in my opinion).