[SadBoySquad]

Greetings to all people in this forum!
My wishes for a happy new year!

For the past few days, I have been facing a problem that is briefly summarized as follows:

• I want to run a simulation with an atmospheric boundary layer inlet
• I am aware of the atmBoundaryLayerInletVelocity for U, it works fine
• Same for the atmBoundaryLayerInletK and Epsilon (even though I find it weird that openfoam.org does not have that atmBoundaryLayerInletOmega option whereas the openfoam.com version does have it)
• All the aforementioned types work very well in cases where the patch has a uniform z0 (which is the ground level where the profiles start with 0 velocity)
• However, my inlet plane does not start from a uniform z0, it has varying elevation
• openFoam calculates the global minimum Z of the patch and sets that as z0
• Therefore, since my inlet patch has varying elevation, many profiles do not start from 0 velocity, but rather from a finite value
• This leads to higher velocities near the ground on many regions

What I want to do:

• I want to, someway/somehow, specify a prescribed space dependent field on the inlet
• I am aware of time-dependent inlets, but this is not what I want to do
• what i want to do is calculate the velocity profiles externally and set the profiles in openfoam
• I neither want nor need to specify space dependent equations, the inlet field has already been calculated via a different solver

What I have access to:

• I have the correct inlet profiles on the same mesh from a simulation with a different, in-house solver
• I have the mesh set-up in openFoam (I have run a couple simulations with the default atmosphericBoundaryLayer types)

How can I tackle this?
Can I use ParaView to resample the solution I have over to the openfoam mesh, in order to define the inlet somehow?
I note here that I am not interested in prescribing the internalField, I know there are options to do that.

What I want to do is prescribe only the inlet velocities and turbulence.


Thanks in advance.

[Tobi]

Hi SadBoySquad,

its my first post here for a while now and as you are did a good and comprehensive analysis of your problems, here are the ideas which came into my mind.

• I checked the atmBoundaryLayer files and the good news are that z0_ is a PatchFunction1 which means you can use Function1 entries here. Interestingly enough is the coded Function1 possibility in which you might set z0 related to e.g., the x-coordinate of your face. I guess its the simplest and most-straight forward solution
• Another possibility would be to use the timeVaryingMapped boundary condition in which you specify e.g., x-y-U data (or x-y-k data) in a file which is used for interpolating to the inlet patch faces. The data could be retrieved by using ParaView from your in-house solver analysis and corrected to the foam format manually or with some small script

So I guess setting z0 with a correct functionality will allow you to mimic your non-flat inlet patch. Without testing it, it should be possible. Alternatively, you could hard-code something into the boundary condition and re-compile it.

Hope that my reply will support you and will give you an idea how to resolve your problem.

[SadBoySquad]

Hello Tobi!
Thanks for replying to my question.

I went through your reply and I'm afraid my original post used the term z0 incorrectly.

Here is the relevant atmBoundaryLayer manual that I am referring to:

https://www.openfoam.com/documentati...daryLayer.html

Based on what is presented there, z0 is the roughness height.
However, erroneously, in my original post I used the term z0 to refer to the local ground level.

In the above link, in the equations for u, k, epsilon, and omega, the local z coordinate of each patch face is used (noted with z).

Towards the bottom of the manual page, in the Notes on Entries section,
the following is stated:

• z is the ground-normal height relative to the global minimum height of the inlet patch; therefore, the minimum of z is always zero irrespective of the absolute z-coordinate of the computational patch.

Therefore, a minimum z is calculated for the whole patch and z on all formulas has that minimum z subtracted in order to start from 0.

This is what I want to, somehow, remedy.
There is not a relevant entry that is used to modify this in particular.
Thus, I though I could prescribe the whole inlet as is, if possible.

[SadBoySquad]

I was able to find a way to do it.
I'm not sure it is the only way, but it works and it's somewhat efficient (I think).

I'm leaving the solution here for future reference.
The process I followed is explained in the following video:
https://www.youtube.com/watch?v=K-nAF3qAPTc

Essentially, you set the inlet in 0/U as:

inlet
{
      type fixedValue;
      value nonuniform List<vector>
      #numberOfInletFaces#
      (
      ( u1 v1 w1 )
      ( u2 v2 w2 )
      ...                  // repeated for all inlet faces

      ( un vn wn ) 
      )
      ;
}

The additional nice thing is that you can use ParaView to interpolate the values from a different solution to the new openFoam mesh.
If you export the interpolated inlet data directly from Paraview, the produced list will be correctly mapped to the inlet faces.
So, you essentially just parse the list in the corresponding boundary file.

[Tobi]

Got it. Would you like to test a patch I might create for you? Please be aware that the ordering might kill your inlet profile and you have to take care of the right ordering. Hence, the timeVaryingMapped Boundary condition would make more sense to me.

[SadBoySquad]

Originally Posted by Tobi

Would you like to test a patch I might create for you?

Sure, though I don't understand what you mean exactly.
What would you like me to test?

Originally Posted by Tobi

Please be aware that the ordering might kill your inlet profile and you have to take care of the right ordering.

I know.
I was indeed skeptical about the whole "resampling" process at first, since I thought the ordering in Paraview would be different than the one used by openFoam boundaries.
However, Paraview seems to utilize the ordering of the openFoam mesh.

For example, let's assume that my inlet patch has 100 faces.
The relevant constant/polyMesh/boundary entry will state nFaces 100 for the inlet patch.

If interpolate a solution to the inlet patch using Paraview and then export the solution, the list ordering will be correct and the velocities on the list will correspond to the correct boundary faces.
I know this because I interpolated and ran a case and the inflow velocity is correct!

[SadBoySquad]

Originally Posted by Tobi

Got it. Would you like to test a patch I might create for you?.

Sure thing, even though I don't quite understand what you mean.
What exactly do you want me to test?

Originally Posted by Tobi

Please be aware that the ordering might kill your inlet profile and you have to take care of the right ordering.

I know.
I was also skeptical about the whole "resampling" process at first.
I thought that perhaps Paraview would renumber the faces, or maybe that the inlet faces in Paraview would not correspond to openFoam faces when I resample and export a solution.

Turns out I was happily proven wrong!
Paraview uses the same indexing!

Let's assume that my inlet patch has 100 faces (which can be checked via the relevant entry in the constant/polyMesh/boundary file).
If I open the case in Paraview, the inlet patch will, of course, have 100 2D cells (which are the inlet faces).

I then interpolate/resample on this inlet patch from a different mesh (which in my case is a solution from a different solver on a same mesh).
Finally, I export the inlet Velocity field (or any other variable I want), making sure that I have Cell Values and not Point Values.
This is crucial, I think the resampling process interpolates to Point Arrays, though I might be wrong.
In any case, one can use Point Data to Cell Data to convert the variables.

Assuming I export to tsv/csv, the resulting will contain 100 vector entries for the velocity vector.
The indexing of these entries directly corresponds to the inlet faces of the openFoam mesh.
Thus, the first entry corresponds to the first boundary face, etc etc.
No need to remap anything (phew!).

[Tobi]

Just try your approach and get back to us if it works.

The intention I mentioned was that I update the boundary condition to add the possibility for changing the z value accordingly (not a single value anymore).

[SadBoySquad]

The approach works fine.
I just prescribe the inlet velocity vector as a nonuniform List.

[Tobi]

Sure. Its obvious that it works but you cannot renumber your mesh or change anything in the mesh. Your workflow requires always to adopt the nonuniformList which is a bit tricky an not straight forward

[SadBoySquad]

Sure, I agree that the solution is not straightforward and requires work outside of openFoam.
However, given the fact that in order to run the simulation one already needs to have the openFoam mesh ready, the whole approach is not difficult to grasp.

Originally Posted by Tobi

Sure. Its obvious that it works but you cannot renumber your mesh or change anything in the mesh. Your workflow requires always to adopt the nonuniformList which is a bit tricky an not straight forward

This is correct, my approach has to adhere to the underlying mesh.
If I remesh and the inlet changes, I will have to re-resample the data to the new mesh.
However, this would always be true for a randomly generated field.

My case is a little bit unique, I guess, since it is derived from the atmBoundaryLayer conditions and can be expressed via formulas.
Thus, the boundary conditions for atmospheric BL could be modified to calculate the local ground level.

For a truly random inlet field, or for an inlet field that is not described by some sort of equations available in openFoam, using the nonuniform List I think would be the only way to prescribe the inlet field (apart from delving into changing the BCs and recompiling openFoam).

[Tobi]

Could you please provide me your case, or at least the part of the inlet ?
I would like to extend the condition to work with non-uniform inlets.

Thanks in advance,
Tobi

[SadBoySquad]

Hello Tobi.

Of course, I'd be glad to.
What would you want me to provide?
Unfortunately, I cannot share the whole mesh because it concerns confidential information.

I could provide the inlet, though.
How would I go about preparing what you need?

[Tobi]

Originally Posted by SadBoySquad

Hello Tobi.

Of course, I'd be glad to.
What would you want me to provide?
Unfortunately, I cannot share the whole mesh because it concerns confidential information.

I could provide the inlet, though.
How would I go about preparing what you need?

So I am actually only interested in the inlet part. So you can leave out all geometries inside the domain and only provide a test case that has the "terrain" applied. I would like to use it and modify the boundary condition in a way, that you could use the bc without any special treatment.
Add a script that meshes the stuff and which applies your correct profile (it would be good to counter-check with a possible new extension). Sent the data to community@Holzmann-cfd.com

[SadBoySquad]

Originally Posted by Tobi

So I am actually only interested in the inlet part. So you can leave out all geometries inside the domain and only provide a test case that has the "terrain" applied. I would like to use it and modify the boundary condition in a way, that you could use the bc without any special treatment.
Add a script that meshes the stuff and which applies your correct profile (it would be good to counter-check with a possible new extension). Sent the data to community@Holzmann-cfd.com

Hello Tobi,

I still quite don't understand what to send you.
How can I separate the inlet from the rest of the geometry?
What do you mean by "terrain"?

[Tobi]

Okay,

I guess you have some buildings inside, or is it just a normal terrain analysis (without any buildings or other special geometries inside the domain?).


So what I would like to need is a domain (just a block) which mimiks your inlet-profile.

Is it clear now?

[SadBoySquad]

Originally Posted by Tobi

Okay,

I guess you have some buildings inside, or is it just a normal terrain analysis (without any buildings or other special geometries inside the domain?).


So what I would like to need is a domain (just a block) which mimiks your inlet-profile.

Is it clear now?

My configuration indeed does contain buildings.
However, I'll try to create a minimum example using a default configuration with a simple block.

I will keep you posted.

[Tobi]

I don't need any block or buildings inside your domain (but of course you can add a block). I just need the terrain, which means that I am only interested in the "inlet" profile... Or maybe I am doing something myself. Thanks in advance, Tobi

[SadBoySquad]

Hello Tobi,

I created a very basic example of a configuration.
You can download it from the following link:
https://www.dropbox.com/s/72pd72r4gq...ample.zip?dl=0

The geometry is very primitive, but I think it'll do the trick:
-- an inflow patch
-- an outflow patch
-- a ground patch
-- front/back/top patches

The inflow patch has linearly varying elevation in this example, my original geometry had random elevation when moving along the y-axis.

As you'll see, I have set boundary conditions for atmospheric boundary layer on the inflow patch.
In this configuration, OpenFoam will take the inflow patch, calculate its minimum z (which is located at minimum y in this inflow patch, since elevation varies linearly along y), and set that as the ground level for all other velocities on the patch.

As we move away from y minimum on the patch, the profiles close to the local ground level will have increasing, non zero values. The profiles should start from 0 velocity instead.

[Tobi]

So yesterday I was thinking about a new implementation. Its not straight forward and tricky. So lets see if I can get some code-snippet work.
The main problem is, that we can apply the condition to x-y-z coordinate and hence, a more reliable logic needs to be applied here. Furthermore, the search of the lowest "coordinate" for each face is not straight forward either.