[fuba]

Assuming I am interested in the efforts made by water in the flap (inlet) to calculate the required power supplied to the flap to produce a certain type of wave, disregarding the inertia of this flap. What would be the best way to get it?

[arashghgood]

Originally Posted by arashghgood

Dear Pablo
How can I read constant/transportproperties values such as viscosity nu and use it in namespace StokesI in waveFun.C

Thanks for attention.

Dear Pablo
I am still working on reading files like transportProperties in namespace StokesI. I tried many different optioned people recommended in forums. However, I failed. Could you let me know how can I do this?
to be more precise, I want to do some calculations in namespace StokesI in waveFun.C
to do these calculations I need to use nu. I want to read its value from transportProperties.
Thanks in advance

[Matheus Miguel]

Dear Pablo,

I have been trying to position the inlet between the walls of the tank for a while so that there is water on both sides of the flap. Could you give me a hint on how to do this?

[Phicau]

Originally Posted by philiplu

hello, Phicau,
first thx a lot for your olaflow and sharing your olaflow.

a small issue:

in Ubuntu (OFv1906 installed), "offlinewise" I compiled "olaFlow-master.zip" and ran an example-case with full success

in same manner, I compiled "olaFlow_supplementary-master.zip":
in the last of 3 available "allMake"s in it, came a msg.:
sth like '.....enter the isoAdvector path ...'

so i want to ask, how shall I deal with it? did I do sth wrong?

thank you in advance

Hi philiplu,

please make sure what you compile before compiling automatically. It sounds like you are trying to compile the OpenFOAM 5 solver with your OpenFOAMv1906, which of course fails. I have just tested and the v17xx still compiles, although you have all the hints to get your own 1906 version modified to be compiled.

--------------------------------------------------------------

Hello arashghgood,

I have never worked with complex numbers in OpenFOAM, so I cannot be of help. I suggest that you post your programming questions in the Programming sub-forum (same goes for your reading nu question), since they are not directly related with this thread.

A small hint for your second question, try to look for subDict and lookup in the code, you might find some hints to get it working, for example:

" mesh.solutionDict().subDict("PISO").lookup("pRefVa lue")"

--------------------------------------------------------------

Hi M.W.G.,

please provide a minimal working example and I will take a look. Nevertheless, let me say that this postprocessing elements are external to olaFlow.

--------------------------------------------------------------

Hi lincui,

this can happen, numerical instabilities can arise almost out of nowhere with small variations of the initial/boundary conditions. The key here is that you should check your mesh and identify where the instability happens before knowing which action to take.

--------------------------------------------------------------

Hi fuba/Matheus,

try creating a baffle (i.e. infinitely thin wall).

Best,

Pablo

[philiplu]

hi, Phicau,

thank you for the reply
and
it looks like that "ola" does work (at least partially) with v1906


thanks, regards

[arashghgood]

Originally Posted by Phicau

--------------------------------------------------------------

Hello arashghgood,

I have never worked with complex numbers in OpenFOAM, so I cannot be of help. I suggest that you post your programming questions in the Programming sub-forum (same goes for your reading nu question), since they are not directly related with this thread.

A small hint for your second question, try to look for subDict and lookup in the code, you might find some hints to get it working, for example:

" mesh.solutionDict().subDict("PISO").lookup("pRefVa lue")"

--------------------------------------------------------------

Best,

Pablo

Dear Pablo
First of all, thank you for your response.
as you recommended to me, I try to set your hint in waveFun.C. but it doesn't work. could you please let me know more details? for example
1)which #include "????" lines are needed?
2) the following lines does not work

Foam::dimensionedScalar.transportProperties.subDic t("water").lookup("nu");
double sca=Foam::blockMesh.meshDict().lookup("convertToMe ters");
//============================================
I have also another question. when convertToMeters is set to 1 every thing is right. when I set it to 0.1 for example, the box is converted. but the velocity component in StokesI model for example does not change. How can I fix this problem?

[Phicau]

Hi Arash,


again, this question is not related to olaFlow. You should open your own thread in the programming sub-forum so that more people may be able to help you.



convertToMeters is a factor that only has any influence at the mesh creation step. It is there to convert the arbitrary length units you used in blockMeshDict (for your point locations) to meters. Later it is never read again, because you should be already working in SI units (m, s, kg...), therefore, you don't need to multiply any velocities by it, olaFlow will read the relevant dimensions (always in SI units) and calculate the correct velocities automatically for you.


Best,


Pablo

[philiplu]

hello, Phicau,

when people want to know e.g. the wave height at certain time and certain location, if it's possible to let olaflow report it or people have to measure it "manually" from simulation results by means of post-processing?


hope this question won't be a burden in the current season
btw, wish u xmas

[jovenitta]

If ı'm not wrong in breakwater tutorial there is a script for that written in phyton. At the end of the simulation you see the plots .

Originally Posted by philiplu

hello, Phicau,

when people want to know e.g. the wave height at certain time and certain location, if it's possible to let olaflow report it or people have to measure it "manually" from simulation results by means of post-processing?


hope this question won't be a burden in the current season
btw, wish u xmas

[philiplu]

Hello, jovenitta,
thank you indeed for the reply.
I read the py-file: it's great, all clear, thanx.

a further question if u don't mind:
instead of e.g. horizontal bed: as the (horizontal) bed turns e.g. 60 even 90 degrees, then how a reasonable water level (over sloped bed or near a vertical wall) can be estimated?



btw. wish u an excellent 2020

[jovenitta]

Hi philiplu,

Actually it is the same. You place the probes anywhere in the slope or in the vertical sea wall for instance and you get wave surface elevations. You may try some experimental wave runup tests in the literature and compare the results. Btw, I did one and the results agreed quite well..
Wish you a great year too!

[philiplu]

hey, jovenitta,
thank u for reply,
pardon, I didn't describe clearly:
if a probe line is defined at e.g. Point "A" in horizontal bed (till mesh top), then all the cells, the line "touches"(thus their alpha values), refer/belong to "A"
but
if bed is oblique or vertical, the probe line may sample the cells(thus their alpha), referring/belonging bed point(s) for horizontal bed

yes, as u said, the method is the same

I only wonder, how to assign/share the cells(thus the related alpha values), if the probes lines for oblique, vertical bed intersect with the probe lines for the horizontal bed.

hope u enjoy the holiday season

[Phicau]

Hi Philip,


I think I do not get your point. You just need to set your probes in the vertical direction, regardless whether the bed is horizontal or oblique, since the sampling and postprocessing scripts will take care of everything. Also, you don't need to worry if gauges intersect, everything is handled independently.


Best,


Pablo

[philiplu]

hi, Phicau,
merci!

I try to understand the {probe)+{post) as:
A probe-line e.g.(0.5 0.001 0)to(0.5 0.001 1.2) samples all alphas along it, so all sampled α "belong/refer" to pt(0.5 0.001 0)
"post" calculates a wLevel, i.e. a solid water-column elevation referring to pt(0.5 0.001 0)

As horizontal bed turns oblique/vertical and upon vertical wall there's also e.g. water-jet (run-up).
so, still sampling for a horizontal bed wLevel, if a vertical probe-line very near to(not inside) the "jet"(belonging to vertical wall), it could occasionally sample some α (spoondrift generated by "jet"/run-up belong to to the wall).

so my first question, how to deal with the oblique/vertical area
my second question:
without using probe-sampling, wLevel can also be estimated by directly post-process the olaflow's results(alpha.water file), thus I wonder how accurate the real-time(run-time) probe-sampling can be than just directly postprocessing the ola-output-files?


thank you, Phicau as well as jovenitta for your reply

[Phicau]

Hi Philip,


you should think of this in the same way as in laboratory measurements. If you place a probe near the wall it will be influenced by it; the flow will change, that is just how it is. Therefore, most of the times you want to place vertical probes, regardless of anything else.


There are only few instances in which probes may not be vertical. For example, a line gauge to measure runup, placed parallel to the bottom. In any case, the sampling procedure and postprocessing tools to use are the same.


Regarding your second question, if you apply the same methodology, you should get exactly the same results. The advantage of doing it doing runtime is that it allows you to check the results (and identify errors) before the simulation has finished.


Best,


Pablo

[philiplu]

hi, Phicau,

thank you indeed for the clear explanation.
now all is clear and is "Ok-la".


thanx, regards

[arashghgood]

Dear Pablo
I copied the case "oppositeSolitariesFlume" from the tutorial. It works well.
then I tried to change the case so that i) a slope is added in right end of the geometry. ii) only one wave moves from left to right.

the following error appears:

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#4  Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#5  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#6  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#7  ? at ??:?
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9  ? at ??:?
./runCase: line 16:  2701 Floating point exception(core dumped) olaFlow > olaFlow.log

(it does not matter what the mesh size is)

the case is attached.

[Phicau]

Hi Arash,


I am not surprised that the case fails, the mesh is terrible, even if checkMesh reports that it is OK.
Try using snappyHexMesh to make the slope or separating the mesh into 2 blocks and lifting the points on the right (like this _/ ).


Best,


Pablo

[Mariano_]

Hi Pablo and forum,

i try to run de tutorial Breakwater in olaflow (latest version) on openfoam 6 and output a fatal error because does not recognize the type of sample PatchCloud. Anyone knows which is the new sample for openfoam 6?

Other question, is possible using dynamic mesh and VOF in olaflow?



Thanks a lot!


Mariano.

[Phicau]

Hi Mariano,


the new sample type for "patchCloud" is "boundaryPoints". Also note that "midPointAndFace" is now "lineCellFace".


Yes, you can use dynamic mesh refinement, for example I used it in this paper: https://www.sciencedirect.com/scienc...464?via%3Dihub . Setting it up is quite simple, just follow the 3D dambreak tutorial case available in OpenFOAM.


Best,


Pablo