Considerations for systems running DIANA​

As you may have noticed we did not publish a minimum requirements sheet for DIANA and related products. The reason for not doing this is that the system requirements depend on the jobs the users want to run. To help customers detemine a proper system for the workload we have some recommendations and guidelines. Finally example configurations to help new users/customers get started with a serious but affordable system.


DIANA and related software makes use of OpenGL for displaying graphical content. Workstation class graphics boards like the NVIDIA QUADRO are designed for OpenGL applications like DianaIE, iDIANA and FX+ for DIANA and are therefore highly recommended for visualisation at the client side. From DIANA 10.3 onwards, the graphics card must be compatible with OpenGL 3.2. See Fact Sheet for more details.


This is probably the most important topic when you need to improve DIANA performance. Users often think that system memory is only used by applications. This is not true. System memory is also used as file system cache. DIANA runs optimal if both executable memory and filos file can be kept in system memory. If you want to run multiple jobs at the same time you need to have system memory available for each job. If not, it is better to run the jobs one at a time.


DIANA does not benefit from using persistent memory.


DIANA is a CPU intense application. Parts of the product make use of parallel processing to speedup the analysis. Adding additional cores helps to reduce the analysis time but since a substantial part of the analysis is executed sequentially instead of parallel the primary focus for improving performance should be to improve the single core performance of the system. For example consider using the 8-core Intel® Xeon W-2145 (3,7 GHz, 4,5 GHz Turbo, 8C) CPU instead of the 28-core Intel® Xeon® W-3175X (3,1 GHz, 3,8GHz turbo, 28C). The parallel performance will benefit from the additional cores but the sequential part will run slower and the end result could well be that the total time is increased instead of reduced.


DIANA will not utilize the GPU for calculations.


DIANA will not utilize Intel Xeon Phi coprocessor boards for calculations. A system with Intel Xeon Phi x200 series main processor and supported linux distribution can run DIANA but is not recommended. Since parts of DIANA do not run in parallel the low single core speed of the Intel Xeon Phi will slow down the calculation so much in serial parts that there is no benefit from having many cores in parallel.


DIANA calculations can create very large files. Besides that the filos file is used intensively while you run a job. For big systems we recommend using a RAID system for secure data storage and increased performance. We reccommend the use of RAID10 to avoid parity calculations on the RAID controller due to excessive write I/O during the calculation.

To improve performance SSD’s and NVMe SSD’s can be used. SSD’s for storing the filosfile should be of type “Write Intensive”.


At the time of writing DIANA is supported on Microsoft Windows and RedHat Enterprise Linux systems. Performance measurements have shown that there is not a significant difference in analysis time when running DIANA on either of these operating systems. Main focus while selecting the operating system should be how well the system fits into the production process. Please note that FX+ for DIANA only runs on Microsoft Windows systems. The DianaIE and idiana pre- and postprocessors run on all supported platforms. It is possible to run calculations on a RedHat Enterprise Linux system and perform the FX+ for DIANA pre- and postprocessing tasks on a Microsoft Windows system but in that case files need to be transferred manually between the systems.


DIANA can create very large files. If you try to make a backup of all data you might run into capacity or time window problems. Here is a description of some files that might help you to fine tune your backup job.

Files with the .dat extension contain the model description. In general these files are small and should be included in a backup.

Files with the .dcf extension contain analysis commands. In general these files are small and should be included in a backup.

Files with the .ff extension are what we call Filos files. This can be seen as a scratch file or swap file and tend to be large. Filos files can be used to continue a previous analysis. Some users perform an analysis in small steps and save the Filos file once they are satisfied before they continue with the next part of the analysis. Other users simply start a complete analysis and only occasionally reuse the Filos file. If the .dat and .dcf files used to start the analysis are included in the backup the Filos files can always be recreated. You might consider excluding Filos files from the backup. Filos files that are open at the time of backup are unusable after restore. You might consider using the FFDIR symbol to set the default Filos file location and/or the FF symbol to set the default Filos file name including location on your system such that they are by default not included in a backup. The user can then choose to move Filos files to a different location if he/she wants to save them for future use.

Then there are several output files which can also become large. These files are what the user needs to perform postprocessing tasks. Output files can be very large but in many cases the Filos file is much larger. All output files can be recreated but think carefully before excluding these files from the backup. It is not pleasant to have to rerun an analysis that took several weeks to complete in order to generate one additional image for a report.