[mleary29]

Thank you so much! This is extremely helpful, and also I greatly appreciate the warning about the sensitivity to changing the geometry.

Best,

[kclement1993]

hi Pablo,

The thing I am doing now is trying to simulate a box slide down with a slope (5 degree),and to see it sliding into water and to see how the water being reaction, and I am using olaDyMFlow solver basically same as interDymFoam solver And I am trapping with the geometry and mesh problem and without any idea, just keeping try and error for such a long time,and feel a little helpless, so come here for help.


best regards,

James

[Phicau]

Hi kclement1993,

with this modelling method the box is not going to slide. I am not aware of any OpenFOAM extension to model sliding objects (i.e. including contact detection and friction as in DEM models).

The only easy option that I can think of, and which might be successful, is using immersed boundary method and prescribing the movement of your solid. This approach is out of the scope of this thread, though, so I suggest that you open another one in the OpenFOAM Running, Solving & CFD subforum so that other people might have visibility on it.

Best,

Pablo

[kclement1993]

Hi Pablo,

Big thanks for your reply!

I'll gonna post the question to the place you mentioned.

Best regards,

James

[aow]

Hi Pablo,

To begin with, thank you for your awesome work first developing IHFoam and then moving on to olaFoam and now olaFlow. I've been using it for my Ph.D. research and it has proven to be an invaluable resource.

Concerning olaFlow, I just downloaded an updated copy this morning and believe I may have just found a typo in a source file. In particular, I am referring to wavemakerMovement.C, where the environment variable OF_FLAVOUR, which you defined in the allMake scripts, is incorrectly referenced as OFFLAVOUR, which causes an error when you run allMake. The error message states...

could not open file PointPatchFieldMapper.H for source file wavemakerMovement/wavemakerMovement.C due to No such file or directory

..., because in OpenFOAM-5.x, which is the version I'm using, the file has been renamed to pointPatchFieldMapper.H as your if statement tries to account for, but fails due to the typo. I don't know how critical this is for the functionality of any of the BCs and/or solvers, but thought it should be pointed out.

For now, I took a lazy approach and replaced all instances of PointPatchFieldMapper with pointPatchFieldMapper instead, which fixed the error, but a more general fix ought to be made.

I initially tried replacing all instances of OFFLAVOUR with OF_FLAVOUR in both pointPatchFieldMapper.H and pointPatchFieldMapper.C, but this didn't help fix the error. Perhaps the environment variable isn't being read/found correctly in the .H and .C files? I double checked the output of allMake by adding the line "echo $OF_FLAVOUR", which gave an output of 3. This is the correct value for OpenFOAM-5.x and should trigger the use of pointPatchFieldMapper.H instead of PointPatchFieldMapper.H, but something was still going wrong.

[Phicau]

Hi Andrew,

thanks for finding this and reporting it! I don't use 5.x, but will try to find the reason behind the error and try to solve it soon. I will keep you posted.

Best,

Pablo

[Phicau]

Hi Andrew again,

thanks for the report. I have checked and everything works well as expected, let me explain what is going on.

- OF_FLAVOUR is defined in the allMake script.
- OFFLAVOUR is defined and passed as a variable with the value of OF_FLAVOUR to the compiler. This is done in the Make/options file.
- The linker comes into play and tries to gather everything defined with the #include directive. It seems to ignore the preprocessor statement and, of course, complains that it cannot find one of the 2 files, either "PointPatchFieldMapper.H" or "pointPatchFieldMapper.H", depending on the version that you are running.
- The preprocessor takes action and removes the option to load file that is not supposed to exist.
- The compiler does its work...

Best,

Pablo

[aow]

Hey Pablo,

Thanks for getting back to me about this issue, which I guess is not really an issue if I'm understanding what you're saying correctly? I'm confused as to how things work out if pointPatchFieldMapper.H is needed, but cannot be found. Even if the preprocessor takes out the faulty option to load a file with the wrong capitalization, how does the compiled application function correctly if it didn't use a file that it needs? Or are you saying that the file is not needed, but provides some sort of optional or alternative functionality?

Best,

Andrew

[Phicau]

Hi Andrew,

I didn't explain it that well.

Basically the linker tries to load both "PointPatchFieldMapper.H" and "pointPatchFieldMapper.H". It loads one of them successfully (the one that it finds for the given OpenFOAM flavor) and complains about the other one, which cannot be found because it does not exist for the given OpenFOAM flavor. Nevertheless, the one missing will never be used afterwards because...

...the preprocessor #if statement makes sure that the .C file uses the correct "PointPatchFieldMapper.H" or "pointPatchFieldMapper.H", depending on the OpenFOAM flavour that you are using.

Short story: take this message just as a warning, which is the trade-off for getting cross-flavor compatibility of the codes. You are always getting the full version, compiled with the correct files and getting full functionality.

I hope that it is clearer now.

Pablo

[aow]

Thanks for the explanation Pablo!

Everything is very clear now and makes total sense. I didn't dig deep enough to see where OFFLAVOUR gets defined and how both files are loaded so I'm sorry to have wasted your time.

Thanks again for your time!

Andrew

[AnnaF]

Hello Pablo,

I just want to tell you that in the tutorial "waveFlume_isoAdvector" the line for the keyword

nAlphaCorr

is missing in "waveFlume_isoAdvector/system/fvSolution.solvers.alpha.*".

Kind regards
Anna

[jinheng]

Hi Pablo,

Thanks for your attribution!

I saw the application of marine new energy on your website.

I would like to consult that if I want to simulate a floating breakwater with two coupling body, how can I use your olaDyMFoam to set up two floating body both with anchor chain or elastic constraint? Whether the floating body must be 3D one due to mass requriement in relative files.

Thanks your and waiting for your reply.

Best regards,

Heng

[AnnaF]

Hello Pablo, hello all!

Not sure if this is the corret thread for my problems, but maybe someone has encountered similar issues:

I try to use runtime sampling (#includeFunc sampleDictVOF) to sample the isosurface for wave gauges with olaFlow (with OF 5.x; just updatet to 20180108) in parallel on a HPC cluster for a simple 2D wave flume.
The exaclty same setting works on my workstation without problems (also in parallel; same OF version). But on the cluster everything stops just before olaFlow starts iterating, there are no error messages produced:

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

I am trying to workout the problem with the HPC support team, but we have not found the problem yet. Maybe someone has an idea or point as towards some potential reasons?
Please find the case attached.

Many thanks
Anna

[Phicau]

Hi Anna,

thanks for noting, apparently there has been some changes recently and it's been quite some time since I do not upload that part. I will try to check it out soon.

Regarding the problem n the cluster, I have no idea what could be happening, every cluster is a different world. Maybe the solver does not find sampleDictVOF for any reason? Does the case work without the #includeFunc?

Perhaps you can try to include everything in the file within functions{} and the macro outside?

    gaugesVOF
    {
        type    sets;
        functionObjectLibs
        (
            "libsampling.so"
        );
        writeControl   timeStep;
        writeInterval  1;
        setFormat       raw;
        surfaceFormat   raw;
        interpolationScheme cell;
        fields          ( alpha.water );
        sets
        (
            GaugeVOF1
            {
                type    midPointAndFace;
                axis    xyz;
                start   ( $xWP1 $ly 0 );
                end     ( $xWP1 $ly $lz );
            }
            GaugeVOF02
            {
                type    midPointAndFace;
                axis    xyz;
                start   ( $xWP2 $ly 0 );
                end     ( $xWP2 $ly $lz );
            } 
        );
    }

Maybe try to fill in the values instead of using the macro?


Hi Heng,

thanks! This can certainly be done, check it out: https://www.youtube.com/watch?v=fE9sf_E9RGU

In that simulation I used 3 independent bodies following this example: Multiple Floating Objects with 6DoF in OF 2.3.0

Since then multiple bodies are supported by the DEV distribution and you can also check the overset procedure in the + distribution.

Best,

Pablo

[AnnaF]

Hi Pablo

Thank you very much for this hint!

It does work now with directly including the code in functions{} - and the macros outside - in the controlDict.

Great! Many thanks.

Anna

[Phicau]

Dear all,

We have released the Extended Range Active Wave Absorption (ER-AWA) in olaFlow. It is included in the new Dev branch.

This feature extends the applicability of AWA to intermediate and deep waters, which is perfect for offshore wave simulations.

To learn more visit the release post: https://olaflow.github.io/blog/new-b...ed-to-olaflow/

Best,

Pablo

[AnnaF]

Hi Pablo

Thanks for your work and releasing the ER-AWA!

I just tried to install it with

git checkout
git pull
git checkout Dev
./allMake

but it fails and I get an error message when compiling the waveAbsorption libraries - I have attached the message.

Have I missed anything?

Many thanks
Anna

[Phicau]

Hi Anna,

thanks for the report! I have just fixed the issue and committed the solution. Please go ahead and download the new version.

Compilation worked with versions 5, 6, dev... but the .x versions are always tricky, as they may change with time.

This was a weird thing: apparently some of the updates have broken the way to instantiate a labelList as (#elements, value). Nevertheless, I have found a way around which (still) works in all cases.

Best,

Pablo

[AnnaF]

Hi Pablo,


the compilation worked out now. However, I am afraid there is still a problem linked to the previous one. When I try running the "baseWaveFlumeNewAbs" tutorial I get the following error message:

--> FOAM FATAL ERROR: 
bad size -1

    From function Foam::List<T>::List(Foam::label) [with T = long int; Foam::label = long int]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-5.x/src/OpenFOAM/lnInclude/List.C at line 45.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::activeWaveAbsorptionModel::activeWaveAbsorptionModel(Foam::fvMesh const&, Foam::polyPatch const&, Foam::dictionary const&) at ??:?
#3  Foam::activeWaveAbsorptionModels::extendedRangeAWA::extendedRangeAWA(Foam::fvMesh const&, Foam::polyPatch const&, Foam::dictionary const&) at ??:?
#4  Foam::activeWaveAbsorptionModel::addpatchConstructorToTable<Foam::activeWaveAbsorptionModels::extendedRangeAWA>::New(Foam::fvMesh const&, Foam::polyPatch const&, Foam::dictionary const&) at ??:?
#5  Foam::activeWaveAbsorptionModel::New(Foam::fvMesh const&, Foam::polyPatch const&, Foam::dictionary const&) at ??:?
#6  Foam::activeWaveAbsorptionModel::lookupOrCreate(Foam::polyPatch const&, Foam::fvMesh const&, Foam::dictionary const&) at ??:?
#7  Foam::waveAbsorptionVelocityFvPatchVectorField::updateCoeffs() at ??:?
#8  Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() in "/home/ubuntu/OpenFOAM/ubuntu-5.x/platforms/linux64GccDPInt64Opt/bin/olaFlow"
#9  ? in "/home/ubuntu/OpenFOAM/ubuntu-5.x/platforms/linux64GccDPInt64Opt/bin/olaFlow"
#10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11  ? in "/home/ubuntu/OpenFOAM/ubuntu-5.x/platforms/linux64GccDPInt64Opt/bin/olaFlow"
./runCase: line 16:  4658 Aborted                 (core dumped) olaFlow > olaFlow.log

I assume this is linked to OF 5.x again?!


Kind regards
Anna

[Phicau]

Nope, my bad. I have just fixed it and it works, sorry for that.
Please go ahead and download the new version.