Employing discrete partitioning

Use Help > Get demo to get the system HydrStatDP.ame. Run the system so that you can compare results (and CPU times) with those you get after employing discrete partitioning.

Note that a special data file is read: HydStatDP_.cam.

Figure 23: Data file

This file will be included in the .ame file when this system is saved. When we divide up the system, we will need access to this data from various slaves. Therefore you must copy this file to a secure location under a generic name, for example pump.cam.

We recommend you do at least the first part of the exercise (steps 1 to 9).

The complete hydraulic system can be converted to employ discrete partitioning in the following steps:

Step 1: Identify sub-systems

Identify sub-systems which are potential slaves. Each sub-system must be connected to the rest of the system by a hydraulic line that models wave dynamics and uses discrete hydraulic submodels. In this case the pump, the relief valve and the motor are obvious sub-systems. If we define the slaves in this way, the number of state variables is as follows:

• master system: 0

• Pump slave: 20

• Relief valve slave: 6

• Motor slave: 11

This is not the only way it can be divided and other divisions will be considered in this chapter.

Step 2: Replace discrete hydraulic line submodels with discrete hydraulic component submodels (HLLWPIPE0 and HLLWCNXFLOW0, HLLWCNXEFFORT0)

Step 3: Cut and paste the Pump sub-systems

1. First, cut the pump slave (including the HLLWCNXFLOW0 submodel) out of the original system and paste it into a new system.

Note There is no need for hydraulic properties icon/submodel in slave systems. This is an important principle of discrete partitioning: Slaves inherit their fluid properties from the master. Normally you do not need to add fluid properties to the slave. If you do, you must make sure that the fluid property index is different from any used in the master.

2. Next, add a one-port master block to the slave:

3. In addition you can add an RSTAT block to give access to the CPU time used by the pump slave.

4. Save the system as PumpSlave and move to Run mode to check it is valid and complete, and then close it.

5. Return now to the original from which the pump was removed.

Step 4: Modify the master system

1. Add a 1-port slave to replace the components you have cut out.

Figure 24: Add a 1-port slave

We are now in a position to do a discrete partitioning run. The original plan was to have 3 slaves but we can run with 1 slave.

2. Use Save As to name the system MasterHydr.

Step 5: Examine the slave block parameters

1. Go to Parameter mode.

Note that the master has 17 state variables. By default the parameters of the slave block are as follows:

Figure 25: Slave block parameters

Note that there are 2 enumeration parameters:

slave run parameters: use master/use local

export master global parameters to slave: no/yes

2. You can experiment with these parameters to see the options available, but return the values to the default setting before continuing.

Step 6: Define the cam position function of angular displacement

In the PumpSlave system, for each cam, you must define the file which supplies the cam position function of angular displacement. This is the pump.cam file you saved to a secure location at the beginning of this example.

Figure 26: Define the cam position

Step 7: Define the slave in the master

We now have a master system and a slave system. To associate the slave with its master, use the menu Modeling / Interface block / Slave system settings.

Step 8: Perform a run

1. Make sure the master is the active system and set the run parameters: Specify a final time of 1 second and a communication interval of 0.001 seconds.

2. Start the run.

You do not need to start the slave. This action is performed by the master.

Running the master system on one workstation for 1 second gives the following. CPU Time run statistics:

Master system: 964 s

and slave system: 411 s

The sum of the two CPU times is 1375 seconds compared with 2174 seconds for the original. The CPU is cut by 37% or alternatively there is a speed up by a factor of 1.58. This is quite reasonable but the situation is really much more complex. For the original run the elapsed (or wall clock) time must be at least 2176 seconds. For the discrete partitioning run with a single plain processor the elapsed time cannot be less than the sum of the CPU times, in other words 1375 seconds. The runs were actually done on a 2 processor machine. If you have a 2 processor machine and there is CPU usage monitoring facility, it is very interesting to watch this while the run is in progress. Elapsed times are more difficult to measure but careful measurements gave the original system run elapsed time 2176 seconds and the discrete partition run 978. Thus for one particular machine the elapsed time is cut by 55%, a speed up by a factor of 2.22. Warning CPU timers are notoriously inaccurate. On some platforms they are actually measuring elapsed time. The statistics obtained in this chapter were obtained on a platform known to have a reasonable CPU timer. Repeating the experiments on another platform gave strange results. The master and slave CPU times were almost identical. This was also true for cases with 2 slaves and 3 slaves. The explanation is simple. They were elapsed times. The master and slaves start at almost the same time and finish at almost the same time. Hence their elapsed times are almost identical. If you are following these experiments and observe the same phenomenon, interpret the times as elapsed times. Note that on Windows, CPU times displayed in the RunStats are usually elapsed times.

We have obtained some good improvements in run time. The next thing to check is that the results agree.

Step 9: Compare the results with the original system

We can plot the pump flow rate and pressure from the original and the discrete partitioning systems.

Figure 27: Pump flow rate

Step 10: repeat process and create 3 slaves for this system

We have run 3 cases of discrete partitioning with a small system. We can summarize the statistics in the following table.

	Speedup in total CPU time	Speedup in elapsed time
1 slave	1.58	2.22
2 slaves	2.48	3.79
3 slaves	2.56	4.26