[cfd.with.openfoam]

Hi Christoph,

I just took a quick glance at your issue -

To me it seems that you are not using the right name - you can find the name of the BC in the header file - I think it will be in TypeName - it should look like this - scaledMappedVelocity and not scaledMappedVelocityFixedValueDelta. To be clear I am talking about the U file in the 0 folder.

Regarding the boundary file in the polymesh folder - you need to stick with mappedPatch and try nearestPatchFace for sampleMode.

cheers

[ChrisWe]

Hi,

thanks for taking your time to have a look at my issue. I think that your answer makes sense and could solve this problem. I'll test it on monday and let you know about the result ...

Best regards

[ChrisWe]

PS on Monday:
Your hint was perfect, OpenFOAM detects my BC without any problems. Now there seems to be another problem with a segmentation fault, but I'll try to solve it on my own before describing it here.

Joachim wrote in this topic something about a very small gap in his grid and that he couldn't use blockMesh. I'm using blockMesh and I have a simple grid with equally spacing in the streamwise direction without any "gap" in my grid. Can you remember, if there has been anything special about your grid in your simulation?

Thanks for your help and your patience with me,
Christoph

[cfd.with.openfoam]

Please do not worry about the small gap that Joachim mentioned.

Things should work out well with a simple grid.

[ChrisWe]

In the hope that this is my last question in this thread ...

To test Lunds BC I created a very simple mesh with blockMesh. Its dimensions are from (0 0 0) to (0.28288 0.09 0.0942592) in [m].

I want to simulate a turbulent boundary layer at Re=(U_inf*delta_99)/nu = 3000 and Re_\tau=(u_tau*delta_99)/nu=160.
When using U_inf=1[m/s] and delta_99=0.03[m], I have to set nu=0.00001 (this corresponds to u_tau=0.053).

I'm using a coarse grid with y⁺_1~1 for testing Lunds BC, that is initialized with a disturbed DNS solution (perturbU).

+++++++++++++++++++++++++++++++++ settings in OpenFOAM +++++++++++++++++++++++++++++++++

When using Lunds BC I have to adapt the following files:

• constant/polyMesh/blockMeshDict
• 0/U
• system/controDict

constant/polyMesh/blockMeshDict:

...
boundary
    (
        upper_boundary
        {
        type        wall;
        ...
        }
        plate
        {
        type        wall;
        ...
        }
        inlet
        {
        type         mappedPatch;
        offset          (0.28288 0 0 );        //0.28288 is the distance between inlet and outlet
        sampleRegion    region0;
        sampleMode      nearestPatchFace;
        samplePatch     outlet;
        faces        ((0 3 7 4));
        }
        outlet
        {
        type        patch;
        faces        ((2 1 5 6));
        }
        left_side
        {
        type        cyclic;
        ...
        }    
        right_side
        {
        type        cyclic;
        ...
        }
    );

With this setting, I map the transformed velocity field from the outlet to the inlet. Of course this isn't the best choice for a final run, but for testing the boundary condition it should be ok. Since Lunds BC can only map a flowfield from a boundary of type patch, the outlet must be type patch.

0/U file:

...
dimensions      [0 1 -1 0 0 0 0];
internalField   nonuniform List<vector> 
1572864
(
(0.0685244 0 1.98918e-05)
...
(0.998887 0 1.34832e-08)
)
;

boundaryField
{
    upper_boundary
    {
        type            freestream;
        freestreamValue uniform (1 0 0);
        value           uniform (0.998904 0 0);
    }
    plate
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    inlet
    {
        type            scaledMappedVelocity;
        value           nonuniform List<vector> 
12288
(
(0.0676941 0 0)
...
(0.998886 0 0)
)
;
        deltaInlet      0.03;            //important for calculation
        thetaInlet      0.004;           //will be updated using the solution of lunds BC
        nu              1e-05;           //important for calculation
        Ue              1;               //important for calculation
        t               0.001;           //only important for first iterations, will be updated using the time information during simulation
        UMeanSpanTime   uniform (0 0 0); //only initial value, is calculated in lunds BC
    }
    outlet
    {
        type            zeroGradient;
    }
    left_side
    {
        type            cyclic;
    }
    right_side
    {
        type            cyclic;
    }
}

system/controDict:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
libs ("libScaledMappedVelocityBCDelta.so")
application     icoFoam;
...
averagingTime    0.3;    //for Lund recycling  at the beginning rather short: 10*delta_99/U_inf
            //when flow equilibrates, the averaging interval must be increased!!!
...

+++++++++++++++++++++++++++++++++ final question +++++++++++++++++++++++++++++++++

Using this setting, my DNS (icoFoam) runs without any problems (except a probably correctable floating point error after about 150s), but the simulation results look extremely bad when plotting the nondimensionalized velocity after approximately 150s runtime.

https://www.dropbox.com/s/6mikw72xdx..._plus.pdf?dl=0


There are two possible reasons for this problem:

• My simulation settings aren't good enough. I'm fully aware that the simulated runtime is very short, that my grid is coarse and so on, but I think that the solution should look much better because of my good velocity-field initialization (DNS-solution!).
• I'm using Lunds BC in a wrong way (maybe wrong settings in the blockMeshDict, ...)

Before I'll try some parameter studies with my grid, runtime, timestep, ..., I want to be sure that my settings for Lunds BC are correct.

So my question: Is there anybody, who has already been succesful in using Lunds BC and who can give me a feedback about my settings? Are there any mistakes or weaknesses in my use of Lunds BC?

An additional question arised when I tried to run this case in parallel because OpenFOAM breaks with a segmentation fault error directly at the beginning of the simulation. Do you have any experience in running a Lund BC testcase in parallel?


Maybe I haven't given enough information in the presented code snippets, so you can have a closer look to my testcase in the following files:
https://www.dropbox.com/sh/xlzp3e16o...UsOmR-1La?dl=0

Thanks for your help,
Christoph

[infinity]

Originally Posted by cfd.with.openfoam

Hello Everyone,

If anybody needs Joachim's code then please send me an email at cfd.with.openfoam@gmail.com.

I wanted to upload the code here but I don't have his permission yet. Hopefully he will be OK with me distributing the code via email

Thanks.

Hi
I've just got into this thread and I mailed you guys individually but unfortunately I've not received Joachim's code yet

Would you please send me the code?

[Joachim]

Hey everyone,

sorry I have been a bit busy lately. Here is the boundary condition I implemented a while back (maybe two years ago). It seemed to work at the time (see attached figure).

I also have a zipped test case (Lund's flat plate), but the file is too large to be uploaded here (14mo or so). Any idea how I could share that with you guys?

Best,

Joachim

[ChrisWe]

Hi Joachim,

when I get your permission I can upload it in dropbox...

Christoph

[infinity]

Originally Posted by Joachim

Hey everyone,

sorry I have been a bit busy lately. Here is the boundary condition I implemented a while back (maybe two years ago). It seemed to work at the time (see attached figure).

I also have a zipped test case (Lund's flat plate), but the file is too large to be uploaded here (14mo or so). Any idea how I could share that with you guys?

Best,

Joachim

Thanks so much for taking the time to help me with sharing your code. Best way to upload such file would be Dropbox( https://www.dropbox.com/home ) but the easiest way to do so is http://wikisend.com/

you can also send the file to me (armehrjoo@gmail.com) and i'll take care of sharing it.
thanks again for your help

[Joachim]

I just uploaded the files on Dropbox. Enjoy!

https://www.dropbox.com/sh/ckj3yf5e5...VKGY5UpCa?dl=0

The boundary condition was implemented roughly two years ago using OF 2.2.0. I haven't tried it with the latest releases, but some people did and it seemed to work. Please let us know if it worked for your version, etc!

Best,

Joachim

ps: I think I also have a version where I impose the displacement/momentum thickness instead of the boundary layer thickness. I'll see if I can find it.

[ChrisWe]

When I run Lunds BC with OpenFOAM-2.2.2, my parallel running problem is solved. This is weird, because Lunds BC should also work with OpenFOAM-2.2.0. So maybe I had an installation problem.

Thanks to everybody who helped me with my problems, you have been an awesome help for me

[ChrisWe]

It figured out that I have been pleased too early. When I run Joachims uploaded test case with scaledMappedVelocityFixedValueDelta (averagingTime=100), all seems to work fine. I can't reproduce his amazing results that he presented here, but that's not the problem.

In the next step I wanted to resimulate Joachims test case with my own initial conditions. Therefore I initialized the flowfield with the averaged mean velocity field of a DNS-solution, that is perturbed with perturbU. Apart from the averagingTime, all settings are identical to that one which Joachim used. The mesh is refined a little bit in the wall-normal direction (from 45 to 60 cells) to get y⁺_wall=1 with simplegrading=60 instead of Joachims value of ~150, but this shouldn't be the problem.

The boundary layer parameters are:
deltaInlet = 0.243;
thetaInlet = 0.028;
nu = 2e-05;
Ue = 1;
t = 2;
u_tau_expected ~0.0425

According to Lunds paper, the initial averagingTime was set to T=10*delta_99/Ue~2.5.

For the first 45000 iterations (280s physical time), the simulation looks brilliant. U_tau_inlet converges to the expected value of 0.0425 and the simulation is very stable and equilibrates. Afterwards, u_tau_inlet, u_tau_recycle (image 3) and the CFL-number increase and the simulation breaks. When you have a look at the flowfield, you can see some wickles in the freestream.

To stabilize the simulation, I reran the simulation beginning at 45000 iterations (280s) and increase the averagingTime, according to Lunds paper to T=100*delta_99/Ue~25. When you have a look at the attached plot (image 5), you can see, that my simulation shows exaclty the same behaviour like bevore and breaks. When I tried other Re-numbers, every simulation has shown the same behaviour.

This is very supprising for me, because Joachim never reported about this problems and his uploaded testcase works fine. I know that you really have to be careful with the averaging time, because Lunds BC uses an average with a weight that decreases exponentially backward in time, but I couldn't solve this problem.

Didn't you have the same problems?

Thanks in advance,
Christoph

[syavash]

Originally Posted by ChrisWe

It figured out that I have been pleased too early. When I run Joachims uploaded test case with scaledMappedVelocityFixedValueDelta (averagingTime=100), all seems to work fine. I can't reproduce his amazing results that he presented here, but that's not the problem.

In the next step I wanted to resimulate Joachims test case with my own initial conditions. Therefore I initialized the flowfield with the averaged mean velocity field of a DNS-solution, that is perturbed with perturbU. Apart from the averagingTime, all settings are identical to that one which Joachim used. The mesh is refined a little bit in the wall-normal direction (from 45 to 60 cells) to get y⁺_wall=1 with simplegrading=60 instead of Joachims value of ~150, but this shouldn't be the problem.

The boundary layer parameters are:
deltaInlet = 0.243;
thetaInlet = 0.028;
nu = 2e-05;
Ue = 1;
t = 2;
u_tau_expected ~0.0425

According to Lunds paper, the initial averagingTime was set to T=10*delta_99/Ue~2.5.

For the first 45000 iterations (280s physical time), the simulation looks brilliant. U_tau_inlet converges to the expected value of 0.0425 and the simulation is very stable and equilibrates. Afterwards, u_tau_inlet, u_tau_recycle (image 3) and the CFL-number increase and the simulation breaks. When you have a look at the flowfield, you can see some wickles in the freestream.

To stabilize the simulation, I reran the simulation beginning at 45000 iterations (280s) and increase the averagingTime, according to Lunds paper to T=100*delta_99/Ue~25. When you have a look at the attached plot (image 5), you can see, that my simulation shows exaclty the same behaviour like bevore and breaks. When I tried other Re-numbers, every simulation has shown the same behaviour.

This is very supprising for me, because Joachim never reported about this problems and his uploaded testcase works fine. I know that you really have to be careful with the averaging time, because Lunds BC uses an average with a weight that decreases exponentially backward in time, but I couldn't solve this problem.

Didn't you have the same problems?

Thanks in advance,
Christoph

Dear Christoph,

I have some questions regarding this BC.

I have a channel flow with a humb in middle of it, already with an initial solution (fully turbulent at inlet). I want to use scaledMappedVelocity boundary condition at this stage, i.e. not from time 0.

I looked upon the settings you have provided above, and the settings provided in Joachim test case.

I observe that there is an Interface boundary condition in Joachim test case which is used for recycling purpose.

However In my simulation, there is not such Interface bc defined. So, can I implement this boundary condition to continue my simulation?! or I should return to the grid generation tool and define an Interface bc and then start my simulation from scratch??!

If the latter comes to be true (needing an interface), is there any other option to create it at this stage and not returning to grid generation tool?!

Thanks,
Syavash

[ChrisWe]

Dear syavash,

the scaledMappedVelocity BC is based on the mappedBC to set values from one plane to another.

When you have a look at the mappedBC, you can see, that there are different possibilities to use this BC:

• nearestPatchFace (nearestFace) needs a patch, where it can extract values to set them to another patch. This type is used for the scaledMappedVelocity BC so you really have to use patches to run Lunds BC. The easiest way to get a patch is to use cyclic BCs.

• when you want to simulate a channel flow, you do not need Lunds BC. It is enough to transfer values from one plane to another without rescaling. Therefore you can use all possible options which are given in the mappedBC. The best possibility is to use the nearestCell option for your inlet. To use this option, you have to specify a distance from your inlet to the cells, where you want to extract your values. For this option you do not have to define any patches.

I hope that this answers your question? If not, maybe you have to draw a little sketch to clarify your problem...

Cheers,
Christoph

[syavash]

Originally Posted by ChrisWe

Dear syavash,

the scaledMappedVelocity BC is based on the mappedBC to set values from one plane to another.

When you have a look at the mappedBC, you can see, that there are different possibilities to use this BC:

• nearestPatchFace (nearestFace) needs a patch, where it can extract values to set them to another patch. This type is used for the scaledMappedVelocity BC so you really have to use patches to run Lunds BC. The easiest way to get a patch is to use cyclic BCs.

• when you want to simulate a channel flow, you do not need Lunds BC. It is enough to transfer values from one plane to another without rescaling. Therefore you can use all possible options which are given in the mappedBC. The best possibility is to use the nearestCell option for your inlet. To use this option, you have to specify a distance from your inlet to the cells, where you want to extract your values. For this option you do not have to define any patches.

I hope that this answers your question? If not, maybe you have to draw a little sketch to clarify your problem...

Cheers,
Christoph

Thanks Christoph,

You answered my questions, more or less. Regarding your second statement, I do have a channel flow but not a fully developped one! So, I guess I cannot use mappedBC and nearestCell option (correct me if I am wrong).

You also mentioned "the easiest way to get a patch is to use cyclic BCs". I do not fully understand what you meant to say. May I ask to elaborate further on how to get a patch using this method (I mean by using cyclic BCs)?!

Another point: in your previous post, you mentioned that care must be taken regarding time average interval (T). In Joachim test case it is set to 100 through whole the simulation time, I wonder if this is a convenient value. Lund in his paper has suggested to increase this value when boundary layer reaches equilibrium. How can one assess that it has occured?!
Generally, do you have any recommendation on how to adjust this parameter?

Thanks,
Syavash

[ChrisWe]

Hey syavash,

Do you want to simulate transition in your channel flow? Or why isn't your inflow fully developed? I think that I don't understand your setup at all

When using Lunds BC, you need a patch at the recycling station. But the recycling station is somewhere in the middle of my internal field, so there is no patch. To define a patch at this recycling point, the easiest way is to use cyclic BCs, because they automatically generate patches without influencing the flow.

I think that you can also generate patches with cellSet or topoSet, but they work like boundaries and you have to define values for this patches.


Referring your question about the time averaging parameter T:
Joachims testcase is a well developed simulation. The T3=100 in his simulation is the final step to generate his inlet profile. In this final step, T must be greater than the runTime to get a "normal" time averaging. When I use LundsBC, I set T in the final step to T3=100000 to be save, that this value will never be reached.

As a consequence of the periodicity of your simulation area, it is very hard to get a stable simulation with LundsBC, especially for low Re-numbers. In contrast to a channel flow with periodic boundaries, a flat plate flow hasn't got an upper wall, which suppresses any oscillations by the no slip condition. For this reason, your periodic boundaries create oscillations in the spanwise direction which aren't suppressed by the upper boundary. This oscillations increase during runtime and will destroy your simulation.
This means, that you have to keep your averaging intervals very short to survive the oscillations. For time averaging I used the averaging intervals which are recommended in Lunds paper.

Step 1: Run the simulation with Lunds T1 and plot U_tau_inlet up to the time, at which U_tau_inlet reaches your desired value (maybe a little bit longer) and switch to Step 2.

Step 2: Run the simulation with Lunds T2 for maybe 40-50 cycles (maybe thats not the optimum, but it worked for me). You can check your flow by plotting the turbulent energy spectrum after this time period and switch to Step 3.

Step 3: Run the simulation with T3=infinity (1000000).


Best regards,
Christoph

[syavash]

Originally Posted by ChrisWe

Hey syavash,

Do you want to simulate transition in your channel flow? Or why isn't your inflow fully developed? I think that I don't understand your setup at all

When using Lunds BC, you need a patch at the recycling station. But the recycling station is somewhere in the middle of my internal field, so there is no patch. To define a patch at this recycling point, the easiest way is to use cyclic BCs, because they automatically generate patches without influencing the flow.

I think that you can also generate patches with cellSet or topoSet, but they work like boundaries and you have to define values for this patches.


Referring your question about the time averaging parameter T:
Joachims testcase is a well developed simulation. The T3=100 in his simulation is the final step to generate his inlet profile. In this final step, T must be greater than the runTime to get a "normal" time averaging. When I use LundsBC, I set T in the final step to T3=100000 to be save, that this value will never be reached.

As a consequence of the periodicity of your simulation area, it is very hard to get a stable simulation with LundsBC, especially for low Re-numbers. In contrast to a channel flow with periodic boundaries, a flat plate flow hasn't got an upper wall, which suppresses any oscillations by the no slip condition. For this reason, your periodic boundaries create oscillations in the spanwise direction which aren't suppressed by the upper boundary. This oscillations increase during runtime and will destroy your simulation.
This means, that you have to keep your averaging intervals very short to survive the oscillations. For time averaging I used the averaging intervals which are recommended in Lunds paper.

Step 1: Run the simulation with Lunds T1 and plot U_tau_inlet up to the time, at which U_tau_inlet reaches your desired value (maybe a little bit longer) and switch to Step 2.

Step 2: Run the simulation with Lunds T2 for maybe 40-50 cycles (maybe thats not the optimum, but it worked for me). You can check your flow by plotting the turbulent energy spectrum after this time period and switch to Step 3.

Step 3: Run the simulation with T3=infinity (1000000).


Best regards,
Christoph

Thanks Christoph,

My channel simply is like the configuration in pitzDaily tutorial, except that the upper wall is further away and the incoming flow is not fully developped but is completely turbulent and a turbulent boundary profile should be applied. Of course at this station, the boundary layer thickness and momentum thickness are both given.

About the difference between the flat plate and a developping channel flow, you mean that having a stable simulation is easier in case of channel because of the upper wall, right?!

I have read Lunds paper but now with your explanation, I have been confused about T!! I thought this parameter is simply the time span over which the averaging is applied. But I am not so sure now!
Could you elaborate a little further about this parameter please?

Thanks,
Syavash

[ChrisWe]

Hi Syavash,

thats right, a cyclic channel flow is much more stable than a cyclic flat plate boundary flow, but it's absolutely not impossible to stabilize it!

About the averaging Time T, that is presented in Lunds paper.
Lund writes: "A convenient way to eliminate the starting transients is to use an average with a weight that decreases exponentially backward in time".

The given formula includes the time parameter T.

• In your controlDict (or in the U-file, I'm not sure) you have to define this parameter. For example T=10.
• When you run the simulation and your actual runtime is smaller than T=10, T is replaced by the runTime and you have a simple running average.
• When your runtime is greater than T=10, this value will be used and you have an average with a weight that decreases exponentially backward in time.

Example for T=10:
...
runTime=7 T=7;
runTime=8 T=8;
runTime=9 T=9;
runTime=10 T=10;
runTime=11 T=10;
runTime=12 T=10;
...

Try to understand the effect of a constant parameter T in Lunds formula. I hope that this explanation makes it clear?

Cheers,
Christoph

[syavash]

Originally Posted by ChrisWe

Hi Syavash,

thats right, a cyclic channel flow is much more stable than a cyclic flat plate boundary flow, but it's absolutely not impossible to stabilize it!

About the averaging Time T, that is presented in Lunds paper.
Lund writes: "A convenient way to eliminate the starting transients is to use an average with a weight that decreases exponentially backward in time".

The given formula includes the time parameter T.

• In your controlDict (or in the U-file, I'm not sure) you have to define this parameter. For example T=10.
• When you run the simulation and your actual runtime is smaller than T=10, T is replaced by the runTime and you have a simple running average.
• When your runtime is greater than T=10, this value will be used and you have an average with a weight that decreases exponentially backward in time.

Example for T=10:
...
runTime=7 T=7;
runTime=8 T=8;
runTime=9 T=9;
runTime=10 T=10;
runTime=11 T=10;
runTime=12 T=10;
...

Try to understand the effect of a constant parameter T in Lunds formula. I hope that this explanation makes it clear?

Cheers,
Christoph

Dear Christoph,

Your comments were really helpful. Thanks!
Yet, I should work on it to get into that.

Following our discussion regarding the intermediate patch to use for recycling, I have been struggling to generate a grid with two interfaces, using a third-party software (ICEM CFD), and really that was a pain!

I could simply create a single patch, but I am not sure it would be enough since I have no idea what bc can be applied to this single patch in boundary file. Besides, I can see that Joachim has used two adjacent patches as cyclic boundary conditions in his test case (still wondering how he managed to separate them by a small gap!!)

Now, I have two coincident cyclic patches in my boundary file (yet, checkMesh throws me bunch of warnings for translation vector being zero!). Is it enough for making the simulation work?!
Can I use a single patch instead (because it is much easer for me)?!

Thanks,
Syavash

[ChrisWe]

Hi Syavash,

I am pretty sure that you have to define two surfaces when using cyclic BCs.

Of course it is not enough to define one patch without using cyclic patches. Thats the problem I mentioned when I wrote:

I think that you can also generate patches with cellSet or topoSet, but they work like boundaries and you have to define values for this patches.

If it is not possible for you to create two independent domains with some distance between the cyclic patches (This must be possible!) in ICEM, you can use Joachims blockMeshDict and adapt it to your wishes. Have a look at this file and try to understand, what he is doing there.

Cheers,
Christoph