[Phicau]

Hi Georgia,


why do you believe the boundary condition is the source of your error? Everything looks ok to me. Evidence seems to point out that the BC is not the problem, but if you are ever in doubt just substitute the wave generation BCs for walls and see if the case still fails. Sometimes you may need to add a hump of water to get some water velocities started.


The porous terms changed after that publication, see my thesis for an updated version: https://olaflow.github.io/numerical-...el-references/ , therefore, I suggest that you if you lack validation data from which to find the relevant alpha and beta values, you use the ones in the breakwater tutorial as a starting point. Also note that the model is not suited for very small values of porosity, as friction forces tend to infinity in that case.


Another possible factor that can induce such high velocities is a bad mesh.


Best,
Pablo

[renos]

Dear Pablo,

First of all, thank you for your help all this time. I am stuck in the explanation of the results that I have.

I am trying to simulate breaking waves interactions with structures such as monopiles. I had made a convergence study and my results are close to the experimental results.
Although, because I am using a turbulence model ( k- omega SST ) and wall functions are activated near the walls the maximum yplus value during the wave breaking is very big (around 5000) and the average is 500 and minimum around 0.2 .

What should I do with the results?

Are the results correct?

Why I have very close results with the experiment despite of the high value of Yplus?

Also I dont know what are the correct values of Yplus in a multiphase simulation because we have 2 fluids with different properties the Yplus value is very different.

Thanks you very much,

Kind regards,

Renos

[georgiak]

Dear Pablo,



Thank you very much for your recommendations and the reference. I will update the coefficients.



I think that the main problem was the mesh. The bottom is sloped and by doing a blockMesh with inclined bottom posed problems to the alpha water (small alterations between cells). I did a blockMesh of rectangular boxes and just adjusted the bathymetry with snappyHexMesh and 0-level refinement and it works perfectly.



Thanks again!


Georgia

[Phicau]

Hi Georgia,
I am glad to hear that the problem is solved.


Hi Renos,
I think those questions should be addressed better with your supervisor or you could open your own thread, since they are not directly related to olaFlow. This way they will have more visibility from other users interested in turbulence modelling.

My two cents here will be not to pay excessive attention to the air phase, it is known to have very large velocities but if it is non compressible the vast majority of the force on the cylinder will come from the water phase.


Best,
Pablo

[aow]

Hi Renos,
I think those questions should be addressed better with your supervisor or you could open your own thread, since they are not directly related to olaFlow. This way they will have more visibility from other users interested in turbulence modelling.

Renos,

I agree with Pablo's response above concerning your questions, which you also sent to me directly. Everyone in the community stands to benefit if posts/comments are made publicly rather than privately and if I actually have time I will respond to a thread; if I don't then I'm busy.

To give a general comment on the issue you brought up, if you're using wall modeling functions, the fact that y+ is large in a lot of areas is not necessarily an issue. As long as you have some level of refinement near your monopile, then using wall functions will help resolve boundary layer phenomena. Most references on wall function modeling give the "acceptable" range as 30 < y+ <300, but the upper limit is subject to change a bit depending on the Reynolds number. If you really want super accurate boundary values, you ought to fully-resolve the boundary layer down to y+ ~ 1 (i.e. for sure well into the viscous sub-layer near the boundary even for high Reynolds numbers), in which case it is usually recommended to not use wall modeling as far as I know.

Despite all of this, based on my my experience modeling wave impact phenomena, you can get away without going down to very small y+ values in the viscous sub-layer. In situations like this, my intuition is that inertial forces tend to dominate the resultant force since the Reynolds number is usually quite large so the viscous forces on the sides of your pile are probably dwarfed by the inertial impact force on the face struck by the wave. I've not done fine enough mesh models to compare the benefit of including a high level of mesh resolution to get to a small y+ value, but based on the consistency with which I was able to reproduce experimentally measured forces for various multi-structure configurations I would say this intuition isn't a bad one. Be that as it may, you still need to be careful which turbulence model you select for your modeling and create a high-quality mesh without skew and non-orthogonality. More specifically, you need to use a turbulence model that is capable of capturing the sort of phenomena you're modeling. For example, the basic k-epsilon model, which was developed to model attached flows over airfoils, failed to give accurate, consistent results when I applied it to wave impact modeling on a box-like structure, where significant flow separation occurred. I ended up settling on the k-omega SST model instead since it was designed to handle flow separation better than other two-equation models. I tried Reynolds stress models too, but didn't see a notable benefit over the k-omega SST model. Also, Reynolds stress models make it much harder to create stable models (e.g., I succeeded with the Launder-Reece-Rodi model, but not with the Speziale-Sarkar-Gatski model during trial runs).

Anyway, if you're getting the results you're looking for even with large y+ values, you probably ended up in a similar situation as I did: simulating a high-Reynolds number flow that ended up producing an accurate resultant wave impact force, but probably doing a bad job of resolving localized boundary layer behavior.

Good luck!

Andrew

[sercro]

Hello all,

Are the new turbulence models compatible with compressible solvers? My cases with olaFlow or interFoam run fine using kOmegaSSTStable but whenever I try do a case using compressibleInterFoam I got the message:


--> FOAM FATAL ERROR:
Unknown RASModel type kOmegaSSTStable

Valid RASModel types:

13
(
LRR
LaunderSharmaKE
RNGkEpsilon
SSG
SpalartAllmaras
buoyantKEpsilon
kEpsilon
kOmega
kOmegaSST
kOmegaSSTLM
kOmegaSSTSAS
realizableKE
v2f
)

Even though I have the libraries duly added in controlDict:

libs
(

"libturbulenceMultiphaseOlaFlowModels.so"
"libwaveGeneration.so"
"libwaveAbsorption.so"
);



Thanks!

[asalm]

Hi there,

Thanks for putting this great toolbox together. I am having problems compiling and running on our machine.

I can successfully compile the BCs and solvers for openFoam 7 on a HPC cluster running a module of openFoam 7 - however, I can only achieve this by creating two new directories for $FOAM_USER_APPBIN / $FOAM_USER_LIBBIN locally to avoid permissions errors.

When the compilation is complete, I am unable to run the 'olaFlow' solver. Is there a fundamental problem that it is not in the the original '$FOAM_USER_APPBIN' location with the other solvers? Any help would be greatly appreciated.

As a subnote - has anyone successfully compiled for Helyx-OS?

Thanks

[love_huang]

Dear Pablo:
I have read the Fenton reference paper about the streamfunction, but I am confused about the patchU calculation in 'profileStreamFunction.H'; I just show the copy code in following:

patchU[cellIndex] = celerity - uMean_
+ sqrt(g*waterDepth_)*waveK*waterDepth_*patchU[cellIndex];

patchV[cellIndex] = patchU[cellIndex]*sin(waveAngle);
patchU[cellIndex] = patchU[cellIndex]*cos(waveAngle);

patchW[cellIndex] =
sqrt(g*waterDepth_)*waveK*waterDepth_*patchW[cellIndex];

Base on last equations, when the wave speed, celerity, is equal to uMean, then it will be a regular wave in tank. How when I want to simulation the wave with current, which means celerity is not equal to uMean, finally the regular wave is moving forward with (celerity - uMean)*cos(waveAngle)?
Is that right? can you enlighten me?
Best regards.

[Phicau]

Hi Sergio,


that is weird, I will take a look at it tomorrow.


Hi asalm,


it seems a very weird issue with the permissions, yes. Normally you should be able to have write and execute permissions in the USER folders, which should be only for you to prevent messing things for other users. This is probably an issue regarding your OpenFOAM installation, so it is worth posting it here instead https://www.cfd-online.com/Forums/op...-installation/


Hi Shanqin,


I don't remember this exactly, please check the reference manual for a full explanation. What I remember is that there are some tweaks in the code to correct some bugs that Fenton had in his original code and that he later fixed, that is why we request people to use Fenton's old version of the program. From what I remember, if you want a current with the streamfunction theory, you needed to include it in the input to Fenton's program.
Nevertheless, I am working in a new implementation of the streamfunction theory which I will be releasing at a later stage.


Best,
Pablo

[Phicau]

Hi again Sergio,

incompressible turbulence models are in a different class, that is why the turbulence models are not listed, because compressibleInterFoam is looking for compressible turbulence models only.

I have now added a Dev branch to https://github.com/phicau/olaFlow_supplementary in which the models are compiled as compressible turbulence models too. In order to use it you will need to follow a procedure similar to the one outlined here https://olaflow.github.io/blog/new-b...ed-to-olaflow/

I have just compiled but not tested the new turbulence models yet, so if you run into trouble keep in touch via email.

Best,
Pablo

[love_huang]

Originally Posted by Phicau

Hi Sergio,


that is weird, I will take a look at it tomorrow.


Hi asalm,


it seems a very weird issue with the permissions, yes. Normally you should be able to have write and execute permissions in the USER folders, which should be only for you to prevent messing things for other users. This is probably an issue regarding your OpenFOAM installation, so it is worth posting it here instead https://www.cfd-online.com/Forums/op...-installation/


Hi Shanqin,


I don't remember this exactly, please check the reference manual for a full explanation. What I remember is that there are some tweaks in the code to correct some bugs that Fenton had in his original code and that he later fixed, that is why we request people to use Fenton's old version of the program. From what I remember, if you want a current with the streamfunction theory, you needed to include it in the input to Fenton's program.
Nevertheless, I am working in a new implementation of the streamfunction theory which I will be releasing at a later stage.


Best,
Pablo

Hi Pablo:
Thanks, I get it. Best regards.
------------------
Shanqin

[wo315]

Hi Pablo:

Do you have any plans to update your reference manual?

Thanks!

[sercro]

Hello Pablo,

I just updated the code and added the library in controlDict, it works fine.

Thanks!

[Schub]

Hi Pablo,

Firstly, thanks so much for all the help you've provided to others on this forum, I've been looking through and trying various things that have been suggested. Unfortunately I still haven't been able to adequately get my scenarios working as desired after many (many) months. I'm hoping you might be able to spot something I'm doing incorrectly or point me in the right direction.

For context, I'm trying to model the dynamic response a submerged "floating" object with a nonlinear control mechanism (effectively a bistable system) subjected to waves of different frequencies. It has been restricted to 3 DOF for simplicity - surge, heave, and pitch. I have achieved convergence of waves and have actually validated against experimental data. I have managed to get the CFD models working with the higher frequency waves (I suspect because of the much lower amplitude response and therefore less complex dynamics).

But for all other cases, I see the velocity and pressure spike up to infinity after some time of running smoothly, between ~2-30 seconds depending on the excitation frequency. When this happens, the Courant number is also quite large, despite having set a maximum, the timestep gets very small, but the volume fractions remain reasonable. I have seen that this spike often occurs in cells around the edge of my object, so I suspect it's due to larger mesh deformations. However, when I start the scenario with a wave height of 0, the buoy settles nicely to it's non-zero equilibrium position (as expected due to the bistable potential well). Which indicates to me that it's not just mesh deformation, but the combination of the wave pressure and push away from the unstable equilibrium position. Is there any way to introduce the wave after a certain amount of time, just to let the object settle first?

The desired scenarios have consistant wave heights but different frequencies with corresponding control stiffness and damping coefficients which have been locally optimised in matlab using linear hydrodynamics, so the response is expected to be close to resonance for some frequencies (and matches well for higher frequencies). So I'm confident it's heading in the right direction.

In my attempts to solve it over the past 6 months I have tried many variations on mesh qualities in snappyHexMeshDict, solver settings in fvSolution, changing mesh resolutions and aspect ratios, Courant numbers, dynamic mesh solver settings in dynamicMeshDict, additional edge snapping tools for the mesh, various layer additions, OpenFOAM v4.2 and v7, tweaking relaxation and/or compression factors, changing the mesh deformation area around the object, as well as other things I've come across and I still don't seem to have any consistent success.

I've attached a picture of my mesh, and an example case. Is there anything obviously wrong in snappyHexMeshDict, waveDict, dynamicMeshDict, controlDict, or fvSolution? Or is there something else I'm missing?

Any suggestions, thoughts, or directions your could provide would be appreciated. I'm happy to provide further info if that's useful .

Kind regards,
Ben

[Phicau]

Hi Wang Yang,
yes, it is certainly in my to do list but I don't think it will happen anytime soon. It will probably happen some time after I roll out the newer version, which has significant changes in the code, sampling tools…

Hi Sergio,
glad to hear that!

Hi Ben,
yes, running floating structure simulations in OpenFOAM has been quite tricky since the early days in which changing some parameters in the floating object tutorial led to the case crashing.
Although I cannot provide a solution to deal with pressure instabilities other than using some overrelaxation and ad-hoc limiting/smoothing of stupidly high velocities, you are right in that normally having your structure in equilibrium when you start the simulation helps.
The way to do this is simple and can be easily scripted.
You substitute the wave generation and absorption BCs for wall BCs.
Run the simulation for some time.
Once the structure is close to the equilibrium state, stop the case.
Run the same setFields as in the beginning (make sure that you set U to 0 too).
Restart the case. Is the structure still moving? Then go back 3 steps.

When you are happy with your structure equilibrium, copy that folder into a new case and name it 0.
Open the alpha.water and U files and change the wall boundary conditions at the inlet and outlet back to normal to start generating and absorbing waves.

Hopefully this will help, otherwise if you encounter additional problems feel free to come back.

Best,
Pablo

[Stan Zhou]

Dear Pablo,

I am trying to simulate a breakwater case using olaFlow. However, I have some questions about the coefficients in porosityDict and I sincerely hope you could give me some advice.

In the porosityDict, there are three friction coefficients a, b, and c. I think these coefficients are the same as the A, B, and C in OlaFOAM Reference Manual if I understand correctly. As it is shown in the Manual, to calculate A and B needs two more coefficients α and β. I know these two coefficients can be obtained from experiments, but when it comes to numerical simulations, the values of α and β used by researchers are quite different. I wonder how α and β are determined in simulations and whether there are any rules or methods to choose their values.

Secondly, in the equation for calculating B, there is a Kc number. In order to calculate Kc (Kc=VT/L), the velocity of the flow V and a characteristic length L are needed. I am quite confused about how to determine their values.

Additionally, as there are both fluid and porous media in the simulation, I wonder whether the rho in the equation for calculating B means the density of fluid or the dry density of porous media?

Best regards,
Stan

[Phicau]

Hi Stan,
a, b and c are alpha, beta and c.
You can find all the information on how I derived them in my thesis: https://olaflow.github.io/numerical-...el-references/


KC is implemented but not connected by default. I don't use it often, but to answer your question, T is the wave period and L is D50 of your rocks.


rho is the density of the fluid. VARANS considers the rocks as rigid and static, so their density or other properties other than D50 and the porosity of the arrangement are not required at all.


Best,
Pablo

[Stan Zhou]

Dear Pablo,


Thank you very much for your suggestions!


During the past months, my colleague has obtained the coefficients A and B of a kind of sand which we are studying through a lot of experiments. Because α and β are empirical coefficients, we want to adopt the two actually measured coefficients A and B to do our simulation rather than use d50, n, α and β to get approximations of A and B. However, I don't know where I can input my coefficients A and B directly instead of using d50, n, α and β.


Is there any possible way to input A and B directly into the VARANS equation?


Best regards,

Stan

[Phicau]

Hi Stan,


I believe that your approach fixing A and B is as empirical as selecting alpha and beta, since when D50 and porosity are fixed, A and B are linked with alpha and beta in a direct way.


Nevertheless, yes, you can set A and B yourself quite easily. The code is open source, so download it, make the substitutions and changes that you require and compile it.


Best,
Pablo

[Schub]

Originally Posted by Phicau

Hi Wang Yang,
yes, it is certainly in my to do list but I don't think it will happen anytime soon. It will probably happen some time after I roll out the newer version, which has significant changes in the code, sampling tools…

Hi Sergio,
glad to hear that!

Hi Ben,
yes, running floating structure simulations in OpenFOAM has been quite tricky since the early days in which changing some parameters in the floating object tutorial led to the case crashing.
Although I cannot provide a solution to deal with pressure instabilities other than using some overrelaxation and ad-hoc limiting/smoothing of stupidly high velocities, you are right in that normally having your structure in equilibrium when you start the simulation helps.
The way to do this is simple and can be easily scripted.
You substitute the wave generation and absorption BCs for wall BCs.
Run the simulation for some time.
Once the structure is close to the equilibrium state, stop the case.
Run the same setFields as in the beginning (make sure that you set U to 0 too).
Restart the case. Is the structure still moving? Then go back 3 steps.

When you are happy with your structure equilibrium, copy that folder into a new case and name it 0.
Open the alpha.water and U files and change the wall boundary conditions at the inlet and outlet back to normal to start generating and absorbing waves.

Hopefully this will help, otherwise if you encounter additional problems feel free to come back.

Best,
Pablo

Hi Pablo,

Thank you so much for your help, I've finally managed to get something that doesn't crash after simulating for 10-30 seconds. My fix was carefully selecting the mesh quality parameters in snappyHexMeshDict. However, the simulations seem to stop later ~45-100 seconds and they seem to be quite closely linked with the mesh deformation region. I've attached a number of figures showing this condition. I figure that since the buoy had somewhat settled into a lower equilibrium position, the source of the new error is not due to the complex nonlinear bistable forces acting at the start of the simulation and I have therefore abandoned plans to run, settle, and then restart.

I have also observed that the level of water can rise, or decrease in the time leading up to the failure (which is still a velocity spike - tiny time step - huge forces etc.) I suspect this might be due to water level poking out into the coarser mesh after the mesh deformation due to rotation becomes significant, which I guess could lead to more extreme motions and instabilities. (example in pictures, surface should only vary +/- 0.5m, but alpha indicates water drifted to -4 or -5 just outside the high resolution region)

I've tried changing the inner and outer distances in the dynamicMeshDict and then increasing the domain so that the deformation doesn't interact with the boundary (which also caused crazy velocities).

Are there any suggestions that spring to mind in regards to mesh deformation robustness? (does the diffusivity option work with sixDoFRigidBodyMotion to your knowledge?)

What do you make of the reduced or increased volume of fluid over time/ any ideas on how to fix it?

One thought I had was that perhaps the mesh displacement was not subject to the maximum Courant number condition and could therefor really mess with the calculations. Though I'm not an expert and do not have the skills to go digging into the source code at this stage, so I can't confirm that is the case.

Thanks in advance for you thoughts

Kind regards,
Ben