Desktop version

Home arrow Engineering

  • Increase font
  • Decrease font


<<   CONTENTS   >>

Appendices

A On limitations and way forward

One of the main limitations of the framework presented here (which is common to all high- fidelity FSI models) is the relatively high computational cost of large simulations. This was particularly apparent in Section 5.3.3, where the simulation used more than 800,000 core hours before completion. This limitation is still prominent despite the careful selection of the techniques presented here according to their computational efficiency when compared to alternative tools. For example, the added mass stabilised non-iterative coupling scheme between the fluid and the solid solvers avoids any additional iteration of either solver per time step, and this induces significant computational savings when compared to implicit schemes. Computational efficiency is also the reason for using gradual mesh refinement on most simulations presented here. Resolving these issues essentially comes down to simply optimizing aspects of the code, sometimes simply by converting code written in high-level interpreted programming languages (Python) to lower-level compiled languages (e.g., C++), or by employing more efficient approaches or algorithms for the numerical solution. The computational efficiency for the fluid problem can be further improved by allowing gradual coarsening of the mesh along the free surface in areas where the description of the fluid does not need to be accurate, such as in absorption zones. This requires further work on the free surface description model as such coarsening along the air-water interface is not possible without introducing spurious fluid velocities due to the dependence on the mesh element size to smooth the VOF field in the current. Furthermore, mesh motion approaches based on monitor function model, on top of allowing for quality control of the mesh, can be used to dynamically refine around the free surface instead of using a large refined band covering all areas where the free surface is expected to evolve, thus improving computational efficiency.

Another limitation concerns the added mass stabilisation, that is limited to single rigid bodies, and cannot technically be applied as it stands to flexible bodies or multiple bodies that are in close proximity. Inclusion of these effects may require a re-design of the added mass stabilisation model, which may prove to be complicated and impractical. In de Latail- lade (2019) it is nevertheless shown that using conservative (overestimated) values for the added mass matrix may result in practically identical results as using the actual added mass values, as long as time discretisation is sufficiently fine. It is therefore very possible that a careful implementation of the current model with appropriate multipliers will be suitable for stabilising flexible bodies and multiple structures.

The simulations presented herein do not include turbulent effects for the CFD model, despite Proteus® having built-in the k-epsilon and k-omega models. The authors made a conscious choice not to include them, as the turbulence models had been designed for single-phase flow and this might have caused spurious results for two-phase flows (Devolder et ah, 2017). In addition, resolving turbulent processes is not as significant for this work as resolving the coupling and stability issues discussed herein. It can also be argued that the results from the simulation presented here, are in good agreement with the experiment and other numerical models, and are not significantly affected by the absence of turbulence modelling. Turbulent effects may nevertheless be of increasing importance in case of, e.g., multiple bodies with interacting wakes. Implementing specialised turbulence models for two-phase flow such as the one in Devolder et al. (2017) may further improve the framework.

In terms of mooring modelling, various additional aspects can be implemented such as nonlinear stiffness along the cable (varying with tension), line breaking mechanisms, and anchor movement or dislodgement mechanisms. Note that, as the CFD and MBD solvers are fully partitioned, it is possible to extend the capabilities of the existing framework by modifying or replacing one of the solvers without affecting the coupling strategy. Future work may be performed to include deformable bodies, collision for multiple bodies or failure mechanisms for mooring lines or other solid elements, thus further extending the capabilities of the framework towards a realisting representat ion of FSI processes.

B On software development

In this section, some general thoughts on software development aspects of the FSI framework applied in this work are discussed briefly. The framework is based on the Proteus® toolkit for solving fluid transport equations with FEM, and the Chrono® MBD library for introducing rigid body motion, dynamic mooring and collision detection capabilities. While both Proteus® and Chrono® were extensively modified to fit the needs of the FSI framework, the framework itself is built upon the Proteus® toolkit where Chrono® is built as a dependency when compiling the source code. At the time of writing, the code repository of Proteus® is available online at https://github.com/erdc/proteus, where all contributions for building the FSI framework presented here are recorded. Therefore, the majority of the software development work that has been done for this research is available online and can be used to reproduce any of the simulations from Section 5.

When building this FSI framework, the Chrono® library was mostly written in C++ (with relatively limited high-level Python access), while Proteus® was written in Python for high-level access and C++ for low-level access and efficiency. Both Python and C++ have therefore been extensively used for the implementation of the different models and tools presented here. Interfacing between these two languages and libraries was a major aspect of software development, as can be seen conceptually in the workflow diagram of Figure 4 where the main necessary communication steps between Proteus® (CFD) and Chrono® (MBD and mooring dynamics) are represented. This communication was mostly achieved with Cvthon, an interfacing language between Python and C++ that allows for sharing objects or pointers between the two languages. Cython also allows to convert automatically Python-like code to C/C++, and was therefore also used to increase the computational efficiency of several parts of the code in Proteus® that were originally designed in Python, but were proven to be time-consuming (e.g., relaxation zones).

Another major recurring aspect that had to be considered for the implementation of the methods presented here was parallelisation of the code. Most of the cases presented in Section 5 were typically medium or large FSI problems, in terms of domain and mesh size. These are recommended to be run in parallel, as decomposing the simulation into parallel tasks reduces both the power and the memory required by each task. This was achieved on a large scale by using HPC and the Messaging Passing Interface (MPI) for the CFD model. At the time of performing the simulations in de Lataillade (2019), the MBD solver was not parallelised when using FEM and collision detection, but this was not a major issue as the MBD solver-typically much faster than the CFD solver—did not pose a significant time overhead. Note however that for more demanding MBD problems (e.g., collision detection with mutliple bodies, deformable structures, very highly refined cables, etc.), it is recommended to include this parallel capability once ready.

It is also worth noting that, on top of the FSI framework presented here and at the time of writing, various additions were being added to the open-source Proteus® project: Immersed Boundary Method (IBM), mesh adaptivity, sediment solver, turbulence models, shallow water equations, and improvement over free surface tracking methods. Due to its open-source nature, the freely-accessible high-fidelity FSI framework that has been developed and presented here is also likely to undergo further development and improvement within the Proteus® toolkit.

 
<<   CONTENTS   >>

Related topics