Problem with fluid interface on rotating domain
 

Hi, i have a fluid interface problem in my project that i don´t know how to solve. Im basically modelling the effect on the temperature field of an axial fan on large vineyard (a wind machine for frost protection, for those who may know), which has an angle of 7° with respect to the floor, so it pushes air 7° downwards.

I already did a simulation of the fan itself with all its geometry and things like that, and from that simulation i obtained the average air velocity (20 m/s) at the outlet of the fan (vorticity is practically zero at the oultlet according to cfx post, due to the fan design).

That being said, in my main simulation im modeling the fan as a cilinder domain with a general momentum source of 20 m/s (the standard technique). For the geometry of the simulation see "isometric view" and "side view" images attached.

There are two domains in the simulation: the whole space of air and the cilinder. The cilinder is well, the cilinder, and the space of air is the giant cube of the image with a hole in the middle, just where the cilinder initially is. The fan oscilates (the whole body) around a vertical Y axis placed like 2 mrs apart (see image called "vertical Y axis" with an oscilation speed of 0,2 rpm, ie a whole 360° oscilation in 5 minutes.

I only need to do a transient simulation of the fan oscilating 37,5 seconds, not the whole 5 minutes. I already run a transient simulation with that time and adaptive timestepping, but with the fan fixed, ie not oscilating at all. The results where pretty good so im not going to go into detail about meshing, boundary conditions and setups because the issue is clearly not there.

Here comes my problem: when i tried running the transient simulation with the fan oscillating, the general momentum source only pushes air throughout the remaining interface between the cilinder and the big domain, and not throuout the whole front face of the cilinder, which is what i need (see image called "fan oscillating" to get a clear understanding).

I highly suspect that this happens because as soon as the cilinder stop "matching" the hole in the big domain, the front and back faces of the cilinders become default wall boundaries, and therefore the momentum source cant make air pass through them. By the way, im using transient rotor stator configuration for the interface with pich angles of 360° and 360°.

The thing is i cant set boundary conditions of opening or inlet/outlet for the front and back faces of the fan, because if i do that i would need to impose a determined temperature, and in this particular simulation the temperature cannot be imposed, it must be concecuence of the temperature of the air being pushed (which comes from different heights etc).

Finally my question is: how can i fix that so air is being pushed thorout all the front face of the fan/cilinder?

Greetings and sorry for the wall of text.

No problem with the long post. In fact I appreciate the fact that you properly explained your issue and the background behind it.

To answer your question:
To do this simulation you will need to move the cylidrical fan domain (which you are doing), but you will then need to use moving mesh in the stationary ambient domain to deform the surrounding mesh to connect to your fan domain. Then the interface between the two domains will always line up. The problem you are seeing is because the ambient domain is not moving and the interface is not lining up between the two domains.

But a comment which could make things a LOT easier:
I do not see why you need a cylidrical domain to hold the fan. Why not just have a single fixed domain for everything, and just define a general momentum source which pushes the air in the vector direction as a function of time? Then you can rotate the source, move it around, make it stronger or weaker or whatever you want to do - and you do not need moving mesh, interfaces, multiple domains or anything. Simple!

How do you make the source rotate?
Something like:
VelX = A*cos(W*t)
VelY = A*sin(W*t)

Where A is the velocity you want in your jet and W defines your rotational speed.

How do you make the source move?
A source term set to zero does nothing. So define your entire domain as the source, but only give it a value in the region where your fan is.
V = 1[m/s]
InSourceX = if(x<V*t,if(x>V*t-1[m],1,0),0)
InSourceY = if(y<1[m],if(y>0[m],1,0),0)
InSourceZ = if(z<1[m],if(z>0[m],1,0),0)
InSource = InSourceX*InSourceY*InSourceZ

This defines a source 1m x 1m x 1m translating at 1m/s along the X axis.

First of all, thanks for your response.

Well, before commenting about your interesting idea, i would like to let you know that apart from making the fan domain oscilate, i made "oscilate" the general momentum source too.

For that i defined the general momentum source as:

x component: -5E2[kg m^-3 s^-1]*((Velocity u)-20*cos(pi/180*7)*sin(phi) [m s^-1])

y component: -5E2[kg m^-3 s^-1]*((Velocity v)+20*sin(pi/180*7) [m s^-1])

z component: -5E2[kg m^-3 s^-1]*((Velocity w)- 20*cos(pi/180*7)*cos(phi) [m s^-1])

mom source coeff: -500 [kg m^-3 s^-1]

Where phi represents the azimuthal angle and is an expresion defined as:

phi=2*pi[rad]/(5*60)[s]*t

In concecuence, the momentum source is exactly aligned to the angle of rotation of the fan domain.

Now, with respect to your second suggestion, i understand your general idea but the problem i see is the following: how can i make it so the flow rate of that configuration is equal to the flow rate of the current cilinder?

The thing is the flow rate from the fan is Q=V*A, where A is the sectional area (in this case aprox 3,2 [m^2]). If i make a "cube" as you suggest, it wouldnt be the same same flow rate due to the different area, would it?

Finally, i didnt understand your Insource "code" and how to implement that final multiplication in the momentum source imputs. The other thing, is this method compatible with the fact that the flow a 7° "outlet angle"? That angle is extremelly important for my simulations.

Greetings.

Q1: Please attach your CCL so I can understand how you have set this up.

Q2:
I was not suggesting making it a cube. I used a cube as it was easy to define in CEL as an example. You will need to rewrite this to define your actual cylindrical domain.

You rewrite your momentum source as (X eqn only is shown):
x component: -5E2[kg m^-3 s^-1]*((Velocity u)-20*cos(pi/180*7)*sin(phi) [m s^-1])*InSource

Yes. You define the 3 momentum terms to give you any vector you like.

Please attach your CCL so I can understand how you have set this up.

No need to, with your second answer i fully understand your suggestion.

"I was not suggesting making it a cube. I used a cube as it was easy to define in CEL as an example. You will need to rewrite this to define your actual cylindrical domain."


Any suggestion on specific documentation to search for learning how to do that?

Rewriting it for other shapes is just basic mathematics and programming. For instance:

Radius = sqrt(x*x+y*y)
InSourceR = if(Radius<1[m],1,0)
InSourceZ = if(z<1[m],if(z>0[m],1,0),0)
InSource = InSourceR*InSourceZ

Now InSource will define a cylinder, 1[m] in radius, 1[m] long along the z axis. I will leave the mathematics of adapting this to an arbitrary axis vector and location to you :)

Hi, i did both methods an none om them work like i need to.

First i tried with a moving mesh on the stationary ambient domain with the following settings (only on this domain, not on the cilinder domain):

Mesh deformation:

Option: regions of motion specified
Displacement relative to: previous mesh
Mesh motion model: displacement diffusion
Mesh stiffness: increase near small volumes
Model exponent: 2.0 i tried with 1.0 also with same results)
Reference volume: mean control volume

All of the boundaries of the big domain i set the mesh motion option to stationary, EXCEPT the "side area" of the cilinder hole, which i set to mesh motion unspecificied.

Results: EXACTLY the same as before (see image attached on the first post on this thread), the air only moves through the remaining interface, not through the entire front face of the cilinder, Which is what i need.

After this i tried your technique of only using the stationary big domain (with no cilinder) and programming a local general momentum source. After a lot of thinking i managed to describe the geometry of the source along the desired axis and position, but with no rotation/oscilation yet.

I am running a transient simulation with this mom source (stationary) and the outlet velocity has fully and well converged to the desired value (20 m/s) (see images attached of vector plots, panoramic view and close up).

The problem though is that the timestep size behaving kinda weird and is too low after an entire day of running (see monitor plot attached).

What do you recommend doing at this point?

Moving mesh: Please post your CCL.

Moving source: On the face of it, it appears the flow is correct but simply has not developed yet. It needs to run longer. Large CFD runs take a long time - my longest run took 6 weeks. So more patience is needed, and if you don't have enough patience try more parallel licenses.

But this also shows why you should do all your sensitivity studies: Then you work out exactly the mesh size, time step size and convergence criteria you need and do not waste time calculating to unnecessary accuracy.

Here, in attached files is the mesh motion simulation CCL.

Thanks a lot in advance!

Thanks - a minor point, this is the output file, not CCL. But the output file contains the CCL at the beginning so this is fine.

I would recommend you to put the fan in a cylindrical domain such that it can rotate with no need for the ambient domain to move at all. You will probably have to put a cylinder enclosing the entire fan at its angle to do this, and then use a GGI to connect it to the ambient domain. This will mean you do not need to use moving mesh at all which will simplify things a lot.

mmm what exactly do you mean?

I guess i understand your general idea but have no clue what do you mean in geometric terms. Just to get things clear, in that simulation there is the big domain with a cilindrical hole and there is the cilindrical domain (the general momentum source), which fits exactly into that hole in the starting position. That being said, are you suggesting that i make the hole bigger (more diameter and more length) and that i put a "cilindrical ring" in the new space formed?

Sorry but i don´t understand what do you exactly mean by "putting a cylinder enclosing the entire fan at its angle"...

This might explain it better.

Attachment 60887

The black lines are your fan, with its compound angle. The green lines are the rotating domain, rotating on the blue axis. The outer brown domain is stationary. Here the rotating domain simply rotates and the outer domain does not need any mesh motion. The GGI at the green boundary handles the rotation.

Right, i get it. Just to confirm, would it be like this?

Body n°1: black lines cilinder
Body n°2: green lines cilinder (with a hole in the middle in the position of the black lines cilinder)
Body n°3: brown lines "cube" (with a hole in the middle corresponding to the full vertical cilinder)

Domain n°1 (rotatory domain around the vertical axis): body n°1 + body n°2
Domain n°2: body n°3

Domain n°1- sub domain: body n°1 (asign general momentum source)

Am i correct?

Yes, that is correct.

Thanks Glenn, it worked like a charm. Really appreciated!

Just one point in case if anyone wants to know: the solver manager throws an interface error, that i didnt know how to fix, if you use a vertical cilinder (maybe because of the mix of curved surface and planar surface of the interface, i dont know).

The solution i came up with was to use a sphere instead of a vertical cylinder and the technique worked perfect.

Just out of curiosity Glenn, does someone pays you to answer questions in this forum or you do it just because you like to?

Greetings.

A GGI interface should be able to handle the cylinder. But if a sphere works then you have a path forwards so that is excellent.

Nobody is paid to answer questions on the forum. I just do it because I like trying to help people. I also learn stuff on the forum as well.

Analizing the results in cfx post i encountered a super weird problem.

The initial position of the mom source cilinder is not where it is supposed to be according to the whole default geometry of the system. The cilinder is supposed to oscilate around the Y axis of the sphere (and according to the transient results it does that perfectly, in the right direction and at the asigned rpm) but the problem is it starts the simulation at a random angle instead of "parallel" to the walls (like it is in the default geometry). The first image attached shows the initial position the cilinder is supposed to have and the second image attached shows the initial position the simulation utilizes (Y is the vertical axis).

On top of that, the weird thing is that the "absolute" initial position (timestep=0) it shows the cilinder in the right position but around 1E-4 seconds after, it shows it inmediately in the wrong position, almost like it teleported itself

I looked at all the initial conditions setups and they are all perfect, how can i fix this?

Are you using any moving mesh to do this, or just rotating domains?

I used this exact same configuration:


Body n°1: black lines cilinder
Body n°2: green lines cilinder (with a hole in the middle in the position of the black lines cilinder)
Body n°3: brown lines "cube" (with a hole in the middle corresponding to the full vertical cilinder)

Domain n°1 (rotatory domain around the vertical axis): body n°1 + body n°2
Domain n°2: body n°3

Domain n°1- sub domain: body n°1 (asign general momentum source)


In other words, only that 1 rotating domain and no moving meshes nor any setup out of the ordinary. As i said, the rotating domain behaves perfectly well, the only problem is that it starts in a totally random position, but the rotational velocity and direction are spot on.

There is something wrong in the geometry or set up of the rotating domains. You are going to have to check through it carefully to find it. It is not something we can debug on the forum.