1. Unlike DS2V which has separate codes for the DSMC calculation and the interactive user interface, the DS3V graphical interface is produced by the Winteracter application that embeds calls to the Windows API as FORTRAN subroutines within the DSMC code. This is undesirable because, unlike RealStudio, it limits the code to the Windows platform and there will be no further development with Winteracter. Also, Winteracter is more expensive than RealStudio and can be difficult to integrate with the preferred FORTRAN development environment.
2. Unlike DS1V which is a 64-bit program that employs double precision for all variables, DS2V and DS3V are 32-bit programs and much of the code development effort has dealt with the problems that arise from round-off error. The most serious problems have been associated with the marking of the very small elements as either fully or partly within the flowfield or completely outside the flowfield (I.e. Inside a body). This shows up on the interactive displays during the project initialization stage and the memory that is initially allocated to the project can be changed slightly to (hopefully) avoid the problem. A bad “inside-outside” marking is just an occasional problem with DS2V, but a good marking for a complex geometry occurs only occasionally with DS3V!
3. The other problem with DS3V is that it is not self-contained in that a surface triangulation file must be provided. A special program can be written for simple geometries like that in the sample data files, but access to expensive grid generation programs is generally required. The only “reasonably priced” (under $1000) surface triangulation program that gives the necessary control over the triangle size is Rhinoceros.
4. There is an all-FORTRAN version of DS3V (DS3.F90), but it is almost impossible to cope with the problem outlined in Note 2 unless there there are interactive displays that allow the user to easily monitor the application. Also, now that CPU speed rather than memory capacity is the limiting factor, there is an overwhelming case for programs to be 64-bit. I have a low priority continuing project to update DS3 to a 64-bit program that would not have the “Note 2 problem” (simply changing all variables to double precision in the current code does not solve this problem). Most FORTRAN compilers have extensions that allow the execution of related programs, and RealStudio now supports OpenGL. An interactive program for the verification of the surface data file has already been prepared.
5. If commercial programs are used to produce the surface triangulation, it may be possible to produce a tetrahedral grid for the flowfield without much additional effort or expense. While, this grid would not be used in the main calculation, it would allow the easy production of alternative subroutines to solve the problem outlined in Note 2.
6. The current DS3V code allows the calculation to be made in two parallel streams through domain decomposition. Now that the Intel Version 12 FORTRAN compiler contains support for co-arrays, this could be be extended in a more robust manner to an arbitrary number of domains. Co-arrays also permit parallelism through loop splitting, rather than domain decomposition, and a simplified 3-D code has been written in order to compare these approaches.
7. It was stated on the previous site that future versions of DS2V and DS3V might move to a “tree structure” cell structure. The DS1V employs this approach in the cell adaption, but the current cell structure appears to be far preferable for two and three-dimensional grids. The disadvantages of the irregular cells are preferably overcome by additional output arrays based on the rectangular divisions that are already in the current programs