Fluid Library Mathematics

Hi,

I want to understand better how the Fluid Library works. Could somebody tell me more about the mathematics behind it?

The math is not nearly as complicated as actual fluid dynamics. The objects have rates defined for their inputs and outputs. There are three values that affect the rate for each port: a base rate, a total rate and a scaling factor. The base rate defines how fast material can move into the object (or out of the object, depending on the type of port). The base rate is multiplied by the scale factor defined for the specific port in question. So, for example, let's assume an object has an input rate of 10 and the scale factor for input port one is defined as 1.0 and the scale factor for port two is defined as .75. Port one would be able to receive material at the full rate of 10, but port two would be limited to only 7.5 (10 * .75). Then these rates are actually throttled by the maximum object rate. The object will receive material until the maximum object rate has been reached, then it will stop receiving.

This is the underlying system for all of the fluid objects. Not all of them expose all these values to the user, however. For example, the Mixer asks an input rate and a recipe. It will determine what scale factors to use automatically as it runs. I think that pretty much all of the fluid objects (except the Tank) hide (or at least filter) these options from you.

Hi,

Thanks for your explanations.

I still have a few questions:
- how are the objects ordered? I suppose they are "ticked" one by one
- is it a sequential evaluation (one pass per tick) or is there some hidden convergence loop?

Regards,

At the start of a model run, the objects are ordered based on how far they are from the beginning of the fluid section of the model. A fluid object with no fluid objects connected to its inputs is considered the be the beginning of the fluid section. During a tick, the objects are evaluated from the end of the flow to the beginning. So, if I have a Generator, a Tank, a Pipe and a Terminator in a row, they will be evaluated in this order: Terminator, Pipe, Tank, Generator. Things get to be more tricky when a loop is discovered in the flow. The system doesn't know what order those objects should be in, so it will assign a rather arbitrary evaluation order to them. It is recommended that loops be avoided.

Hi again,

Ouch! The processes I have to model usually have recycle loops....

Are there some plans to develop further the Fluid features?

The fluid objects can handle loops, for the most part. But the results may depend on the order the the Ticker decides to evaluate the objects in the loop. If you start having trouble with this, let me know and we can find a way to make the Ticker evaluate things in the order that you need.

There are some plans for improvements to the fluid objects in the future, but our development efforts tend to be in other places right now.

Hi AJ,

I am trying to use Fluid Library objects to simulate Dry Bulk material handling. I found this post is very useful to understand how Fluid Objects work. However, I still found some logic is not very clear.

Can you tell me how the attached simple model the rate for P1 and P2 is calculated?

In the model the maximum rates for Fluid Generator, Fluid Terminator, and P0 are 1.0. And the maximum rate for P1 is 0.4, for P2 is 1.

I found if I use the First Available option for the Flow Mode of P0, the actual rate for P1 will be 0.2, and for P2 will be 0.8. I think they should be 0.4 for P1 and 0.6 for P2.

However, if I changed the maximum rate for Fluid Terminator to 10, the rate for P1 will be 0.4 and for P2 will be 0.6, which are correct numbers.

If use User Defined option for P0, it will be the same as the First Available option.

If use Flow Evenly option, the rate for P1 will 0.4, and for P2 will be 0.5.

Thanks very much for your help!

Alan

Alan,

Whenever the math of the fluid library doesn't make sense in a simple model like this one, the best way to figure out what's going on is to step through the model run one event at a time. It is often very enlightening to see what's happening during each tick. Here's what I discovered stepping through this model:

Some underlying rules that affect what's going on:
1) Pipes can never receive more material than they have space for.
2) Pipes try to send material at the same rate that it was received. If there is a drop in the incoming rate, there will be a corresponding drop in the output rate.
3) The dwell time in a Pipe is the maximum content divided by the flow rate.

When the model starts, P1 and P2 receive at the expected rates (.4 and .6). P2 begins to send material before it is full because the incoming rate is lower than the maximum rate and the dwell time is based on the maximum. This means that the maximum content of P2 tends to not be a limiting factor in this model.

P1 keeps receiving .4 each tick until it is nearly full (specifically, 4.8). Then it can only receive .2 units. Once it starts receiving .2 units, P2 can receive .8 units (because P0's rate is 1).

P1 and P2 continue to send at .4 and .6, until they reach the material that came in at .2 and .8. Then they change to sending at that rate.

Hi AJ,

Thanks very much for your reply and the advice. But I still have the following questions.

1. Why the rate will be depending on the maximum content? I though the maximum content is only used for determine the time for how much the pipe can hold. It is a tricky logic for adjust the flow rate which should consider the maximum content. For example, if I set the maximum content for P1 to be 5, the stable rate will be 0.2 for P1 in the model. If I set the maximum to be 4.81, the stable rate will be 0.01. If i set it to be 4.8, the stable rate will be 0.4. You can imagine how tricky it will become if you have a relative big network and try to control the flow rate.

2. What is the dwell time? Is it how long the material will spend in the pipe? How to track this in your logic as these are fluid material, not discrete flow items?

3. I found the dwell time equals to the maximum content divided by the maximum rate, not current rate. Is this right?

4. I actually add some code to track the content, input and output of P1 and P2 in the attached model. The result is shown in the attached Excel file with a few steps extracted here.

Time Device Content In Out In-Out In_Rate Out_Rate
...
18 P1 4.8 4.8 0 4.8 0.4 0
19 P1 4.81 4.81 0 4.81 0.01 0
20 P1 4.81 5.21 0.4 4.81 0.4 0.4
21 P1 4.81 5.61 0.8 4.81 0.4 0.4
22 P1 4.81 6.01 1.2 4.81 0.4 0.4
23 P1 4.81 6.41 1.6 4.81 0.4 0.4
24 P1 4.81 6.42 1.61 4.81 0.01 0.01
25 P1 4.81 6.43 1.62 4.81 0.01 0.01
...

Something I cannot understand from this log. Why the rate for P1 drops to 0.01 at time 19 then bounce back to 0.4 at time 20. Then after 4 time steps, it drops to 0.01 again and then keep unchanged?

Sorry about these additional questions. But I think understanding the logic behind is essential to use the fluid library. And the manual seems not sufficient.

Thanks again for the help!

Alan,

When I talk about dwell time in a Pipe, I mean the amount of time between when material enters an empty Pipe and when it is available for downstream objects to pull. (Remember that ALL material is pulled in the fluid library. There is no pushing at all.) This time is calculated by dividing the maximum content by the flow rate. It assumes that that the Pipe will use it's full input rate during a run. If a Pipe does not use its full input rate, then it can behave in possibly unexpected ways.

When using any of the fluid objects remember that the underlying pull logic is identical for all of them. A downstream object pulls material from the object(s) directly upstream of it. It can never pull more material than the upstream objects have available. Thus, the content of objects will throttle the rate that material moves.

In Pipes, there is an interesting feature that allows material to "back up". If more material is available to leave than is actually pulled by the downstream object that material is added to a value called "accumulation". All "accumulated" material is available for pulling. This means that a downstream object can sometimes pull at a faster rate than the material actually entered.

In your pipes, they come close to filling up, then pull a tiny amount to fill themselves up. That tiny rate eventually works its way to the end of the Pipe and so the downstream object only pulls a tiny amount. To compensate for pulling a small amount from P1, the Terminator pulls .99 from P2. The .99 is allowed because there is accumulated material at the end of the Pipe.

Here are a couple of things I've tried to keep in mind when working with Pipes:
1) Don't use Pipes unless you absolutely need the time delay between two objects. Every Pipe in the facility does not need to be modeled.
2) Try to make sure that a Pipe's entire input rate is used.
3) Try to keep the input rate to a Pipe as constant as possible.
4) Pipes work best if their maximum content is a multiple of their maximum rate. That way you don't have the strange rate drops when the Pipe fills up.

Phil,

Thanks for your suggestions. I guess my model falls into your category that it behaves in an unexpected way. Perhaps it is better to model the dry bulk material using the discrete objects, not the fluid library object to avoid these glitches and get better control of the behaviors.

Guys,

Interesting to see this discussion on the fluids. As you may or not may know, we (talumis) have developed a different way of calculating flows in a fluid network, that would take away concerns about these "glitches".

I am interested to hear if more people out there would be using fluid objects if they would function more intuitively. We either might decide to put the new calculation in the current library (but this will have major issues with upward compatibility) or alternatively create a different set of objects.

Let me know if it would make the effort worth while to enrich Flexsim with this development?

Regards,
Dirk-Jan Moens

(reply moved)