Fluid particles go across a solid boundary with modified dynamic boundary conditions
I grew interested in testing the modified dynamic boundary conditions for rapid fluid-structure interactions (problems of water entry and wave slamming).
I have simply replayed the 3D dam-break test case of [pkg]/examples/mdbc/04_Dambreak/CaseDamBreak3D_Def.xml. Data, code and tools are taken as is from DualSPHysics5 v5.10.164 (21-11-2020). In the path above [pkg] is the root of the package downloaded from the website.
This is the dam-break benchmark endorsed by SPHERIC (https://spheric-sph.org/tests/test-2) and is different from the dam break of the 'main' suite of examples. In this benchmark, the central point for attention is a low object in the middle, a mock container, where pressure sensors were mounted. There, the fluid flow looks fine. However, unexpectedly for me, the solid boundary does not quite hold back the fluid elsewhere.
I have attached three snapshots. They show a side view of the 3D domain sliced along the plane of symmetry. The view is clean of perspective effects (purely 2D).
An animation of the first three of six simulated seconds is available from this unlisted Youtube link
Fluid particles do enter in great numbers into the solid boundary, and keep on roaming in there. This anomaly is not caught by the 'particle out' total, arguably because these particles neither leave the greater simulation domain nor suffer from otherwise abnormal state values.
While the evidence is contrary to a basic expectation of physical solidity, I am fine that this anomaly shows up. Its extent can be appreciated visually at least. This raises concerns, however, on the accuracy of the fluid-structure interactions where these spurious effects might occur, discounting any why they do.
It would be important, rather, to know whether this escape of fluid particles across a solid boundary is consequential for sound results, and how much. I might have missed thousands of resources where this limitation is already acknowledged.
Is the current implementation of the modified boundary conditions in DualSPHysics5 still subject to research? Are there any caveats and provisos with a quantitative backing?
From a user's perspective, are there ways to mitigate these effects? Or is falling back on the conventional dynamic boundary conditions still the practitioner's failsafe option?
Thanks for looking into this.
Comments
Thanks for the email.
In fact the modified boundary condition is an approach still under developemnt, several issues still need to be solved and slip modes need to be implemented. However we found it robust enough to allow users to start playing with that so we can all learn more about strengths and limitations.
In this dam-break example (https://youtu.be/DgO8kPHkTEU) the good news are that we can measure now the pressure at the exact pressure gauge locations as the ones defined in the experimental test since there is no gap between fluid and boundary any more. In terms of accuracy comparing with experimental data, both numerical surface elevation and pressure values are in very good agreement using mDBC, while using DBC numerical pressures were not accurate enough and the pressure gauge location should be displaced.
Regards
For completeness of illustration, the snapshots and animation below show the simulation of the DualSPHysics test case above, but with the boundary-conditions type set to the conventional dynamic form. This is merely the change of a single simulation parameter, applied in an uncritical fashion as far as the rest is concerned. The simulated times in the snapshots are the same.
@Alex Thanks to you. What is the way preferred by the DualSPHysics to receive feedback on this and learn more about strengths and limitations? Thanks for directions.
I guess that an email is the best way...
However note that since we have many different duties in our institutions we usually work on the online code like one month per year, where we try to work together among the different institutions and we improve the code and the documentation, we solve bugs, and we release new stuff... so we can take a look to all these issues when we are focussed on this or when we find same problems applying the code in our projects.
Regards
Thanks for clarifying this. In the net, the chances for the Developers to pick up on a point appear very much restricted in time, space and alignment of interests --- fair enough. While waiting for this multi-factor event to happen, hearing from other users of the red, amber and green lights of DualSPHysics could possibly be mutually helpful in the concrete, where time and money is invested and budgeted.
To this end would then the Developers also consider contributions to the Workshop rather than emails?
@iarba27 in copy for the convener's information
@sph_tudelft_nl "While waiting for this multi-factor event to happen, hearing from other users of the red, amber and green lights of DualSPHysics could possibly be mutually helpful in the concrete, where time and money is invested and budgeted."
PLEASE share that money with us and then you will be a priority and multi-factor event will be perfectly aligned with you FOR SURE.
@Alex I wish I could and, if I possibly could, I possibly would. But I cannot.
@anyreader The point of my observation above is that, while each sorts his own priorities as is fair, it can be beneficial to share any attempt to "fix stuff" with the community at the workshop. I feel this has been missed, so I state it again.
Now my concern is that the workshop is only an event for showcasing success stories and not a place where "we can all learn more about strengths and limitations".
@iarba27