[Stan Zhou]

Originally Posted by Phicau

Hi Stan,
1) You are right, 'useTransient' is false by default, therefore the oscillatory flow enhancement is disconnected. This is to allow using the porous media friction in cases such as the dam break tutorial included in olaFlow, in which the flow is not oscillatory. If can connected in cases in which you have oscillatory flow and you want to consider the turbulence enhancement created by the oscillatory flow. In that case you set 'useTransient' to true and you also need to provide the value for KC in the dictionary.

2) The default value of 'useTransMask' is 0, so it will have no effect if not intended to. Similarly, 'KC' default value is 1, to prevent dividing by 0, but that is irrelevant because 'useTransMask' is 0 already.

3) I suggest that you take a look here: How to give enough info to get help There are thousands of things that can contribute to getting unexpected values. I would suggest you starting with a simpler mesh/case to validate the case and select the porous media parameters. A quick sanity check is that the hydrostatic pressure is alright; if that is not the case you know you have probably done something wrong.

Best,
Pablo

Hi Pablo,

Thanks for your reply and the advice. I'll try to validate the case as your suggestion.

Sincerely,

Stan

[CallumG]

Hi Pablo and others,

has anyone ever set a shear velocity profile at the inlet using the currentWaveFlume as a base?

If I was to set a 7th power law to a standard simulation I would use something like:

    

inlet
    {
        type        groovyBC;
        variables   "u_mean=10;z_var=mag(pos().z+0.82);h=1.9;";
        valueExpression "vector(u_mean*pow(z_var/(h*0.4),1./7),0,0)";
    }

In my 0/U file and add the additional libraries to my controlDict. In the currentWaveFlume tutorial we have:

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
        type            waveVelocity;
        waveDictName    waveDict;
        value           uniform (0 0 0);
    }
    outlet
    {
        type            waveAbsorption2DVelocity;
        uCurrent        (0.75 0. 0.);
        value           uniform (0 0 0);
    }
    bottom
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    atmosphere
    {
        type            pressureInletOutletVelocity;
        value           uniform (0 0 0);
    }
    frontAndBack
    {
        type            empty;
    }
}

I was just hoping someone could help me with how to impliment my goovyBC from the first bit of code into the olaFlow U dictionary.

Any help really appreciated!

Cheers,
Callum

[Phicau]

Hi Callum,
The public release only includes a simple constant current, although I have tested sheared currents and higher order velocity profiles successfully.


The implementation is really easy. Oversimplifying things a bit you need to populate https://github.com/phicau/olaFlow/bl...ofileCurrent.H with the relevant profile, as performed in the other files in the same folder. Wave absorption needs some changes too.


For wave + current you would need to define another variable (or += the existing one) and edit https://github.com/phicau/olaFlow/bl...ocityProfile.H to perform both calculations. If you choose the former, you will need to add everything together towards the end of https://github.com/phicau/olaFlow/bl...hVectorField.C . Either way, I suggest keeping the uCurrent_ variable and converting it to a unit vector, to set the direction of your current easily.


Best,
Pablo

[CallumG]

Hi Pablo,

thanks very much for your reply!

When you say populate the profileCurrent.H is this anywhere near correct?

        if (zSup[cellIndex] <= heights[cellGroup[cellIndex]-1])
        {// Full cell
            patchU[cellIndex] = uCurrent_*pow(zSup[cellIndex]/(watrDepth_*0.4), 1/7)

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

            patchW[cellIndex] = 0

        }
        else if (zInf[cellIndex] < heights[cellGroup[cellIndex]-1])
        {// Partial cell
            auxiliar = heights[cellGroup[cellIndex]-1] - zInf[cellIndex];
            auxiliarTotal = zSup[cellIndex]-zInf[cellIndex];
            auxiliarTotal = auxiliar/auxiliarTotal; // VOF of the cell

            // Height corresponding to the partial cell
            auxiliar = zInf[cellIndex] + auxiliar/scalar(2);
            if (!extrapolation_)
            {
                auxiliar = zExtra;
            }

            patchU[cellIndex] = auxiliarTotal*uCurrent_*pow(zSup[cellIndex]/(watrDepth_*0.4), 1/7)

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

            patchW[cellIndex] = auxiliarTotal*0
        }
        else // Empty cell
        {
            patchU[cellIndex] = 0;
            patchV[cellIndex] = 0;
            patchW[cellIndex] = 0;
        }

Secondly, when you say wave absorptions needs some changes, could you give me some more information on what editing is required?

For the wave + current can I just now add #include "profileCurrent.H" to a current waveType like this:

    if ( waveType_ == "regular" )
    {
        if ( waveTheory_ == "StokesI" )
        {
            faseTot = waveKx*xGroup[cellGroup[cellIndex]-1]
                + waveKy*yGroup[cellGroup[cellIndex]-1]
                - waveOmega*currTime + wavePhase_;
            #include "profileStokesI.H"
            #include "profileCurrent.H"

        }

Finally, if you have any editted files left over from your successful tests that you wouldn't mind sharing it would be a great help. I'm still very inexperieced programing in OpenFOAM so could use all the help I can get.

Thanks again for you support, it is very much appreciated!

All the best,
Callum

[Rob4]

Hi all,

I am fairly new to olaflow and was wondering how to implement a Salome mesh alongside the blockMesh of the piston wavemaker tutorial. Whenever I use ideasUnvToFoam to implement my salome mesh it overrides the blockMesh and alpha.water. Is there a command where I can add the salome mesh to the polyMesh folder without it deleting everything already there?

Kind regards,
Rob

[Phicau]

Hi Callum,
The first implementation looks alright, however for the second you might need to implement it slightly different, with += instead of = to prevent the wave values being overwritten by the current.
We'll continue our communication via email.


Hi Rob,
Since you don't provide much information on what you want to do with the Salome mesh along with the other one, I can't offer you an answer. However, this issue is particular enough (mesh-related, not related with olaFlow) that I would suggest to open your own thread in https://www.cfd-online.com/Forums/openfoam-meshing/
Just a final comment, I don't see the reason why ideasUnvToFoam would modify alpha.water. Mind you, it will make it not compatible if you had already run setFields on it due to the different new mesh, but you could always copy over the original file from the 0.org folder and adapt it as needed.


Best,
Pablo

[Stan Zhou]

Hi Pablo,

Recently I'm studying your thesis and the codes in OlaFlow. However, I'm quite confused about a few variables in OlaFlow and I'll appreciate it if you could give some advice.

1) AFAIK, the closure term are divided by porosity(phi) and then added into the momentum conservation equation as shown in https://olaflow.github.io/numerical-...model-physics/. In equation 4.56(as shown in Figure 1), there is no density(rho) in the transient component. However, when shifting the transient component to the left side, it is directly merged with the original transient term which has density(rho). Is there anything wrong? Or there is density in the transient component which is missed in equation 4.56?

2) In the createPorosity.H, there is

porosityF = fvc::interpolate(porosity);

. As the porosity is considered as constant in the simulation, why do we need to interpolate porosity here and use both porosity and porosityF to calculate the convection term in UEqn.H?

1.0/porosity * fvm::div(rhoPhi/porosityF, U)

- fvm::laplacian(muEff/porosityF , U)

3) In order to achieve partitioned coupling, I want to add the displacement calculated by an in-house solver onto the border of a structure or the porous media and then update the mesh. As it is related to dynamic mesh method and cell movement on the boundary, I wonder if olaDyMFlow could deal with it. To my knowledge, it's easy for olaDyMFlow to solve dynamic mesh cases. But for moving the mesh of every cell on the boundary based on the displacement obtained from an in-house code, even though I've done some searches, I still don't know how to achieve this. Do you have any ideas about this problem? Any suggestions your could provide would be appreciated!

Best regards,
Stan

[Phicau]

Hi Stan,
- Yes, I skipped a couple of steps there, and there might be some typos. C is the whole term (as A or B) which should include density and porosity, and it is c the empirical coefficient ( = 0.34).
- Porosity needs to be interpolated to the faces to be included in the discretised equations.
- Yes, olaDyMflow should be able to deal with this, you just need to code your own BC for the coupling. However, note that if you are moving the porosity around, you need to add more terms in the equations as shown in my thesis and in a book chapter that I will be publishing next month.


Best,
Pablo

[Stan Zhou]

Originally Posted by Phicau

Hi Stan,
- Yes, I skipped a couple of steps there, and there might be some typos. C is the whole term (as A or B) which should include density and porosity, and it is c the empirical coefficient ( = 0.34).
- Porosity needs to be interpolated to the faces to be included in the discretised equations.
- Yes, olaDyMflow should be able to deal with this, you just need to code your own BC for the coupling. However, note that if you are moving the porosity around, you need to add more terms in the equations as shown in my thesis and in a book chapter that I will be publishing next month.


Best,
Pablo

Thank you for your reply and hope to see your book soon ！

[Pilardc91]

Hello all,

I'm running simulations with regular waves (Stokes I). I've tried different meshes and time steps and I've noticed my cases converge towards a wave height H_si=0.10m. However, the target value (waveHeight) I put in waveDict is 0.121156. I have everything set to first order in fvSchemes.

Does anybody have an idea as to why this difference? How could I solve it?

Thanks!

[Phicau]

Hi Pilar,
If you are sure that Stokes I is the correct theory to use, that your mesh size is adequate, and since you mention that you have achieved mesh convergence, it is time for you to tune your wave height.


Best,
Pablo

[Pilardc91]

Hi Pablo,

Thank you very much for your response.

I will check first the theory generation of the waves. What do you mean by tuning the wave height, playing with other parameters in the FvScheme folder?

Regards,
Pilar

[Phicau]

Hi Pilar,
as simple as increasing the waveheight multiplying by a tuning factor > 1.


Best,
Pablo

[Stan Zhou]

Originally Posted by Stan Zhou

Hi Pablo,

These days I've been doing a simulation about a breakwater on the porous seabed using olaFlow. The schematic diagram of the numerical model is shown in the attachment. There are two kinds of porous media in the seabed and there are rubble mound in front of the breakwater.

The turbulence model I chose was KEpsilon and the wave theory adopted was Stokes V. The number of mesh grids are about 1800000. My main focus of the simulation is the pressure or force on the breakwater. As the first simulation result is a bit lower than I expected, I ran a second case with the same mesh and initial conditions. The wave profile of the two cases is similar. However, the pressure at the same point on the breakwater is two times of the first case.

I'm quite confused about this problem. Why could two cases with the same mesh and initial settings lead to different numerical results? Is the problem caused by the wrong choice of turbulence model? Or it is because the mesh near the breakwater is coarse which lead to the convergence of the wrong result?

Thanks in advance!

Sincerely,
Stan Zhou

Hi Pablo,
I've done two simpler cases similar to this case (also cases of caisson breakwater with seabed but not complicated like this) and the numerical results were basically the same with the same mesh and initial conditions.

As the information I provided before was not enough to find out the problem, I will try to describe it in detail.
The horizontal size of the computational domain is about 1000m and the veritical size is 120m. The total thickness of rock and two porous media is about 100m (so is the initial water depth). The turbulence model I chose was K-Epsilon and the wave theory adopted was Stokes V (wave height is 12m and period is 12s). The wave generation BC is on the left side and the wave absorption BC is on the right side. The distance between the wave generation BC and the lower left quarter of rock is about 600m. The rock, rubble mound and caisson breakwater are considered as impermeable, so they are removed from the mesh. As our main focus is the pressure on breakwater, the mesh scale around the breakwater is 0.05m in both x and z directions which I think is small enough in such a large computational domain.

Based on these test cases, I think the main reasons why my former cases' results changed even if the mesh and initial conditions were the same might include two parts:

1) The rapid change of terrain leads to the sudden drop in water depth (from about 100m to several meters) which may cause significant wave breaking. The long reef flat makes it difficult for the inflow to return back to the sea. Additionally, the complex terrain on the reef flat makes it even harder for capturing the evolution of waves. Thus, the waves spread differently even with the same initial setup.

2) The choice of turbulence model. In my cases I chose K-Epsilon as it is widely used. However, is it better to choose RNG K-Epsilon or K-Omega SST model as K-Epsilon might be bad at dealing with pressure on structures.
(I've tried to use K-Omega SST model but it stopped quite fast, just several minutes. Maybe this is due to its higher convergence criteria?)

Any comments and suggestions will be appreciated!

Best regards,

Stan

[MIH_ANSYS]

Hi Pablo and others,

I have imported the .stl file to triSurface folder, and have changed all patches to the cylinder name (name of the stl file). I use the floatingObject tutorials.
when I implement the snappyHexMesh, it shows a successful meshing. but in paraview I have got nothing. how can I add my stl file to this tutorial instead of default floatingObject?


tanx in advance

Regards

[sercro]

Hello Milad,

I'm not sure what you mean by that you got nothing. Have you checked if you're looking at the right time step in paraview (usually snappyHexMesh creates subsequent instants for each step).

I'm not familiarized with that tutorial but usually I have to also create an eMesh file (with surfaceFeatureExtract) and make sure the location in mesh coordinates (in the snappyHexMeshDict) correspond with my geometry.

Regards,

[MIH_ANSYS]

Dear Sergio.

thanx for the reply

yes, I check the right timestep.

this tutorial is about a simulation of floating objection interaction with waves. it has a default cubic object with is defined in blockMesh.

I want to change the geometry and use stl file and use the olaDyMFlow solver.

after implementing the necessary settings, it seems this new geometry (.stl file) has not been added.

I do not know why.

maybe I cannot add an external geometry to this tutorial at all.

Regards

[Phicau]

Hi Milad,
there are numerous reasons why this may happen, the most common being having some typos or not keeping naming consistent in snappyHexMeshDict.

Creating such a case is possible. However, what you are experiencing is a meshing issue which is unrelated with olaFlow, so I would suggest opening a thread in https://www.cfd-online.com/Forums/openfoam-meshing/ to obtain more visibility.
Please then remember to provide enough information, see How to give enough info to get help

Best,
Pablo

[Pilardc91]

Hi Pablo,

Thank you very much for your response.

I checked the Generation Theory and I run the same cases with Stream Function instead of Stoke I. The meshes converge and I had the same results in Hs but not in the reflection coefficient (KR is bigger with stream function); the free surface signal with stream function looks more like the one in the laboratory.

I still get Hs < Htarget, so I will have to tune the wave (as you told me). What happens is that I am not very convinced about this solution; that is, I do not know if it is something normal when testing very small heights of 0.10m or 0.12m, or if I should touch other parameters before, for example, the divergence method.

Thank you very much in advance and sorry for bothering you again.

[Phicau]

Hi Pilar,
Any reasonable approach that you can justify is fine.

Best,
Pablo