Modes of operation for discrete partitioning

discrete partitioning modes of operation

What has been described so far is the first mode of operation. You start with a large system and cut the slaves out of it. You will probably start by using this mode. However, after a little experience you will see the need for the second mode of operation.

In the second mode of operation you build up a collection or library of slaves. These will be stable, well-tested systems. You build a master by including in it slave blocks. These slave blocks specify a slave system which may be in your slave library. Therefore you could build a collection of Piston Pump, Injectors etc.

You can create a collections of related slaves and store them in a special folders:

The slaves should be tested by loading them into master systems. When you have built up some good libraries of slaves, you can build the master directly, including slaves from your libraries.

Note

• Libraries ideally must not be in the same folder as the masters that use them.

• You should save slaves in purged condition.

Selecting sub-systems to become slaves

There is no point in creating very small sub-systems. For example, there is nothing to stop you having a hydraulic tank as a sub-system. However, if you do this, your CPU times are likely to increase instead of decreasing. In the first example, the sub-systems were far too small to be useful.

Experience shows that ideally the number of state variables in the slaves should be roughly the same. However, this is often impossible to achieve and there is some flexibility. A good partitioning can give almost as satisfactory results as a perfect one. The most important point is that the CPU loads for slaves and masters are balanced. If a slave consumes all the computation power of 1 cpu and still lags behind, the rest of the system will wait for this slave.

How many slaves should there be? It is extremely difficult to give general rules. Probably a slave should not have fewer than 10 state variables. It also depends on your hardware. It is important to realize that the master and the slaves are running as separate processes. With a conventional single processor the elapsed (or wall clock) time cannot be less than the sum of the CPU of the master and the slaves. If you have a bi-processor machine and/or processor(s) that support hyper-threading (or a machine that has multiple cores) the elapsed time may be a lot less than this. It follows that the best discrete partitioning for one hardware configuration may not be the same as the one for another configuration.

By default, the Discrete Partitioning will generally take advantage of multicores processors.

For hydraulic discrete partitioning you must use discrete hydraulic lines. Thus, an important parameter is the time taken for a wave to travel along the pipe. Even more important is the time taken for the wave to travel across a cell. The length of the cell is (length of pipe)/(number of discrete cells). Taking a representative speed of sound of 1000 m/s, the plot below shows time versus the length of a cell.

Figure 28: Time against length of cell

Thus for a cell of length 1.0 e-3 the time is 1 µs whereas for a cell of length 1 m the time is 1 ms. The times at which information is exchanged between the master and each slave depends on this time. At the time of the exchange there is a discontinuity and this results in an integrator restart. The shorter the time potentially the longer the CPU time is. You have some control by setting the number of nodes. Fewer nodes mean a quicker run. More nodes means more frequency modes will be covered which may or may not be an advantage. In a general manner, it is recommended to use the longest lines to define the cut between master and slaves.