CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions

[OLAFLOW] The OLAFLOW Thread

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree46Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 5, 2021, 03:03
Default
  #281
Member
 
Haoran Zhou
Join Date: Nov 2019
Posts: 49
Rep Power: 6
Stan Zhou is on a distinguished road
Quote:
Originally Posted by Phicau View Post
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
Stan Zhou is offline   Reply With Quote

Old   February 10, 2021, 13:18
Default Adding a 7th power law profile at inlet
  #282
Member
 
Callum Guy
Join Date: Dec 2019
Location: Scotland
Posts: 44
Rep Power: 6
CallumG is on a distinguished road
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:

Code:
    

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:

Code:
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
CallumG is offline   Reply With Quote

Old   February 14, 2021, 21:29
Default
  #283
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
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
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   February 15, 2021, 07:57
Default
  #284
Member
 
Callum Guy
Join Date: Dec 2019
Location: Scotland
Posts: 44
Rep Power: 6
CallumG is on a distinguished road
Hi Pablo,

thanks very much for your reply!

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

Code:
        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:
Code:
    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
CallumG is offline   Reply With Quote

Old   February 24, 2021, 11:02
Default Implementing Salome mesh alongside OLAFlow Pistonwavetank tutorial
  #285
New Member
 
Robert
Join Date: Feb 2021
Posts: 1
Rep Power: 0
Rob4 is on a distinguished road
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
Rob4 is offline   Reply With Quote

Old   March 1, 2021, 21:57
Default
  #286
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
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
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   March 9, 2021, 08:10
Default A few questions about codes in OlaFlow
  #287
Member
 
Haoran Zhou
Join Date: Nov 2019
Posts: 49
Rep Power: 6
Stan Zhou is on a distinguished road
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
Code:
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?
Code:
1.0/porosity * fvm::div(rhoPhi/porosityF, U)
Code:
- 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
Attached Images
File Type: png 1.png (7.5 KB, 13 views)
File Type: png 2.png (13.5 KB, 12 views)
File Type: png 3.png (13.2 KB, 13 views)

Last edited by Stan Zhou; March 9, 2021 at 10:07.
Stan Zhou is offline   Reply With Quote

Old   March 12, 2021, 05:08
Default
  #288
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
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
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   March 14, 2021, 20:51
Default
  #289
Member
 
Haoran Zhou
Join Date: Nov 2019
Posts: 49
Rep Power: 6
Stan Zhou is on a distinguished road
Quote:
Originally Posted by Phicau View Post
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 !
Stan Zhou is offline   Reply With Quote

Old   March 22, 2021, 13:49
Smile Wave height difference
  #290
New Member
 
Pilar
Join Date: Jan 2021
Posts: 4
Rep Power: 5
Pilardc91 is on a distinguished road
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!
Pilardc91 is offline   Reply With Quote

Old   March 23, 2021, 22:07
Default
  #291
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
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
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   March 24, 2021, 13:12
Default
  #292
New Member
 
Pilar
Join Date: Jan 2021
Posts: 4
Rep Power: 5
Pilardc91 is on a distinguished road
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
Pilardc91 is offline   Reply With Quote

Old   March 25, 2021, 00:55
Default
  #293
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
Hi Pilar,
as simple as increasing the waveheight multiplying by a tuning factor > 1.


Best,
Pablo
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   March 28, 2021, 10:15
Default
  #294
Member
 
Haoran Zhou
Join Date: Nov 2019
Posts: 49
Rep Power: 6
Stan Zhou is on a distinguished road
Quote:
Originally Posted by Stan Zhou View Post
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
Attached Images
File Type: jpg figure 1.jpg (30.1 KB, 14 views)

Last edited by Stan Zhou; March 28, 2021 at 20:30.
Stan Zhou is offline   Reply With Quote

Old   April 6, 2021, 15:31
Default simulating floating object
  #295
New Member
 
Milad
Join Date: Jul 2020
Posts: 4
Rep Power: 5
MIH_ANSYS is on a distinguished road
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
MIH_ANSYS is offline   Reply With Quote

Old   April 6, 2021, 17:30
Default
  #296
New Member
 
Sergio Croquer
Join Date: Jan 2011
Posts: 15
Rep Power: 15
sercro is on a distinguished road
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,
sercro is offline   Reply With Quote

Old   April 7, 2021, 01:57
Default
  #297
New Member
 
Milad
Join Date: Jul 2020
Posts: 4
Rep Power: 5
MIH_ANSYS is on a distinguished road
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
MIH_ANSYS is offline   Reply With Quote

Old   April 7, 2021, 02:45
Default
  #298
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
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
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Old   April 12, 2021, 11:29
Default
  #299
New Member
 
Pilar
Join Date: Jan 2021
Posts: 4
Rep Power: 5
Pilardc91 is on a distinguished road
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.
Pilardc91 is offline   Reply With Quote

Old   April 12, 2021, 20:04
Default
  #300
Senior Member
 
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19
Phicau is on a distinguished road
Hi Pilar,
Any reasonable approach that you can justify is fine.

Best,
Pablo
__________________
Check out my new project: olaFlow --> The olaFlow Support Thread
Phicau is offline   Reply With Quote

Reply

Tags
olaflow, waves

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Divergence detected in AMG solver: k when udf loaded google9002 Fluent UDF and Scheme Programming 3 November 7, 2019 23:34
udf problem jane Fluent UDF and Scheme Programming 37 February 20, 2018 04:17
UDF velocity profile willroca Fluent UDF and Scheme Programming 2 January 10, 2016 03:13
Error messages atg enGrid 7 August 30, 2013 11:16
Phase locked average in run time panara OpenFOAM 2 February 20, 2008 14:37


All times are GMT -4. The time now is 21:12.