[GSoC] Using WebGL to Accelerate Fluid Dynamics Simulation in the Browser - preparing proposal

[Piotr Janik]

Hi,

I'm a final year student of Computer Science at the AGH University of
Science and Technology in Cracow, Poland. I am really interested in
the project connected with accelerating fluid dynamics simulation
using WebGL. In fact, I'm almost sure that I will apply for it. I'm
writing to shortly introduce myself and prepare for creating a good
proposal.

My resume: http://dl.dropbox.com/u/7800669/PiotrJanikCV.pdf
As I said before, I'm studying towards M.Sc. in Computer Science. My
specialization is "Interactive Systems and Visualization". I combine
passion for the computer graphics-related technologies (rendering,
simulation, GPU programming) with the strong experience in web
technologies, as e.g. I was developing Eclipse Orion during last year
Google Summer of Code. Orion is a new open source project, entirely
focused on developing for the web, in the web. So I was mainly coding
in JavaScript (client-side) and Java (server-side). Besides that, I've
also created some smaller web projects, so I'm familiar with
JavaScript, Dojo, jQuery, AJAX, HTML and so on. WebGL is technology
which I am really curious about, so I would love to learn it.

When it comes to computer graphics-related areas, I have experience in
OpenGL programming, visualization and simulation. I developed a few
university projects, as well as commercial (e.g. real-time water
simulation with motion detection for interactive floors and surfaces).
What is the most important - I'm really passionate about this topics.
I'm also familiar with Nvidia CUDA technology and General-Purpose
Computation on Graphics Hardware for paralellization. In fact, I've
already created some projects connected with fluid and water
simulation, which are calculated on the GPU:
- Jos Stam stable fluids solver, CUDA-accelerated. Demo:
http://www.youtube.com/watch?v=1FkKrxGmfn0
- Shallow water simulation using hightfields. The parallelization of
wave calculations is done by GPGPU computation using GLSL shaders,
what can be useful in your project. Demo: http://www.youtube.com/watch?v=-GMNAMBV3dQ
So, I think that GSoC project "Using WebGL to Accelerate Fluid
Dynamics Simulation in the Browser" probably really fits closely my
experience, skills, interests and passions. Detailed information about
me can be found in my resume.

Last, but not least, I would like to gain some detailed information
about this project.
1) I've played for a while with Energy2D and Energy2D-JS. The Energy2D
is a mature app, when Energy2D-JS is rather an early prototype. In
your description of project, there is a sentence: "Finish implementing
the partial JavaScript port of the Energy2D engine." What do you mean
by that? Finish just convection and conduction engines or try to
implement similar features as Energy2D has (a lot of ready examples,
advanced editor, flexibility of placing insulators, fans, thermometers
and so on)? I'm just wondering what the scope of desired JS port of
Energy2D is.
2) I suppose that there are plenty of possibilities to simulate
convection, conduction and radiation. Can you provide me some papers
(if available) about solvers used in Energy2D / Energy2D-JS? Or should
I just read the source code (self-explaining I hope :))?

Best regards,
Piotr Janik

[Stephen Bannasch]

At 4:16 AM -0700 3/20/12, Piotr Janik wrote:
>Last, but not least, I would like to gain some detailed information
>about this project.
>1) I've played for a while with Energy2D and Energy2D-JS. The Energy2D
>is a mature app, when Energy2D-JS is rather an early prototype. In
>your description of project, there is a sentence: "Finish implementing
>the partial JavaScript port of the Energy2D engine." What do you mean
>by that? Finish just convection and conduction engines or try to
>implement similar features as Energy2D has (a lot of ready examples,
>advanced editor, flexibility of placing insulators, fans, thermometers
>and so on)? I'm just wondering what the scope of desired JS port of
>Energy2D is.

Hi Piotr,

Thanks so much for your interest.

I think the project could be divided into three stages. I think completion of one or more stages would be successful.

The first stage would be to get a working application running the conductivity and convective solvers and working with a subsetof the existing Energy2D model persistence format. I do not think it is important at this stage to get an authoring UI implemented.

One very important part to me that starts with the first stage is also developing automated unit tests for both model code and tests specifically for the thermodynamic performance.

These don't exist in Energy2D now (at least they didn't the last time I looked).

We are just starting to develop some physical chemistry tests for the Molecular Dynamics simulation we are developing.

See: http://lab.dev.concord.org/
Repo: https://github.com/concord-consortium/lab

and: https://github.com/concord-consortium/lab/blob/master/test/lab/molecules/molecules-test.js

Richard Klancer's been working on a branch integrating physical units and I expect more of these kind of test to showup there before it gets integrated back into the master branch:

https://github.com/concord-consortium/lab/compare/master...physical-units

One of the elements which I have included in the Lab project is the integration of being able to express Math in our html. Thispage on the Lennard-Jones Potential is just a draft but it shows the kind of features I'd like to see in the technical documentation:

http://lab.dev.concord.org/examples/lennard-jones-potential/lennard-jones-potential.html

The Lab project also shows some patterns of development I want to follow. It uses nodejs (based on Chromes V8 engine) for running tests of the code. I think the model as written in JavaScript should be able to be completely tested without ever running it in a browser. Testing in node runs VERY fast.

Check out the readme to see how the project is structured: http://lab.dev.concord.org/readme.html

So with a conductive and convective solver working and tested in JavaScript then the next steo would be developing an implementation in WebGL. I want some tests for the basic JavaScript model before doing the WebGL so we have ways of convincing ourselves the model is still working correctly.

There is some existing code we could look at -- I think WebGL is very well suited to performing these kinds of calculationsquickly -- but compared to writing, testing, and debugging in JavaScript -- writing and testing WebGL code is muchless agile.

The next stage would be to determine how to add an implementation of the photonic solver. This would first involve some research on needs and possible approaches to implementation.

There are some serious limitations of the current photonic solver in Energy2D that make it unable to model some simple solar energy simulations that I'd very much like to model.

For example I'd like to be able to model a simple flat plate solar hot air collector consisting of the following simple elements: a transparent material (glass, plastic), air plenums (vary the width of the gap), absorber (copper, aluminum, steel plate painted black), possibly another plenum/gap, insulation, environmental temperature, temperature of air flowing in.

Energy2d can do many parts of this ... but it doesn't model light as a spectral distribution and how it interacts with materials -- this would mean modeling reflection, transmission, absorption, and then re-emittance from materials.

So this stage starts with some more scenario development like I did above and then some research to see if this will be practical. If it turns out not to be practical then we can implement the existing Energyed solver.

This stage would mean the integration of additional elements of the existing Energy2D initial model state system.

I'd still like to have a version written and tested running in plain JavaScript but I would not be surprised if the WebGLimplementation was the only practical way to get the performance necessary to make it a fun tool for actually exploringsimulations.

The third stage -- if we get there would be to add an authoring interface to make it easier for people to create their own models on the web.

>2) I suppose that there are plenty of possibilities to simulate
>convection, conduction and radiation. Can you provide me some papers
>(if available) about solvers used in Energy2D / Energy2D-JS? Or should
>I just read the source code (self-explaining I hope :))?

I wrote Energy2D-JS just from reading the source for Energy2D -- I did end up reading many papers. I'll try and pull together some that I found useful in a later email.

[Piotr Janik]

Hi,

thank you for your reply! 

Firstly, I would like to present the initial plan of work. I divided it into stages, according to your suggestion. 

1. Energy2D to JavaScript stage:

 1.1 Implementation of the conductivity and convective solvers in plain JavaScript, based on Energy2D code.

 1.1 Unit tests of the model.

 1.2 Tests of the thermodynamic performance.

 1.3 Subset of the existing Energy2D model persistence format implementation [todo: define it more precisely].

2. WebGL optimization stage:

 2.1 WebGL implementation of conductivity and convective solvers.

 2.2 Testing WebGL model against plain JS model.

 2.3 Testing performance of WebGL model.

3. Photonic solver stage: [* optional - probably will be done]

 3.1 Research on possible approaches and needs connected with photonic solver.

 3.2 Decision whether to choose existing Enery2D photonic solver or another one.

 3.3 Implementation of the chosen solver in plain JavaScript.

 3.4 Implementation of the chosen solver in WebGL.

 3.5 Tests, performance comparison.

4. Authoring interface stage: [** optional - probably there will not be enough time to complete this stage]

 4.1 Research on possible approaches and needs.

 4.2 Implementation of the authoring interface.

Secondly, a bunch of questions:

I. What do you think about this plan, is it complete? I marked points 3 and 4 as optional, according to that:

I think the project could be divided into three stages. I think completion of one or more stages would be successful.

The first stage is necessary, the second seems to be quite challenging (so it is difficult to predict time needed for it). I would like to create a high quality, fully-tested application, rather than worrying about new features, before previous are tested. However, I am almost sure that three months are enough even for stage 3 (photonic solver).

II. "persistence format implementation" - I understand it, as a possibility of creating objects such as thermal sources, insulators, etc. Am I right? Just double-checking. What is desired scope of this implementation? 

III. Tests - the example you provided seems to be self-explaining. Of course, I will provide such tests. However, it looks like testing just "API" of the model, not physics itself. Should I prepare also tests for physics? For example, some easy examples with predictable results?

Best regards,

Piotr Janik

[Stephen Bannasch]

Piotr

Thanks for your continued interest!

At 8:26 PM +0200 3/26/12, Piotr Janik wrote:

Hi,

thank you for your reply!

Firstly, I would like to present the initial plan of work. I divided it into stages, according to your suggestion.

1. Energy2D to JavaScript stage:

 1.1 Implementation of the conductivity and convective solvers in plain JavaScript, basedon Energy2D code.

I have already done this in Energy2D-JS but certainly the code should be reviewed AND the convective solver is not working properly (it doesn't appear to have any effect).

 1.1 Unit tests of the model.

 1.2 Tests of the thermodynamic performance.

 1.3 Subset of the existing Energy2D model persistence format implementation [todo: define it more precisely].

I think we definitely need enough of this working to be able to create initial model state in JSON format for testing the thermodynamic performance of the model.

I would be good to be able to save the state of the model after running it -- but this would be a large amount of data. If we are actually doing this online AND it is important to be able to save the state of a model for a user we need to look atthe following possible optimizations:

- binary compression of state of property arrays

- transfer the data  using abilities in the latest browsers to transfer binary Blobs with ajax rather than text

2. WebGL optimization stage:

 2.1 WebGL implementation of conductivity and convective solvers.

 2.2 Testing WebGL model against plain JS model.

 2.3 Testing performance of WebGL model.

I expect the performance of the WebGL implementation to be MUCH faster than the plain JavaScript version. So it would be good to characterize this not just in increased performance but also in how much larger could the model be -- how might this increase in size benefit students/researchers.

The other effect of a large performance improvement is the ability to increase the time resolution of the simulation. I have a similar question here. How does this possibility benefit students/researchers.

3. Photonic solver stage: [* optional - probably will be done]

 3.1 Research on possible approaches and needs connected with photonic solver.

 3.2 Decision whether to choose existing Enery2D photonic solver or another one.

 3.3 Implementation of the chosen solver in plain JavaScript.

 3.4 Implementation of the chosen solver in WebGL.

 3.5 Tests, performance comparison.

4. Authoring interface stage: [** optional - probably there will not be enough time to complete this stage]

 4.1 Research on possible approaches and needs.

 4.2 Implementation of the authoring interface.

Secondly, a bunch of questions:

I. What do you think about this plan, is it complete? I marked points 3 and 4 as optional, according to that:

I think the project could be divided into three stages. I think completion of one or more stages would be successful.

The first stage is necessary, the second seems to be quite challenging (so it is difficult to predict time needed for it).

I'm hoping that with your OpenGL experience and Evgeny Demidov existing examples including a Fluid Dynamics solver: http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm it won't be too hard.

Evgeny has stated that it is his intent that his code be in the Public Domain so it is fine to derive our work from his (with credit of course).

At 8:07 AM +0400 8/16/11, Evgeny Demidov wrote:

What license are you releasing your fluid-dynamics scripts under?
Would you be willing to release your work under an existing open-source license?

   MIT: http://www.opensource.org/licenses/mit-license.php
   Simplified BSD: http://www.opensource.org/licenses/BSD-2-Clause

I'd prefer "public domain" (and don't like to add license text to every file). Shall I write it explicitly in my pages?
But of cause I can add any free license (you like) to this simple script. (And... I only "stand on giants shoulders" :)

I would like to create a high quality, fully-tested application, rather than worrying about new features, before previous are tested. However, I am almost sure that three months are enough even for stage 3 (photonic solver).

II. "persistence format implementation" - I understand it, as a possibility of creating objects such as thermal sources, insulators, etc. Am I right? Just double-checking. What is desired scope of this implementation?

Yes. If the initial model state can be loaded from a JSON file and the structure of the JSON file can describe the placing of the materials and objects we have implemented that will be a good start.

We should also implement the ability to save and load complete model state -- however unless this can be made fast enough this is probably only something a developer or tester might use.

We will have parallel work going on for various web application systems into which this can be integrated.

In order to share the results of this work with collaborators I will probably need to make progress on this part of the work inparallel with the work on he model and visualization -- but implementing a high quality, fully-tested model and visualization will take great focus and it is my experience that programmers are most productive when doing this kind of work when theyhave the fewest cognitive interruptions.

III. Tests - the example you provided seems to be self-explaining. Of course, I will provide such tests. However, it looks liketesting just "API" of the model, not physics itself. Should I prepare also tests for physics? For example, some easyexamples with predictable results?

Yes. The physics should be tested also, this is not nearly as simple as testing the JavaScript code of course.

-- 

-- Stephen Bannasch
   Director of Technology, Concord Consortium
   25 Love Lane, Concord, MA 01742
   direct and fax: 978 405-3209 main: 978 405 3200
   http://www.concord.org

[Piotr Janik]

Hi,

I think we definitely need enough of this working to be able to create initial model state in JSON format for testing the thermodynamic performance of the model.

Right.

I would be good to be able to save the state of the model after running it -- but this would be a large amount of data. If we are actually doing this online AND it is important to be able to save the state of a model for a user we need to look atthe following possible optimizations:

- binary compression of state of property arrays

- transfer the data  using abilities in the latest browsers to transfer binary Blobs with ajax rather than text

I agree, sending compressed binary seems to be good choice if we want such feature. Other option is the "server-side saving", but this will need authoring interface and I don't know if it's possible due to the number of users and size of data.

I expect the performance of the WebGL implementation to be MUCH faster than the plain JavaScript version. So it would be good to characterize this not just in increased performance but also in how much larger could the model be -- how might this increase in size benefit students/researchers.

The other effect of a large performance improvement is the ability to increase the time resolution of the simulation. I have a similar question here. How does this possibility benefit students/researchers.

I am sure that WebGL version will be much faster that JS version. It's difficult to predict performance gain, as I have never tried to implement physics simulation in JavaScript. However, according to my experience with C++, OpenGL and CUDA - parallel versions was 10 - 50 (in some cases even more) times faster than CPU versions. It's a lot.

http://nerget.com/fluidSim/ - calculations on CPU, 512x512 grid -> 1-2 fps.

http://ibiblio.org/e-notes/webgl/gpu/fluid.htm - WebGL, 512x512 grid -> 14-16 fps.

I think that we can obtain similar performance as Evgeny.

I think that higher grid and time resolution brings a visual quality and a more interesting course of the simulation (especially in complex cases). Improved performance brings the better interactivity. Sum of these features give us a tool, which is more playful => more educational. People won't loose their time waiting for effects of simulation too long. I think that such application has to be fast, impressive and interactive. 

I'm hoping that with your OpenGL experience and Evgeny Demidov existing examples including a Fluid Dynamics solver: http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm it won't be too hard.

I hope so. :) 

 

Best ragards,

Piotr Janik

[Piotr Janik]

Hi,

another question: what is desired, final form of the Energy2D-JS? Now it's a simple page, but it's a prototype. Are you planing to integrate this project with the Lab (https://github.com/concord-consortium/lab) or rather create independent website?

Best regards,

Piotr Janik

[Stephen Bannasch]

Hi Piotr,

At 4:43 PM +0200 3/28/12, Piotr Janik wrote:

Hi,

another question: what is desired, final form of the Energy2D-JS? Now it's a simple page, but it's a prototype. Are you planing to integrate this project with the Lab (https://github.com/concord-consortium/lab)

yes

or rather create independent website?

Also further along the Lab repo should be able to produce artifacts easily useable as libraries by other sites. So for example later it should be easy to integrating either the molecular dynamics or energy2djs visualizations into other sites.

This of course can happen via iframes (like a youtube service). We also want it to be easy for other folks to just reference our work as libraries whether they get the resources from github, a CDN, or copy them into their own projects.

So over the medium-term we should architect both energy2djs and the Lab project in general so it would be straightforward to in-effect create a stand-alone energy2djs site from it. This is of course a goal and statement of value at this point -- we willneed to develop and satisfy use cases to understand the specifics of these goals.

[Piotr Janik]

Hi,

ok, now I feel that I can prepare a draft of proposal. :)

Before I will send it through GSoC webpage, should I post it here or send you directly to get a feedback?

Would you like to specify further details of the project or ask me any question?

Best regards,

Piotr Janik

[Cynthia McIntyre]

Hi Piotr,

Sure – please go ahead and submit your proposal through the GSoC website. We can comment there and you’ll have a chance to revise if need be.

Thanks,
Cynthia

[Stephen Bannasch]

At 9:58 PM +0200 3/28/12, Piotr Janik wrote:
>Hi,
>
>ok, now I feel that I can prepare a draft of proposal. :)
>Before I will send it through GSoC webpage, should I post it here or send you directly to get a feedback?

Posting it here or sending directly to me is fine. I use stephen....@deanbrook.org for email lists (to get around annoyinggoogle group limitations) but sban...@concord.org is my main work email.

Of course sending to either of these addresses will get right to me.

>Would you like to specify further details of the project or ask me any question?

Probably after seeing your proposal draft!

[Piotr Janik]

Hi,

Posting it here or sending directly to me is fine. I use stephen....@deanbrook.org for email lists (to get around annoyinggoogle group limitations) but sban...@concord.org is my main work email.

I finally submitted my proposal through the GSoC webpage according to Cynthia suggestion. I can edit it during students application period, so I think it is the best place to work on it.

Direct URL to my proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/pjanik/1

If somebody is interested in it, but don't have an access - please let me know.

I would appreciate any comments or feedback! :)

Best regards,

Piotr Janik

[Chad Dorsey]

Thanks, Piotr. We look forward to reading it and giving feedback. 

Chad Dorsey

President and CEO

The Concord Consortium 

Best regards,

Piotr Janik

--
----
post message :cc-dev...@googlegroups.com
unsubscribe: cc-developer...@googlegroups.com
more options: http://groups.google.com/group/cc-developers?hl=en

[Piotr Janik]

Hi,

the time is counting down. :) Last minutes when I can edit my proposal. Don't you have any urgent comments? :)

Just in case - after students application deadline I am still open to discussion and changes.

Best regards,

Piotr Janik

[Chad Dorsey]

2012/4/6 Piotr Janik <janikp...@gmail.com>

Hi,

the time is counting down. :) Last minutes when I can edit my proposal. Don't you have any urgent comments? :)

:-) I think we're all just very excited, Piotr. We actually have the opportunity to "request more information" as we review the proposals after today, so this deadline doesn't close the door on further discussion/modification. I expect you'll hear more as we start to review and think about this.

--Chad

[Stephen Bannasch]

At 7:48 PM +0200 4/6/12, Piotr Janik wrote:
>Hi,
>
>the time is counting down. :) Last minutes when I can edit my proposal. Don't you have any urgent comments? :)
>Just in case - after students application deadline I am still open to discussion and changes.

Piotr,

I think your proposal is fine.

I think there is an interesting aspect to the work we haven't discussed -- but it's not critical that it be in the proposal.

We can implement computational physics very efficiently using features built-into WebGL -- but when doing computational physicswe have expectations that people doing graphics and visualizations don't necessarily have.

For example we will probably be using Floating Point Textures to hold various intermediate arrays of properties as part of the fluid dynamics modeling. Of course we won't be actually using them as OpenGL Textures -- instead we'll be re-purposingthem for our purposes.

The problem comes because in computational physics we also expect to be able to inspect and/or persist these arrays of properties. This may be difficult to do in WebGL.

This could be a case where our work will provide a very good example for extending the WebGL specification.