Parallel processing

dummy link for benefit of anchor linked from external source

Machines with multiple processors or processors with multiple cores are becoming increasingly common. OrcaFlex can make good use of the additional processing capacity afforded by such machines. For up to date information on hardware choice for OrcaFlex please refer to www.orcina.com/support/hardwarerequirements/benchmark/.

OrcaFlex performs the calculations of the model's line objects in parallel. This means that, interactively at least, performance is only improved for models with more than one line object. However, for models with more than one line performance is significantly improved.

Batch processing, fatigue analysis and OrcaFlex spreadsheet post-processing tasks process jobs and load cases concurrently, using all available processing resources.

Thread count

OrcaFlex manages a number of execution threads to perform the parallel calculations. The number of these threads (the thread count) defaults to the number of logical processors available on your machine, as reported by the operating system. This default will work well for most cases. Should you wish to change it you can use the Tools | Set thread count menu item. The thread count can also be controlled by a command line switch.

Non-repeatabilty of calculations because of multithreading

OrcaFlex performs numerical calculations using double precision floating point arithmetic. Floating point arithmetic is, inevitably, imprecise because values are represented up to a finite precision.

This does not mean that calculations are not well-defined and repeatable. The standard that governs floating point arithmetic, IEEE 754, mandates how the fundamental arithmetic operations are to be implemented on a machine which adheres to IEEE 754. The machines on which OrcaFlex runs do adhere to IEEE 754.

However, the combination of floating point arithmetic and multithreading, as implemented by OrcaFlex, can result in non-repeatable calculations. The simplest way to illustrate this is to consider the associative law of addition: \begin{equation} A + (B + C) = (A + B) + C \end{equation} Whilst this is a mathemetical truth for all values $A$, $B$ and $C$, this is not the case for floating point arithmetic. In other words, the order in which a set of values are added together can result in different results. Note that these differences will be tiny, at the level of machine precision.

Usually the calculation order is the same each time a program is run, in which case multiple runs on the same hardware will produce exactly the same results. However, if the program uses multithreading, then the calculation order can sometimes vary from run to run.

To see how this can happen, consider a program whose job is to calculate 100 values and then add them all together. If the calculation of each value involves a lot of computation, then an efficient way to do this is to use parallel processing. The job is split into 100 separate tasks and each task is given to different processors as they become available.

Suppose the program is run on a two processor machine. The program creates two separate processing threads, one for each processor, and these threads execute in parallel. Each thread takes the next task from the list of 100, performs it and adds the resulting value to its own thread sub-total. The two threads continue to do this until there are no more tasks on the list. When both threads have finished, the program adds together the two thread sub-totals to obtain the final sum.

The order in which each thread picks the next task is undefined and different executions of the program can result in the tasks being shared differently between the threads. Because floating point addition is not associative, this means that the end result can differ for different executions of the program. This is precisely what happens with OrcaFlex.

Of course, such differences are normally tiny, as mentioned above, and totally insignificant. The unknowns in the data far outweigh the tiny imprecision in computer calculation.

However, it is possible to get cases where the tiny differences are amplified by sensitivity in the calculations involved. In these cases the tiny machine accuracy differences can lead to significant differences in results. Such sensitivity is often referred to as the butterfly effect. Such sensitivity can arise in a wide variety on nonlinear systems, weather forecasting being the oft-quoted example. When it does occur the tiny differences due to finite machine accuracy can lead to significantly different results when a run is repeated. It is wrong, however, to think that the problem is the tiny differences. The problem is that the calculation is extremely sensitive, and there are two possible reasons for this.

The first possibility is that the real-world system being modelled might indeed be extremely sensitive. In this case the problem is inherent and cannot be avoided. The results will depend significantly on what one might have hoped were trivial aspects of the data, and also depend on the tiny inaccuracies in the computer calculations, so the problem becomes effectively unpredictable. It is believed that this might apply to weather forecasting, in which case we will never be able to get accurate long-term weather forecasts.

The second possibility is that the real-world system is not chaotic, but that the model of the real-world system, which of course is never a perfect model, is hyper-sensitive. In this case the problem lies with the modelling and it should be possible to solve the problem by changing to a better model of the real-world system.

When using OrcaFlex, in common with any other numerical analysis tool, both of these situations could occur. Vortex induced vibration (VIV) is a highly nonlinear real-world effect that is often quite sensitive to changes in conditions, so it might in some cases be an example of the former. But most real-world systems modelled using OrcaFlex are not anything like as sensitive and are usually quite stable.

More often, however, it is the model that is too sensitive and is not a good model of the real-world system. It is not possible to say in general what makes a model too sensitive. However, here are some possibilities:

If you are concerned that your model might be very sensitive, then it is worth re-running simulations using slightly different data. For example, try re-running using a different time step, or with slightly different data values (e.g. line type properties, positions of objects, etc.) to see how significantly such changes affect the results.