[gelbebanane]

Hey,
I've got nearly the same case as u do. My case is a periodic cooling pipe.

At the moment i am setting up my BC but i have quiet a lot problem especially when it comes to mapping the outlet values to the inlet. For me it is very difficult to setup the BC and the offset of the mappedPatch BC because my patches are not parallel to the coordinate patches.

Perhaps you can have a look at my thread and help me.



Best Regards,
Phil

[Sniper]

Hi Bruno,

thanks for the reply, I tried what is mentioned in the directory, but was not able to get it work. Should I run the commands mentioned in the web page in the OpenFOAM/user/run directory or some other location, kindly let me know.

Thanks,

Vimal

[wyldckat]

Hi Vimal,

OK, a very quick way to build swak4Foam is like this:

mkdir -p $FOAM_RUN
cd $FOAM_RUN
cd ..
wget https://github.com/wyldckat/swak4foam/archive/OF22X.zip
unzip OF22X.zip
cd swak4foam-OF22X
./Allwmake > make.log 2>&1

#run the last line once again:
./Allwmake > make.log 2>&1

Once you've finished running the commands above, you should have a working swak4Foam installation.

Best regards,
Bruno

[gelbebanane]

Hey Sniper and wydlckat,
I had a look at your hints about Snipers case. My case is nearly the same as the one frome him. The only difference is, my patches are not parallel to the coordinate axes/planes.

Right at the moment i am facing a lot of problems with setting up my case with cyclic as well as mapped boundary conditions. Especially with setting the offsets for the cyclic/mapped planes in a case where the planes are not exactly conformal.

As i explained in my thread already i want to compare OpenFoam with a Fluent case.
The Fluent case has a periodic inlet with steady state pressure based simple solver.


- Can you look at my case and give ma a hint why my cyclic BC's dont work.
- Can you tell me where i can edit the pressure gradient or the mass flux for the inflow because out of the fluent case i get that it is pressure based.
- Is my geometry working at all or do i have to edit it with i dont know commands like topoSet etc.

Greetings
Phil

[wyldckat]

Greetings gelbebanane,

Originally Posted by gelbebanane

Right at the moment i am facing a lot of problems with setting up my case with cyclic as well as mapped boundary conditions. Especially with setting the offsets for the cyclic/mapped planes in a case where the planes are not exactly conformal.

I've taken a look into your case. I ran the script "parallelized.sh" in order to generate the mesh.
I was going to suggest that you had a look into the tutorial "incompressible/pisoFoam/les/pitzDailyMapped" and to suggest using the "mapped" boundary condition, taking into account that the offset is the vector between the centroids of each patch... but since the cell count is not identical, things get a bit complicated.

Originally Posted by gelbebanane

As i explained in my thread already i want to compare OpenFoam with a Fluent case.

What thread?
I've taken a look into the list of posts you've made lately and I got lost. I have no idea to which thread you're referring to.


The inlet and outlet patches do not have the exact same area, which are part of the problem. I suggest that you take a slightly different approach:

1. Make a point transformation of your geometry, so that the inlet and outlet surfaces are fully aligned.
2. Generate the mesh for the distorted geometry.
3. Once the mesh is complete, apply the opposite transformation, so that the patches are in the desired positions. Have a look at this post for ideas: http://www.cfd-online.com/Forums/ope...tml#post394044 post #2

Best regards,
Bruno

[gelbebanane]

Hey,
thanks for your suggestions. Unfortunately i saw too late that you will answer my question at your github so i had no more time to update my post above.

From your other link that you have attached i couldn't get any information because there it is just an blockMesh created mesh.


1. I made a point transformation in Salome and translated my inlet to my outlet and exported this as my new .stl file.
2. Generated the mesh but without any improvements.
3. Dont know what you meant here, so i came to the point that i started already wrong at 1.

What i also tried is to rotate my geometry by an angle so that the inlet and outlet patches are parallel to the blockMesh patches. but it still gives me a different number of cells back.
I think the main problem is the snappy process and my sharp edges. (snappy run without snap and layer add, just castellatedmesh feature)
edge.jpeg


Isn't it possible to use different cell numbers as well as the mapped condition?
I can also use the mentioned rotated mesh for my case, i just have to edit my velocity vector.

I have also tried, using the main edges of my geometry for my blockMesh mesh but the mesh quality after snappy didn't improve and it also didn't snap anymore.

I also tried cyclic and cyclicAMI. cyclic does not work because of different cell numbers and cyclicAMI gives me an error back when i try to change my patches with "createPatch" command.

>createPatch -overwrite
....
Build  : 2.2.x-ae7a43cbbfe3
Exec   : createPatch -overwrite
Date   : Jan 13 2014
Time   : 10:46:56
Host   : 
PID    : 28596
Case   :
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create polyMesh for time = 0

Reading createPatchDict

Adding new patch inlet as patch 4 from 
{
    type            cyclicAMI;
    neighbourPatch  outlet;
}

Adding new patch outlet as patch 5 from 
{
    type            cyclicAMI;
    neighbourPatch  inlet;
}


Moving faces from patch eingang to patch 4
Moving faces from patch ausgang to patch 5

Doing topology modification to order faces.

AMI: Creating addressing and weights between 142345 source faces and 142177 target faces
--> FOAM Warning : 
    From function AMIInterpolation<SourcePatch, TargetPatch>::checkPatches(const SourcePatch&, const TargetPatch&)
    in file lnInclude/AMIInterpolation.C at line 109
    Source and target patch bounding boxes are not similar
    source box span     : (0.000115329 0.0987398 0.152781)
    target box span     : (8.22414e-05 0.0987483 0.152795)
    source box          : (0.00671131 1.90699e-06 -0.00673927) (0.00682664 0.0987417 0.146042)
    target box          : (0.0301843 1.448e-06 0.0167262) (0.0302665 0.0987498 0.169521)
    inflated target box : (0.0210879 -0.0090949 0.00762988) (0.0393629 0.107846 0.178617)


--> FOAM FATAL ERROR: 
Unable to find initial target face

    From function void Foam::AMIInterpolation<SourcePatch, TargetPatch>::calcAddressing(const SourcePatch&, const TargetPatch&, label, label)
    in file lnInclude/AMIInterpolation.C at line 712.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   at cyclicAMIPolyPatch.C:0
#3  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, bool) in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#5  Foam::cyclicAMIPolyPatch::resetAMI() const in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#6  Foam::polyBoundaryMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#7  Foam::polyMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#8  
 in "/sw/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/bin/createPatch"
#9  __libc_start_main in "/lib64/libc.so.6"
#10  
 at /usr/src/packages/BUILD/glibc-2.11.2/csu/../sysdeps/x86_64/elf/start.S:116
Abgebrochen

It's so frustrating i am working since 2 month on this mesh but i couldn't it work properly for full edge alignement, i even create the .eMesh files manually to achieve good results.

Looking forward for any further suggestions
Greetings
Phil

[wyldckat]

Hi Phil,

Mmm... OK, I've got two suggestions:

1. Create a much simpler version of your case, with just the outer patches, without those bumps on the side
   Prepare the case to be meshed with snappyHexMesh, similarly to OpenFOAM's tutorials. You can use the tutorial case "compressible/rhoPimpleDyMFoam/annularThermalMixer" as a base idea... have a look at the "Allrun" script.
   Then share the case. This way more people can look at the same problem and try for themselves possible fixes!
   And having the STL geometry for the two positions would also help, since this would allow to test the mesh generation on both positions. Knowing the transformation vector would also help, since this could be used to affect the base mesh made with blockMesh.
2. This one is a bit convoluted:
   1. First generate the surface mesh in Salome or enGrid.
   2. Then export the surface mesh to Blender (or perhaps do the next steps in Salome).
   3. Delete the top patch and clone the bottom patch to the location of the top patch (or vice-versa).
   4. Fix any missing gaps, in case the cloned version does not fit perfectly in place of the old patch.
   5. OK, this part is now really tricky... I don't know if either Blender or Salome is able to fix this... but the problem is that by cloning the patch to another place, the vertexes on the cloned version do not align well to the vertexes on the patches perpendicular to the cloned side. This means that those sides need to be re-meshed, in a way that they can be realigned with the new surface.
   6. Once the surface mesh is done, you can now do a volume mesh and have a perfect cyclic connection between patches, even if you morph the geometry.

Best regards,
Bruno

[gelbebanane]

Hey there,
i've managed to get my case running with "cyclicAMI".
Now my case is running with a modified simplefoam/cyclic solver from here.

The problem is now that i dont get the expected values like in Fluent. My pressure gradient is not the same and i dont know if i specified my mass flow rate with "Ubar" correctly.
My inlet velocity is (12 0 0) m/s and my mass flow rate 0.07865 kg/s.
All other initial values are specified under 0/include/initialConditions.


I've uploaded my case with the appropriate BC. You have to use the solver that is also attached in this thread. Just "make" the solver, i have already changed all neccessary files.
ribbed.zip
simpleFoamCyclic.zip

Regards,
Phil

[wyldckat]

Greetings Phil,

I'm getting this error message:

Unknown patchField type knutRoughWallFunction for patch type wall

Which OpenFOAM version are you using exactly? And are you using any customized boundary conditions?

In addition, the solver gives a warning about these two:

    inlet
    {
        type            cyclicAMI;
        value           101325;
    }

    outlet
    {
        type            cyclicAMI;
        value           101309;
    }

It should be:

    inlet
    {
        type            cyclicAMI;
        value           uniform 101325;
    }

    outlet
    {
        type            cyclicAMI;
        value           uniform 101309;
    }

Although, you're imposing wrong values in these boundary conditions, since the pressure field in simpleFoam is actually "p/rho" and is relative to a reference pressure. In theory, what you want is this:

    inlet
    {
        type            cyclicAMI;
        value           uniform 0;
    }

    outlet
    {
        type            cyclicAMI;
        value           uniform -16;
    }

Although the "-16" should actually be divided by the density of the fluid, which I'm not certain what the value is in your case.

Beyond this, the relaxation factors seem very relaxed. Are you certain that the solution converged?

Best regards,
Bruno

[gelbebanane]

Ok,
i have changed my case.
Actually it was called nutkRoughWallFunction not knutRoughWallFunction.

i have also changed my pressure to what you said.
But for my outlet pressure im not sure.

First of all my boundaries. My mass flux is 0.07865 kg/s, density=1.1697 kg/m^3, pressure gradient -485.4435 pascal/m, dynamic viscosity 1.85964e-05 kg/m s.
My inlet flow is U=(12 0 0).

So i calculated my boundaries based on these values:

nu=1,85964e-05 / 1,1697 = 1,58984e-05

the pressure value for the outlet i got throug my geometry.
the distance from inlet to outlet in x direction is 0.023483.

outlet pressure= -485,4435 * 0,023483 / 1,1697 = -13, 7785

.
Did i use the wrong length for the gradient? Do i have to use the distance vector that is perpendicular to the inlet/outlet patches or is the distance vector in flow direction ok?

So the last value was "Ubar" to calculate. I used the continuum equation for this.
But here i have the same problem as mentioned above.
Is the mass flux perpendicular to the inlet and outlet patch or is it in flow direction? i made up 2 calculation, 1 with mass flux orthogonal and 1 with mass flux in flow direction.
So i got this Ubar values:

Ubar= massflux / (densitiy *patch area)

I got the patch area of my geometry inlet within Salome. The same thing about direction etc counts also for the patch area do i have to take the normal area or the perpendicular projected patch area?

I hope you understand halfway what i want so say you with my calculations and problems.
For now i made 4 cases. Each a variation of Ubar direction and pressure gradient on/off.

Here is a picture with what i mean about perpendicular and in flow direction (view is on top of my geometry to the ground, bird perspective, dont know the english word for this).
flowdir.jpg

And here is a case with pressure gradient on and mass flux in flow direction. The problem for now is that my flow does not look not even close like the one in Fluent.
rippencase_salome.zip

[wyldckat]

Greetings Phil,

I finally managed to give a proper look into this. Here's what I've found:

1. The resulting mesh for the latest attached case has some issues that might not be ignorable. Run this command to see what I mean:
   

   checkMesh -allTopology -allGeometry

2. If you're comparing with Fluent, I suggest that you take 2 approaches, in order to validate your workflow:
   1. Export this mesh to Fluent:
      

      foamMeshToFluent

      Then try running in Fluent. I'm guessing that even Fluent will give you some... strange results
   2. Export the mesh you have in Fluent (generated by it, not OpenFOAM) and import into OpenFOAM. The utility for importing should be fluent3DMeshToFoam.
   This way you can validate if things are making sense on both ends, since the mesh is really-very-extremely important!
3. Do not use kOmegaSST right-off-the-bat. Use k-Epsilon first, since it's easier to start with it first. Only after it's working with it, should you move onward to the next step. Because I tried running simpleFoam in parallel and it crashed right on the first iteration... possibly to both the turbulence model, as well as the mesh.
4. Still on the topic of the mesh: Attached is an image that demonstrates that this mesh is far from perfect. More and more it feels that it would be best for you to use a non-inclined geometry first, figure out how the mesh is done perfectly for a "normal looking geometry" and then let us know when you've solved the problems up to this point.
   Then you can use moveDynamicMesh to distort the mesh and achieve the geometry+mesh you want.
   How neat can this mesh solver be? Have a look into the second attached image! It's from the tutorial "mesh/moveDynamicMesh/SnakeRiverCanyon".

Best regards,
Bruno

[sourav0921]

In case of fvOption, we impose momentum source term but can, though there is flow but we cannot observe any pressure gradient along the channel length. Can anyone please tell me how to obtain actual pressure in case of fvoptions


Regards,

Sourav