The fully implicit code goes a step beyond, in parallelization, than the Explicit-Implicit code. The utilization result attained by this method, working on the load balanced mesh, is not as good as the attained with the previous code, due to the high contention (described in Section 5.2) between processes of the distributed Tri-Diagonal solver. This algorithm spent a lot time waiting for data from adjacent blocks.
In spite of the fact that the utilization result obtained is worse than in the explicit-implicit code, there is a positive side on this implementation, because the CFL time step restriction is removed. Time step limit is taken from the less restrictive stability analysis performed in Section 4.6 instead.
There is a balance between the advantage of this code and its improvement. Therefore, speedup employing the Fully-Implicit code doesn't change significantly from the speedup attained using the Explicit-Implicit code. Since it is often desired to maintain a small time step in engineering applications (to get better time resolution) there is still room for using the Explicit-Implicit code instead. Due to its extensive use of communications this implementation has been harder to develop and debug.
Figure 10.2, for the th80 grid shows the utilization diagram (explained in previous section) for the Fully-Implicit code working on a 4-block mesh.
Comparison of diagrams 10.1 and 10.2 leads to the observation of the described behavior. There is less wasted time using the Explicit-Implicit code and better utilization (4 processes working simultaneously). This different behavior is impossible to be distinguished working on the th5 mesh, due to its thin parallelism grain.
