Non-physical results with Fluid Sim

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

Post Reply
aquarien
Posts: 0
Joined: Tue Feb 05, 2008 10:26 pm
Location: Tulsa OK USA

Non-physical results with Fluid Sim

Post by aquarien » Tue Feb 05, 2008 11:02 pm

I'm not sure if this is the right forum. Apologies if not. I started trying to learn and use the Fluid Simulation package to fit to a set of real flume data - a simplified physical model of dam breach (www.aquarien.com/flumexp/index.html). It's not going very smoothly, and I'd sure like some changes to make it more mathematically accurate, physically realistic, and usable for scientific and engineering models. If
that works like that, then you could use the underlying code for much more realistic models of dam breach (www.impact-project.net). Or, you could use it to design innovative flood-control or irrigation-control weirs, say, that would be easy to construct in developing countries. Or, agricultural engineering students could use it to study irrigation system designs.

If you could pass it along to whoever is maintaining the fluid solver, I think that it does not apply the "realworld-size" consistently to fluid "inflow" objects. The physical logic here seems flawed. I have data from the physical flume model, in feet instead of meters. I set up a similar flume model in blender with an inflow object at one end about 9 feet wide by 5 ft high by 1/2 foot thick in a tank about 10x20 by 5 ft high. I set the realworld-size to 0.305 (one foot per major division) and the inflow object to "init volume" with an inflow velocity of 0.028 in the x-direction. This should have produced an inflow of one cubic foot per second (cfs).

I simulated a flow of 10 seconds at 25 fps with resolution of 50. Instead of 10 cubic feet in the tank, I got about 326. That is about ten cubic meters. I didn't measure from the sides of the tank, but from the edges of the fluid volume, which refuses to actually touch the tank. So there seems to be a problem with conservation of mass and boundary conditions as well. I ran some others. With the realworld-size set to 1.0, and the fluid inflow object set to init shell, it generates 146.7 cubic meters in ten seconds, instead of 10 cubic meters. Realworld-size does not seem to be a physical scaling factor of the kind used in hydraulic research models.

Please pass that along. It would be nice to get those problems fixed. It would also be nice if the model produced numbers for the conservation of mass accuracy, inflows and outflows, and if it would tell us ahead of time if the resolution is too coarse for it to actually produce a fluid mesh in the domain. Sometimes it just gives a blank screen.

A mesh plane will not produce flow as an inflow object unless the resolution is fine enough, with no indication but trial and error how that is. In scientific modeling, one can calculate stability criteria that tell one beforehand how fine the resolution must be. What is it for Fluid Sim? It would be nice if mesh planes of any shape could actually be used as inflow and outflow objects to simulate valid BCs in math models. I finally got a 4x9 mesh plane for an inflow object to work at resolution = 100, realworld-size = 1, and am running that at x-inflow = 0.028. At frame 25 of 250, 1 second, it looks like it is still overproducing fluid, by a factor in the range of 5 to 8.

Among other things, I tried to calibrate a fluid sim by turning off the tap and letting the remaining fluid settle into a container to be measured. There doesn't seem to be any way to do it. Unfortunately, the generated fluid is defined as "domain" instead of an additional fluid object, as it should be. That makes it difficult to do some normal physical things, like turning off the tap. So if you remove the fluid inflow, it stops on an error stating that there is no fluid object present.

I tried to change the inflow object to a fluid at frame 25. No go. The sim lost the large fluid blob entirely, left with a few drops falling down. Also it would not start at frame 25 using the previous information, as I tried to request. It insisted on starting all over at frame 0 again. I tried to define the domain as fluid and put in another domain. No go again.

Also, starting at frame 1 does not make mathematical sense. Your initial conditions are at frame zero, which never shows. But frame 1 looks like the initial conditions. If you don't have a frame 0, then it gets hard to click on the fluid inflow to change it (the initial conditions), when it is entirely covered.

Perhaps the first tutorials don't show how to change physical conditions during the simulation, if it can be done. Nor can I see any way to import initial conditions from a frame in a previous simulation. Nor can I see any way to directly measure the (total) volume of the fluid in a frame.

I also notice that the turbulence from an inflow object looks way too coarse and violent. Not to mention non-physical. For example, a tombstone shaped inflow object, with a horizontal flow out of a vertical large face, produces obvious extra horizontal flow along the edges, and slightly less so in an x-shape from corner to corner, leaving lumpy triangular pockets in between. A cylinder horizontal in the y-dir, with flow in the x-dir, also produces obvious extra flow from the capped ends. It looks really weird. And you should see the spurts of water leaping up out of the leading edge of high flow. :shock: It looks like an alien invasion or horror SFX.

I downloaded Nil Thuerey's scientific papers on the Lattice Boltzman Method used in Fluid Sim, and what Blender uses and produces does not jibe with that kind of modeling. I may still make some use of Fluid Sim for uncalibrated graphic demonstration, but not as a calibrated scientific tool. I think it has some real potential if someone could fix the kludges.
Regards, aquarien
www.aquarien.com

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Re: Non-physical results with Fluid Sim

Post by matt_e » Wed Feb 06, 2008 1:04 am

aquarien wrote:I may still make some use of Fluid Sim for uncalibrated graphic demonstration, but not as a calibrated scientific tool. I think it has some real potential if someone could fix the kludges.
Perhaps Nils can answer some of these questions if he's around (though he's been a bit absent recently), however it should be said that Blender is definitely not intended as a calibrated scientific tool, it's for making art and 'good looking' animations. If scientific accuracy is what you want, you're using the wrong tool for the job.

aquarien
Posts: 0
Joined: Tue Feb 05, 2008 10:26 pm
Location: Tulsa OK USA

Re: Non-physical results with Fluid Sim

Post by aquarien » Wed Feb 06, 2008 5:26 pm

Thanks, but I went to him first. He has moved on and gotten very busy with other things. Can anyone else tell me how the guts of Fluid Sim work? Is it possible to change or add capability with Fortram-generated DLLs in Windows? Please pass this along to the developer community.

The "right tool for the job" costs thousands of dollars the last time I looked, and I live on disability. A "scientific tool" is whatever you make of it. You have to jump through a lot of hoops to get graphical results in most scientific applications at the level of model construction available in Blender. Plus, they take a longer time to learn. Years ago, when I was better off, I bought Macsyma with PDEase. I still haven't learned how to use it, it's so cumbersome and confusing. I started working with Blender about the middle of January (It's Feb 6 now), and can make a simplified model I need for evidence in a court case already.

Adding capability here is a very worthwhile goal, considering how many science students need to see how things work. Here in the USA, our primary and secondary school students are even years behind in math and science compared to most other developed nations, and some developing nations I imagine. I got a simple simulation to run on my used 900 MHz laptop with a low-capability graphics display in a reasonable time. I don't care where the tool comes from, so long as it is physically valid. I say again, Blender has some real potential in science research and education.
Regards, aquarien
www.aquarien.com

TERRAINFIGHTER
Posts: 0
Joined: Sat Jan 19, 2008 3:07 am

Post by TERRAINFIGHTER » Wed Feb 06, 2008 11:52 pm

I don't exactly know all the guts of the system yet, but if it helps any you can make changes that occur during the animation.


To do this, change a window to the ipo editor, select the object you want to edit, click on the Object drop-down box in the ipo editor, and select Fluidism.

From there, you can change many of the settings for during-animation;
in order to turn on and off an inflow, create an 'Active' ipo, 0 = disabled, > 0 = enabled.


As for getting realistic amount of fluids, I think the way it works is by adding the inflow object's mesh worth of water and adding however much has left the inflow each frame.

n_t
Posts: 0
Joined: Tue Jun 28, 2005 2:07 pm

Post by n_t » Mon Feb 11, 2008 9:25 am

Hi aquarien,

good to hear you got some first tests to work within Blender. Overall, I think several points you mentioned can be explained by the fact that the solver in Blender was developed focusing on the visual quality of the results, and not the highest physical accuracy. You mention the fluid is not touching the container - this is probably an issue of the grid resolution. As terrainfighter mentioned, you can take a look at the fluidsim-IPO to modify some parameters during the course of the simulation.

I the mail you sent, you also asked about the real-world-size parameter. You can think of it more as a "desired value". The lowest viscosity that can be handled by the solver is essentially given by the grid resolution. If you choose some large real world size, it simply tries to the reduce the viscosity as far as possible, but might not fully reach the desired value. In reality, simulating a 1m-tank of splashing water is already a very challenging problem, so the Blender solver will internally have a higher viscosity (set by the Smagorinsky turbulence model) to keep the simulation stable.

I also cannot really certify any properties of the results, as I didn't run the necessary tests to validate the results with this solver. We had a different implementation for the metal foam simulations you perhaps saw in some papers. These were validated e.g. with some experiments of single bubbles. With the Blender solver, you should probably first run some test cases with analytic solutions to check whether it gives the right results for your problem. Once you did this, you can also use it to motivate that other simulations in this direction yield correct results...

Cheers,
-> Nils

Post Reply