[rupak504]

Originally Posted by Phicau

Hi rupak504,
Yes, Adaptive Mesh Refinement should work.
Best,
Pablo

Yes, it works fine. It was a silly mistake.


Thank you

[Tarekhadj]

Hi Pablo,


Thanks for your excellent work.
Thanks for sharing your knowledge with the CFD community.


I am a master student in coastal and marine engineering and I am very keen on olaFlaw.


When I read your phd thesis, there was some question.

1. In section 8.1.3 page 285, (the random waves have been obtained based on an iterative process) what's mean the iterative process? Hs = 4.5m is in the front of the structure (after propagation) or in the boundary condition of the IHFoam model, or in the middel of the wave flume (between the structure and the wavemaker and you used the seperation wave method to seperate the incident wave from the reflected wave then you compared the incident wave with the theoretical ones)
2. In page 306 (it is propagated with the IHBouss)Are there other alternative of IHBouss that calculate the time series and velocity.

Best regards.
Tarek

[goodstah]

Originally Posted by Phicau

If waves are close to shallow water conditions you can use the static wavemaker module, in which you feed a time series of free surface elevation directly, see the reference manual for a full description.

Thanks Pablo--much appreciated. Yeah, our sites of interest are quite close to shore in ~6m of water so I've been experimenting with the "tveta" wave maker, format as shown in pg 51 of the manual. I think I must have the syntax or format still incorrect tho, or missing something, b/c I receive the error below on the first iteration:

PIMPLE: iteration 1
Point displacement BC on patch inlet
Initial water depth Paddle_inlet = 6.95758
[0] 
[0] 
[0] --> FOAM FATAL IO ERROR: (openfoam-2112)
[0] incorrect first token, expected <int> or '(', found on line 3019: double 0.6787
[0] 
[0] 
[0] file: [1] 
[1] 
[1] --> FOAM FATAL IO ERROR: (openfoam-2112)
[1] incorrect first token, expected <int> or '(', found on line 0: double 0.6787
[1] 
[1] 
[1] file: [2] 
[2] 
[2] --> FOAM FATAL IO ERROR: (openfoam-2112)
[2] incorrect first token, expected <int> or '(', found on line 0: double 0.6787
[2] 
[2] 
[2] file: stream.paddleEta at line 0.

Was wondering if maybe you could take a quick peek at my wavemakerMovementDict file if not too much trouble... Feel like might be close to getting it working.

Mahalo nui
Chris

[goodstah]

I think I must have the syntax or format still incorrect tho, or missing something, b/c I receive the error below on the first iteration

Well, I definitely had something wrong, haha. Wasn't the time series format, it was the dynamic mesh--I didn't realize that in contrast to the flap/piston wave makers cases that use the dynamic mesh, this version of wave maker uses the static mesh with no moving parts. Made that adjustment and it works.

Unfortunately, the results look nothing like what I expected. The input WSE amplitude range is on the order of +/- 1.5 m in 6.5 m depth, with velocities +/- 2-3 m/s, and within the first 10 s of the simulation, the water appears to just drain down to -6m at the inlet patch and never recovers, with no wave propagation. Hmmm. Does this effect sound familiar to anyone? A working tveta wavemaker tutorial case would be extremely useful if anyone has a simple one they could share.. I've attached my working case here, just to show the waveDict setup and the v and eta time series if anyone's interested.
Mahalo

Update: So interesting development - experimenting with different v and eta timeseries, even setting them all to zero, produces the same result. Which is water draining out through the inlet wave maker and no wave generation. This suggests that the tveta wavemaker (as I have it set up) is either not reading the data, or that it is simply not passed to the appropriate place. But since there are no errors generated at runtime, and it does complain if I format the time series incorrectly, it leads me to believe that it is reading the file, I'm just not getting it to the right place in the code. A little bit baffling. I must be missing something here...

Update Update:

...water draining out through the inlet wave maker and no wave generation.

sooooooooo, one must pay careful attention to the direction of the wave absorption boundary, as well as ensure to choose appropriate vertical cell sizing..! Works great once its set up correctly! What an awesome feature this tveta option is.

[openfoamdjxych]

Hello, I have a problem about overOlaDyMFlow now, could you please answer it for me？I have changed a case of overinterdydmfoam solver,but when I start to run it using overOlaDyMFlow solver,it did not work,and the terminal's information is that:
--> FOAM FATAL IO ERROR: (openfoam-2106)
Cannot have both dictionary entry 'oversetInterpolationSuppresed' and 'oversetInterpolationRequired' for field cellMask

file: /run/media/kemove/246ce341-170f-3c47-9bdc-a094e4bc81e5/olawavestokes2/ov/background/system/fvSchemes at line 19.

From void Foam:versetFvPatchField<Type>::initEvaluate(Foam ::UPstream::commsTypes) [with Type = double]
in file oversetPolyPatch/oversetFvPatchField.C at line 138.

FOAM exiting

[Phicau]

Hi Tarek,
Since phases are random, iteratively means that the random phases are generated until the resulting sea state fulfills the quality control criteria and is close enough to what we were trying to obtain. All parameter are defined at the wave generation boundary.
Any other model will do.

Hi Chris,
sorry for the late reply, too much work going on here. Glad to find out that you managed to solve the issue and you appreciate the static wavemaker BC! In later version it will be called timeSeries or something similar to avoid the confusion with the moving wavemaker.
A quick note: generally setting the angle to anything above 360 will make olaFlow to calculate the correct perpendicular angle for you. This is the easiest and safest way, so if you try it and for any reason it does not work for any particular case just let me know.

Hi ych,
It does not seem related to olaFlow, since OpenFOAM is complaining of two conflicting options. Anyway: How to give enough info to get help

Best,
Pablo

[openfoamdjxych]

Originally Posted by Phicau

Hi Tarek,
Since phases are random, iteratively means that the random phases are generated until the resulting sea state fulfills the quality control criteria and is close enough to what we were trying to obtain. All parameter are defined at the wave generation boundary.
Any other model will do.

Hi Chris,
sorry for the late reply, too much work going on here. Glad to find out that you managed to solve the issue and you appreciate the static wavemaker BC! In later version it will be called timeSeries or something similar to avoid the confusion with the moving wavemaker.
A quick note: generally setting the angle to anything above 360 will make olaFlow to calculate the correct perpendicular angle for you. This is the easiest and safest way, so if you try it and for any reason it does not work for any particular case just let me know.

Hi ych,
It does not seem related to olaFlow, since OpenFOAM is complaining of two conflicting options. Anyway: How to give enough info to get help

Best,
Pablo

Thanks for your answer,I have solved my problem,I find I have oversetInterpolation and oversetInterpolationSuppressed in my fvSchemes,when I deleted behind one,I find it could work successfually.But I have a new question now,when I use overOlaDyMFlow,I find I get Max(alpha.water)=1.00016 and sometimes it can reach 1.01,and when I use KOmegaSSTBounyancy,it will be 1.04 everytime,but when I use overInterDyMFoam,it can maintain a low level, for example 1.0000001,I wanna solve it,can you give me some tips, thanks again deeply.

[Phicau]

Hi ych,
I have never experienced such a thing except when I had set the BCs wrong. Please double check that all the BCs for all fields are right. If this does not fix it, it may as well be an issue with the overset method which, as far as I know (and if it has not been fixed yet), does not conserve mass; nevertheless, you should be able to play with the Courant number or with the numerical schemes to improve conservation.

Best,
Pablo

[openfoamdjxych]

Originally Posted by Phicau

Hi ych,
I have never experienced such a thing except when I had set the BCs wrong. Please double check that all the BCs for all fields are right. If this does not fix it, it may as well be an issue with the overset method which, as far as I know (and if it has not been fixed yet), does not conserve mass; nevertheless, you should be able to play with the Courant number or with the numerical schemes to improve conservation.

Best,
Pablo

hi Pablo,
At first,thanks for your reply,and now I get an another question about setOla,I can use it successfully in olaflow and oladymflow,but when I use it in overOlaDyMFlow,it can't work,I find the log.setOla and I just find that Time=9,and nothing in it,so I want to know whether setOla can work in overOlaDyMFlow and oversetmesh,and my moving subject all is under the watersurface,I wonder if this will affect setOla's work.
Looking forward to your reply,
thanks again.

[Yuqian-zj]

Hi Pablo,
I have done some great work with olaFlow and olaFlow is great.
Now i am comfused that the gravity has to act in the negative direction of Z aixs?
if I changed the direction of g to （0 -9.81 0）,will olaflow still work correctly?

[Phicau]

Hi ych,
I have never used setOla with an overset mesh, so unfortunately I cannot offer any insights.

Hi Yuqian,
Gravity needs to act in the negative Z axis in order for olaFlow to work. If you change it to the negative Y direction, wave generation and absorption will not work. What you can do is use OpenFOAM's transformPoints utility to rotate your geometry, so that gravity points in the correct direction.

Best,
Pablo

[Yuqian-zj]

Originally Posted by Phicau

Hi ych,
I have never used setOla with an overset mesh, so unfortunately I cannot offer any insights.

Hi Yuqian,
Gravity needs to act in the negative Z axis in order for olaFlow to work. If you change it to the negative Y direction, wave generation and absorption will not work. What you can do is use OpenFOAM's transformPoints utility to rotate your geometry, so that gravity points in the correct direction.

Best,
Pablo

Thanks very much Pablo! It really helps me. I succeed to transform the mesh of "xy" axis to "xz" axis without dealing with any information about origin mesh by this command "rotateMesh -noZero "(0 1 0)" "(0 0 1)" ".

Now I have annother question.It seems that the Dev branch of olaFlow is not compatible with OF9 as I use "./allMake" following with some function‘s errors.Which version is Dev branch compatible with ? or I meet some unexpected mistakes?

[Phicau]

Hi Yuqian,
The Dev branch was added for OF7 / OF+20xx
Full forward compatibility will happen when I release the new version of the code, for which I still have no fixed date.

Best,
Pablo

[jenjo7873]

Deleted message due to accidental double post. See post #415

[jenjo7873]

Hi all - Back into OlaFlow after a few years out. I'm running OlaFlow on Ubuntu 22.04 with OpenFoam 9

All OpenFOAM tutorials works. Most OlaFlow tutorials work expect those that use a dynamic mesh. I am trying to run the tutorial wavemakerTank with runParallelCasePiston.

Here are lines 18-21 of dynamicMeshDict
18 dynamicFvMesh dynamicMotionSolverFvMesh;
19 motionSolverLibs ("libfvMotionSolvers.so");
20
21 solver displacementLaplacian;

Here is the error from olaFlow.log:
Create time

Create mesh for time = 0

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] keyword motionSolver is undefined in dictionary "/home/len/OpenFOAM/len-9/run/wavemakerTank/constant/dynamicMeshDict"
[0]
[0] file: /home/len/OpenFOAM/len-9/run/wavemakerTank/constant/dynamicMeshDict from line 18 to line [1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] keyword motionSolver is undefined in dictionary "IOstream"
[1]
[1] file: IOstream from line 0 to line 0.
[1]
[1] From function T Foam::dictionary::lookup(const Foam::word&, bool, bool) const [with T = Foam::word]
[1] in file /home/ubuntu/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 43.
[1]
FOAM parallel run exiting

Does anyone have any experience with this error? It looks like a path to a library is incorrect, or maybe i need to call some additional libraries in controlDict? Please let me know.

thanks,

-Justin

[jenjo7873]

Just for fun, here's a link to a model run and a video we did a few years ago. Using OlaFlow with dynamic piston. The model was low resolution but we plan on making some higher resolution runs soon.


enjoy!


https://www.instagram.com/p/CS0u6a9H1V3/



more info about the project on www.firstpeak.org

[jenjo7873]

Regarding Post #415

Figured it out. Changed dynamicMeshDict Line 21 from "solver" to "motionSolver"


It's been a while.

[jenjo7873]

Hello fellow OlaFlow'ers


I need some help reducing the storage requirements for OlaFlow runs.


I only need alpha.water and U for my analysis. Therefore I would like to reduce my cases. It is easy to recursively delete p, p_rgh for example, and other unused variables AFTER the model run using bash script.


However, I would like to prevent these variables from being written. I've recompiled the olaFlow code by changing various IOobject calls to "NO_WRITE". For example, in createFields.H LINE 14 I've changed IOobject::NO_WRITE for p_rgh, therefore p_rgh will not write to disk, greatly saving storage space.


I've done this for as many variables as I could find in various .C and .H files, but I cannot find the write functions in the source code for the following variables (using OlaDyMFlow):


alphaPhi0.water
alpha.water.org
cellDisplacement
meshPhi
phi
pointDisplacement
Uf



Can anyone help me find where these variables are written in the source code?

[Phicau]

Hi Justin,
I wouldn't necessarily recommend stopping the program from outputting the fields, because if the simulation blows up you cannot restart it and you would need to run the whole simulation again from the beginning with different parameters.

Here are a couple of strategies that can help you:

- Compress the fields or use binary format. You can set these flags in controlDict (writeFormat binary; compression on; ).
- Reduce the number of time steps saved by increasing writeInterval. You can still sample the variables of interest at particular locations at a high frequency (basically all time steps).
- Write a small bash/python script to erase the fields that you don't want. I would program it in a way to just delete files from the penultimate time folder, every time it detects that a new one has been created.

There is another option, which may not be helpful for you directly:

- Use purgeWrite to select the number of latest time step snapshots that you want to keep. Older ones will be erased during the simulation.

You could couple this one with a runtime function to store the fields of interest in vtk files (sounds feasible, but don't really know if this is available).

Best,
Pablo

[pcwang]

Hello Pablo,

I've tried to run the tutorial case 'baseWaveFlumeNewAbs' from 'Dev' branch. I've not change anything of this tutorial case, and only run the './runCase' script.

When this script execute the line 'olaFlow > olaFlow.log', the terminal outputs some errors, and olaFlow couldn't work well:

Preparing 0 folder...
Setting the fields...
Running...
munmap_chunk(): invalid pointer
./runCase: line 16: 37408 Aborted                 (core dumped) olaFlow > olaFlow.log
Simulation complete.

Then I ran the 'olaFlow' independently in the terminal.

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v2012                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : _7bdb509494-20201222 OPENFOAM=2012 patch=210414
Arch   : "LSB;label=32;scalar=64"
Exec   : olaFlow
Date   : Jul 02 2022
Time   : 11:57:48
Host   : hpws13
PID    : 37453
I/O    : uncollated
Case   : /home/wpc/wpcdata/olaFlowTutorials/baseWaveFlumeNewAbs
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

--> FOAM Warning : 
    From static Foam::IOstreamOption::compressionType Foam::IOstreamOption::compressionEnum(const Foam::word&, Foam::IOstreamOption::compressionType)
    in file db/IOstreams/IOstreams/IOstreamOption.C at line 115
    Unknown compression specifier 'uncompressed', using compression off
Create mesh for time = 0

Selecting dynamicFvMesh staticFvMesh

PIMPLE: Operating solver in PISO mode

Reading field porosityIndex

Porosity NOT activated

Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes

Reading g

Reading hRef
Calculating field g.h

No MRF models present

No finite volume options present
DICPCG:  Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Courant Number mean: 0 max: 0

Starting time loop

Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
deltaT = 0.00119048
Time = 0.00119048

PIMPLE: iteration 1
MULES: Solving for alpha.water
alpha.water BC on patch inlet

Wave Generation BC
Wave theory: cnoidal
H: 0.1
T: 3
h: 0.4
L: 6.0043
m parameter: 0.9771
Direction: 0?


Phase-1 volume fraction = 0.571429  Min(alpha.water) = 0  Max(alpha.water) = 1
alpha.water BC on patch inlet
MULES: Solving for alpha.water
alpha.water BC on patch inlet
Phase-1 volume fraction = 0.571429  Min(alpha.water) = 0  Max(alpha.water) = 1
DICPCG:  Solving for p_rgh, Initial residual = 1, Final residual = 0.00153011, No Iterations 1
time step continuity errors : sum local = 0.001208, global = -1.49667e-10, cumulative = -1.49667e-10
DICPCG:  Solving for p_rgh, Initial residual = 0.000715141, Final residual = 2.98713e-05, No Iterations 16
Velocity BC on patch inlet

Wave Generation BC
Wave theory: cnoidal
H: 0.1
T: 3
h: 0.4
L: 6.0043
m parameter: 0.9771
Direction: 0?


Active wave absorption BC on patch outlet
"Initial water depths for absorption" 1( 0.4 )

Selecting active wave absorption model extendedRangeAWA
AWA model: patch outlet
    Theory: extendedRangeAWA
    Number of paddles: 1
    Reference water depth: 1(0.4)
    Wave period: 3
Updating extendedRangeAWA absorption model for patch outlet
munmap_chunk(): invalid pointer
Aborted (core dumped)

My OpenFOAM version is v2012, my system version is Ubuntu 20.04, my gcc version is 9.4.0. It is puzzling that when I ran this tutorial in my VMware virtual machine, everything went very well. In my virtual machine, the OpenFOAM version is also v2012, but the system version is Ubuntu 18.04 (gcc version is 7.5.0).

Then I tested the tutorial 'baseWaveFlume' which was not using the extendedRangeAWA model in Ubuntu 20.04 system(OpenFOAM-v2012). And olaFlow worked very well. So I think there are no errors when I compiled the olaFlow codes.

On July 1st, I tried the tutorial case 'baseWaveFlumeNewAbs' in other work station whose system version is CentOS 7.9.2009 (gcc version is 7.3.1) and OpenFOAM version is also v2012, and this tutorial runs very well. So I think there must be some difference between these work stations.

This error confused me a few days. Is this something to do with the system version that I am using to run ?

Hope for your answer.

Thanks,

Peicen

P.S. Sorry for posting my question in your old thread(The OLAFOAM Thread). Please ignore it. :)