Free Courses Fluids Structures Electronics 3D Design Optics Photonics Materials Installation Python Optimization Safety & Cybersecurity Embedded Software MBSE Digital Mission Engineering STEM NVH Student Teams Semiconductors Indo Kursus Partner Courses My Courses

[FAQ]

There are a few points to consider: 1. At present, in Release 19.2, the shell zones get created each time, when one reads a case file. Some larger cases, that include 100’s or 1000’s of shell zones might demonstrate a considerable slow-down. 2. Typically, the shell-creation time reduces with the number of cores, and the case loading time is also reduced with the number of cores used. 3. As the virtual shell cells are not saved in the case file, the temperature data for these shells are saved as additional variables on the walls, and represent the shell-cell and facet values. Upon reading a case file, the data gets mapped onto the newly recreated virtual cells in the shell zones and this mapping process adds to the cost and slows down the process further. On a positive side there are a few points to note too. 1. There have been a lot of enhancements in this area between R16.0 and the current release R19.2. Upgrading to the current release is, therefore, very favourable. 2. There are some additional improvements that can be exercised already in R19.2 by means of executing special scheme scripts. This allows a somewhat quicker mapping, which can moderately improve the case and data file read times. 3. Most importantly, in the next release in the beginning of 2019 there will be a drastically improved functionality where the shell elements will be saved in the case file directly. This will make the read/write times much faster and will avoid all the time and effort that is now required for mapping. 4. Reading and writing the files in the .h5 format is likely to improve the overall reading and writing time but it does not affect the shell zone recreation and mapping directly. It is also worth re-iterating that the smaller the cell count per compute node is – the faster the current shell-related read-process is. Currently the only standard possible way to reduce the read/write time would be to open the case file on a maximum number of cores possible.