The principal reason behind implementing Milthorpe's algorithm in C++ was to arrive at a code that would allow a computer programmer to implement changes in a more reliable and more efficient fashion. This goal has been achieved.
Once CONVECT was producing the same results as Milthorpe's computer program it was possible to start enhancing it so that it could tackle more difficult problems, such as driver gas contamination in a shock tunnel. In this section a number of examples are given to show how object-oriented programming techniques have reduced development time for CONVECT and ancillary code.
To implement the tuning algorithm it was not necessary to change CONVECT at all. The tuning algorithm was implemented as a drop-in replacement to CONVECT and managed the tuning of the parameters that it passed to CONVECT's objects. One of the design features of CONVECT was quite useful here. Through most of the development, testing and execution of CONVECT, the computational domain was two dimensional. The tuning took place on a one dimensional domain that was implemented by making one dimensional versions of only some of the objects - through the object-oriented feature of inheritance. Most of the code was written to deal with an arbitrary problem dimension that was specified as a compile time parameter. Thus, there was no time wasted in writing a new version of the computer program and there was no danger of introducing new bugs to the existing code.
Again, the implementation of CONVECT as a parallel computer program involved very little change to the existing code. In fact, the modular nature of the computer program made it possible to continue developing and testing the original version of the code whilst implementing the parallel version. As with the implementation of the tuning algorithm, the parallel version was implemented as a drop-in replacement for CONVECT that implemented the parallel code through inheritance of existing objects.
The implementation of the artificial viscosity term was not particularly enhanced by the object-oriented nature of CONVECT. All that was required was to introduce a new input parameter for certain functions and to rewrite some of the Transport object's methods. This kind of change would have probably taken about the same time to implement in Milthorpe's original Fortran program.
For a team of researchers all using versions of the same code, the C++ implementation is a better choice because of its modular nature. A researcher does not need to change the core code, which may affect the other people using it. The researcher need only create a new version of the objects required to implement the new features. This approach is not really possible with Milthorpe's Fortran program. If more than one person were developing it at the same time then they would have to work on different versions of the code which would quickly diverge. This would make it harder to merge the changes each researcher created into a single version of the code.
C++ does have a role to play in scientific computer programming, especially for dealing with user interfaces and for modelling particular abstract concepts. For the purposes of understanding certain fluid dynamics problems better, it was not worthwhile rewriting existing Fortran code. It would have been better to take a hybrid approach where new data structures, such as those needed in a parallel implementation, could be incorporated with C++ whilst leaving the existing Fortran code to do the underlying computations.
This approach has been taken by Crutchfield and Welcome [8] in their Adaptive Mesh Refinement computer program. They used existing Fortran solvers to integrate the solution over subsets of the problem domain. The overall data structure and adaptive mesh algorithm was handled by a C++ program. Their methodical approach to development in this way created a set of computational tools that they and other researchers have developed further and successfully applied to several problems.
Another example of mixing the features of C++ and Fortran code is the implementation of the commercial computational fluid dynamics package GASP [16]. Looking at the source code, it appears that all the problem solving code is written in Fortran, due to historical reasons. In commercialising the product a graphical interface to the problem solving code was constructed and this has been implemented in C++.
Several lessons have been learnt from this work. It is not good computer programming practice to `re-invent the wheel'. It is better to use existing code that works, rather than spend time writing code that does the same thing. There are several good computer programming languages available. If new code is being developed it is good to use the right language for the job. One needs to weigh the benefits of using the right language against the time it takes for researchers involved to learn that language.
The tuning process worked very well. The results presented in Section 6.1.2 show clearly how the new upwinding parameters produce a much better agreement with the theoretical predictions.
The parameters that were originally taken from Milthorpe's computer program gave the required upwinding value for particular local Mach numbers. Extra parameters defined at specific Mach numbers were introduced to refine the solutions for particular flow problems. In particular, several parameters were specified at subsonic Mach numbers to allow for the correct shock standoff distance to be calculated in a blunt body problem that Milthorpe investigated [25]. Milthorpe also found that existing parameters sometimes had to be adjusted to suit new problems [27].
Figures 6.3 and 6.4 show that all the parameters, except those for the highest Mach numbers, had to be adjusted. For the low Mach numbers, the change went from a small amount of upwinding in the momentum calculation to full upwinding. The current work had quite a different range of Mach numbers - generally much higher. Few of the original parameters were left unchanged by the process of tuning them to suit the driver gas contamination problem.
It would be good to achieve a more versatile approach to choosing upwinding coefficients, one in which the upwinding coefficients would not need to be tuned for each new problem. The Mach numbers at which upwinding parameters are defined could be investigated to see if a better set could be found. It is possible that using the local Mach number as a basis for choosing these parameters is not the best approach. An alternative that would be worth investigating is to use some function of the local cell Reynolds number (Equation 7.1).
Comparing Figure 6.13 with Figure 3.4 it can be
seen that, with the artificial viscosity included, CONVECT produces
reasonable laminar boundary layers when simulating a shock tube. The
size of the boundary layer that was produced by CONVECT was larger
than that predicted by theory. A better match could be achieved by
reducing the value of 
.
To tune 
in a way similar to that used for the upwinding
parameters, it would be necessary to construct an error function that
would be at a minimum when 
was optimised. This would take more
time to tune since this is a two dimensional problem. It is quite
possible to do this.
The fact that GASP did not produce results that were as good as the CONVECT results was not necessarily due to a lack of capability in the product. The intention was to run GASP to produce a comparison for discussion but not to spend a great deal of time doing so. In the time allowed, it was difficult to get an acceptable solution using GASP. Those results presented in Section 6.5 that include viscosity show that a transient, if somewhat unstable, solution was achieved. There was no separation of the shock from the contact surface. This, and the appearance of air behind the contact surface, show that the problem was not simulated adequately.
GASP is widely used and is well validated for a range of compressible flow problems. It is believed that GASP might produce better results for this driver gas contamination problem given enough time. However, for certain problems it would be simpler to use more specialised code, such as CONVECT or Milthorpe's computer program since they are already set up for the job.
The best results for simulating the driver gas contamination problem
were those shown as part of the artificial viscosity study. The
features of a shock, boundary layer and contact surface are all
present. The contact surface is quite smeared and it was found that
this occurred over a constant number of cells. Thus, it was possible to
produce a better defined contact surface by running a problem with
more cells in the 
-direction.
No bifurcated shock system appears as the reflected shock interacts with the boundary layer. Better examples of a simulation of the reflected shock-boundary layer interaction can be found in [34] and [2]. Both of these show the jetting of driver gas through the bifurcated shock system. They both also start the calculation near the end wall assuming an initial boundary layer profile and a test gas slug length. Vortex flow formations that were present in these other works have not appeared in any of the results produced by CONVECT. This may be because Milthorpe's algorithm does not, at this stage, deal with turbulence.
CONVECT is an improvement on Milthorpe's original computer program. It produced the same results and it also introduces some improvements on the functionality of the original program such as the ability to compute in parallel. The fact that it has been re-written in C++ should make further development of the code more efficient and less prone to errors.
C++ is generally a good programming language to use for new projects in CFD. If there are existing routines that have been developed in another language, however, it is best to leave these intact and interface new C++ code with them. Where there is no optimised C++ compiler for a particular computer architecture, it would be best to use the optimised compilers that are available.
Milthorpe's algorithm, as implemented in CONVECT, was able to simulate a shock tunnel to some degree. It certainly had more success than the attempt made with the commercial CFD package GASP. The results produced by CONVECT, however, did not provide any further insight into possible causes of test time limitation due to driver gas contamination in shock tunnels.
Further work could gain more insight into the driver gas contamination problem by introducing features such as a turbulence model. Computations over a greater number of cells would improve accuracy. The availability of faster computers and the use of the parallel code would speed up the process of producing results for larger problems. The shock tunnel could be modelled better by including a representation of its nozzle in the simulation.
