A better Fluid library at the Winter Simulation Conference

Hi,

The 2013 Winter Simulation Conference is less than two weeks ahead. We will present the work we have undertaken to develop a Discrete Rate Simulation (DRS) library, which replaces Flexim's Fluid library. Our library uses generic custom objects and a network flow maximization algorithm to solve accurately the mass balance. It can handle easily recirculation lines. The library interacts perfectly with other Flexsim objects. DRS objects settings are intuitive and straightforward. We have used this library in several projects such as the one we will present. Here is our presentation track:


Simulation of Mixed Discrete and Continuous Systems: An Iron Ore Terminal Example
Monday, December 9th, 3:30pm-5pm
"Commerce" room

Don't miss us!

Helo Vincent,

I see that you did the same as we did.
Started out some years ago and took probaly a similar approach (network optimization). We have created several sets of ibraries with this approach as the timeslicing method (standard libary) has too many headaches as you might have encountered yourselve.

I am curious how the two approaches would compare.

Regards,
Dirk-Jan Moens

Hi Mr. Moens,

What we did essentially is this:

1) Start with a basic Flexsim fixed resource object and add extra variables and functions. The goal is to have a new fluid object that can determine if it is in mass balance. Some other object functions tell how to readjust flow rates in order to become mass balanced

2) Develop a customized network flow optimization algorithm. Classical algorithms such as Ford-Fulkerson do not apply since network objects are “active” and can dynamically influence material routing (ex.: flow splitters and combiners). The algorithm starts with the (maybe?) infeasible solution: put maximal flow rate on all connections. Then it progressively reduces flow rates until all units are in perfect mass balance.

3) Put in place several enhancements:
- a technique to determine a proper evaluation sequence considering recirculation lines (algorithm assumes that all object’s input flows are “known” when trying to readjust flow rates)
- a technique to determine in how much time flow rates will have to be re-evaluated (we got rid of the time slicing method, we jump exactly from one fluid event to the next one!)
- statistics collection..
- an internal event list: in Flexsim’s event list, there is only one event related to our library: a senddelayedmessage to trigger next flow update. During a flow update, we execute all events that occur at the same time (or very closed in time, using an adjustable tolerance factor)

4) We also put in place some mechanisms to apply “external” stops on a fluid object, to be used with outer reliability and scheduling features.

We implemented our fluid library using ModelLibraries (with objects sending messages from the library, such as our “Ticker”). We also developed several fluid objects with their GUIs: source, sink, itemTo Fluid, FluidToItem, Flow Restrictor, Reservoir, Pipe, flow divider and combiner, batch processor. In addition, we created a LogicBuilder object we used to successfully implement PID control loops. Since the entire approach in object oriented, we could quickly create other fluid objects.

We will present all of this more beautifully at the WSC2013!

Regards,

Hi Vincent,

Yes, we came to the same conclusion that classics like Ford and Fulkerson will not work.

Reading this we came to a somewhat different approach. What is the same in our sustem is that timeslicing is not used and only 'actual events' like tank tops are created. We too have 'external events' that can be used as MTBF/MTTR or as user defined actions: like changing rates connecting/disconnecting objects (like ships).

I was wondering how your system would act on conflicts in reflow: it seems that the order which you will evaluate will dictate the outcome is it not?

I will have a look at your WinterSim paper (is it available already?)


Rgds,
Dirk-Jan

Hi Dirk-Jan,

It definitely looks like we created a very similar mechanism. Have you written any paper on your implementation?

In our system, reflows (or recirculation lines) are not an issue. We inspired from chemical process simulation with sequential calculation: a loop tearing algorithm determines the proper evaluation sequence before running simulation. During simulation, our mass balance solver is an iterative algorithm that requires more iteration as the number of recirculation lines increases.

Regards,

Hello Vinvent,

Forgot to get back to yoou after the wintersim. How was your presentation received? Are there more modellers with the same issues?

I had a look at your paper and it seems that we are taking a very different route in solving the fluid flows after all.
I also made the model of the theoratical tank level problem. I was pleased to find out that our solution is within 10 digit accuracy and only takes 9 events to calculate. However this seems a rather simplistic benchmark and it is much more intersesting if a model has reflows, percentage split/merges and preferred flows in the system. Also the size of the model is an interesting parameter.

Rgds,
Dirk-Jan