[mejahan]

Dear CFX Experts,
I am trying to use the following equation to calculate the mass inflow though a cut surface in my domain. It is a steady state simulation.
(areaInt_y( Velocity v* (if (Velocity v < 0[m/s] , 1, 0 )) )@ Plane1)+
(areaInt_x( Velocity u* (if (Velocity v < 0[m/s] , 1, 0 )) )@Plane1 ) +
(areaInt_z( Velocity w* (if (Velocity v < 0[m/s] , 1, 0 )) )@Plane1 )
“if (Velocity v < 0[m/s] , 1, 0 )” is to filter the flow entering the surface since I have reverse flow as well. And Plane1 is on the x-z plane.
It works with < 0.3% error at the inlet, however, it is showing me a flow rate larger than the inlet at this cut surface.
If no filter is used, then the total flow rate though this surface is zero. Please see the attached image.
Any thoughts?
Thanks,

[ghorrocks]

Why aren't you using the massFlow() and massFlowAbs() functions?

[mejahan]

Originally Posted by ghorrocks

Why aren't you using the massFlow() and massFlowAbs() functions?

massFlow() return a very small value (close to zero as it should). In addition, based on the CFX reference guide, massFlow() function may not be accurate at a physical locator and the expression that I posted was recommended. On a unidirectional flow surface, both should return mass flow, with a minor discrepancy.
I could not find the massFlowAbs() function in CFD post!

[mejahan]

Here, the main challenge is how to distinguish the flow coming from the domain inlet and the inflow caused by the reverse flow (vortices) at Plane1, sine the dynamics of the flow is relatively complex here. By the “inflow” I mean the flow entering the plane.
Apparently, both of such flows contribute into the inflow calculated by the posted equation, (that is the reason why the expression returns a flowrate higher than the inlet flowrate), however, I am only interested in the flow coming from the inlet BC.
Any thoughts?

[ghorrocks]

The CFX Reference Guide says massFlow() will only be inaccurate at a physical locator which cuts through a GGI interface. I presume you have no interfaces through that plane, so you should use massFlow() and related functions. The method you are doing is less accurate as it is just evaluated at the nodal points, it does not include the integration points.

Forward and back flow components, I would use a contour at zero flow and define a user surface from that. You can then use the massFlow() function on the user surfaces to get the forward and backward flow components.

[mejahan]

Originally Posted by ghorrocks

The CFX Reference Guide says massFlow() will only be inaccurate at a physical locator which cuts through a GGI interface. I presume you have no interfaces through that plane, so you should use massFlow() and related functions. The method you are doing is less accurate as it is just evaluated at the nodal points, it does not include the integration points.

Forward and back flow components, I would use a contour at zero flow and define a user surface from that. You can then use the massFlow() function on the user surfaces to get the forward and backward flow components.

Thank you Glenn for your insight.
I did actually define a isosurface with v<0 and calculated the mass flow at the surface. No differences between the two methods. Either methods include the flow from the vortices in calculating the inflow to the surface.
As I pointed out, I need to find a method to calculate the contribution of the main flow (inlet) in the surface inflow.
Not sure if taking the velocity v angle into consideration would be a precise method.
What do you think?

[mejahan]

I used the velocity v angle <150 and it is not accurate for more complex geometries.
I am not sure though if using the streamline time would help, since it takes a certain time for them to get to this surface from the inlet. And the inflow from the vortices has larger streamline time. But I don’t know how to apply such a condition.

[ghorrocks]

Can you show an image of why splitting it into v<0 and v>0 regions is unacceptable? I do not understand why that is unacceptable for you.

What is velocity v angle? Please show an image to define what that means.

[mejahan]

Originally Posted by ghorrocks

Can you show an image of why splitting it into v<0 and v>0 regions is unacceptable? I do not understand why that is unacceptable for you.

What is velocity v angle? Please show an image to define what that means.

Please see the following reply.
Thanks

[mejahan]

Originally Posted by ghorrocks

Can you show an image of why splitting it into v<0 and v>0 regions is unacceptable? I do not understand why that is unacceptable for you.

What is velocity v angle? Please show an image to define what that means.

Please see the attached image for v<0 condition. It overestimates the inflow rate since it does not discriminate between the main flow and the inflow created by the circulation zones.
Sorry for the confusion, I meant velocity angle with y direction.
If I can find a way to calculate the streamline time at each node of the surface, I can filter the nodes on which the streamline time is larger enough to create such condition.

[ghorrocks]

You can evaluate fluid residence time with an additional variable.

In CFX-Pre, add an additional variable, units [s], with an advection equation but no diffusion. At the inlet set the boundary condition of the variable to be 0[s], and set a source term over the entire simulation domain with a source of 1 [s/s]. In other words, the source term increments the value of the variable by 1s per second.

Rerun the simulation and the variable will be available for post-processing. This will show the residence time of the fluid since it passed through the inlet. You can then use it to define a user surface on your plane by residence time (young versus old).

[mejahan]

Originally Posted by ghorrocks

You can evaluate fluid residence time with an additional variable.

In CFX-Pre, add an additional variable, units [s], with an advection equation but no diffusion. At the inlet set the boundary condition of the variable to be 0[s], and set a source term over the entire simulation domain with a source of 1 [s/s]. In other words, the source term increments the value of the variable by 1s per second.

Rerun the simulation and the variable will be available for post-processing. This will show the residence time of the fluid since it passed through the inlet. You can then use it to define a user surface on your plane by residence time (young versus old).

Thank you Glenn for your advice. I created a new variable to view the flow residence time in CFD Post. It gives me the residence time at the user surface; however, it takes longer for flow at small regions near the solid surface of the main flow to get to this target surface than the recirculation flow inside the dome. Although such low velocity regions may have small contribution to the inflow rate, however, it may underestimate the inflow rate if I ignore them.
If I try to include them by increasing the residence time at the user surface, then I am including the flow from the recirculation zones as well, which overestimates the inflow rate.
I would appreciate to know your suggestion.

[ghorrocks]

I did not understand your comment, but I assume you mean that you cannot easily separate the flow using residence time.

As an aside: This issue shows an important issue in fluid mechanics, which is that exactly what is a recirculation is not easily defined in 3D. In 2D flows you have the separating streamline which is straight forward, but in 3D there is no equivalent. You have to define something which is relevant to your specific case, and that usually involves compromises and is not perfect.

How about you make the residence time source term act only after your sample plane. Then the residence time will only increment after it has passed through the plane. So the fresh fluid will have a residence time of zero, and anything which has been past that plane at any time will have a residence time >0.

[mejahan]

Originally Posted by ghorrocks

I did not understand your comment, but I assume you mean that you cannot easily separate the flow using residence time.

As an aside: This issue shows an important issue in fluid mechanics, which is that exactly what is a recirculation is not easily defined in 3D. In 2D flows you have the separating streamline which is straight forward, but in 3D there is no equivalent. You have to define something which is relevant to your specific case, and that usually involves compromises and is not perfect.

How about you make the residence time source term act only after your sample plane. Then the residence time will only increment after it has passed through the plane. So the fresh fluid will have a residence time of zero, and anything which has been past that plane at any time will have a residence time >0.

Thank you Glenn,
That is a clever idea. How can I make the residence time source term act only at the user surface? Not sure how to implement this method.
Thank you for your help in advance.

[ghorrocks]

Go to your meshing package and define a mesh region where you want it. You will have to remesh to do this. Then run the simulation again on this mesh, where the mesh region is defined as a subdomain with the source term applied to it.

[mejahan]

Originally Posted by ghorrocks

Go to your meshing package and define a mesh region where you want it. You will have to remesh to do this. Then run the simulation again on this mesh, where the mesh region is defined as a subdomain with the source term applied to it.

Hi Glenn,
I applied the method following your advice.
Results do not seem what I expected. As you can see from the attached image, the area of residence time =0 does not represent the fresh flow coming from the inlet. I expected that the area of incoming flow to have exactly residence time =0.
In addition, why the residence time on the user surface has different values based on the contour map, while it should be uniformly zero since it is at the inlet flow region (ledt image).
I only specified the source term to be 1[s/s] inside the volume above a cut surface on this user surface, which divides the entire domain into two subdomains.
Just to confirm my numerical setup:

Additional Variable -> Volumetric / Unit [s] / Tensor Type: Scalar
Default Domain -> Additional Variable -> Residencetime -> Transport Equation
Initialization -> zero over entire domain
Inlet -> zero
Source term -> 1 for the top subdomain

The contour indicates some sort of diffusion!
Please advise if I am missing something here.
Thank you.

[ghorrocks]

Yes, there will be diffusion.

There is physical diffusion if you have set a diffusion coefficient. Check that you set the diffusion coefficient to zero.

There is artificial numerical diffusion from the numerical solution. Check that you are using second order discretisation for the scalar equation, tight convergence, double precision numerics and a fine mesh.

[mejahan]

Originally Posted by ghorrocks

Yes, there will be diffusion.

There is physical diffusion if you have set a diffusion coefficient. Check that you set the diffusion coefficient to zero.

There is artificial numerical diffusion from the numerical solution. Check that you are using second order discretisation for the scalar equation, tight convergence, double precision numerics and a fine mesh.

Thank you for your advice Glenn.
I repeated the simulation with high resolution advetive scheme for this variable, tighter convergence and double precision, and still I get a distribution of residence time over user surface within the fresh flow region.
I assume when the Kinematic Diffusivity is not selected in the setup, it is excluded, but I set the Kinematic Diffusivity= 0.
I did the mesh sensitivity analysis before and my mesh are fine, but will give it a try with a finer mesh.

But, even though the diffusivity for this variable is zero, but it is transported with the fluid particles, which themselves have diffusion effect. Therefore, observing diffusion for this purely convective variable seems unavoidable due to the nature of flow. But how I can take this effect into account?

[ghorrocks]

Numerical diffusion is usually proportional to mesh size. So no matter what your mesh size, if you make it smaller you will reduce numerical diffusion. This includes for meshes which are fine enough so the pressure and velocities are considered mesh-independent.

The best you are going to do is to smear the interface over about 3 mesh elements. So make the mesh elements as small as possible and you can minimise this.

In your case it appears your low numerical diffusion requirement results in a requirement for a finer mesh than a mesh sensitivity study done on pressure or velocity results.

[mejahan]

Originally Posted by ghorrocks

Numerical diffusion is usually proportional to mesh size. So no matter what your mesh size, if you make it smaller you will reduce numerical diffusion. This includes for meshes which are fine enough so the pressure and velocities are considered mesh-independent.

The best you are going to do is to smear the interface over about 3 mesh elements. So make the mesh elements as small as possible and you can minimise this.

In your case it appears your low numerical diffusion requirement results in a requirement for a finer mesh than a mesh sensitivity study done on pressure or velocity results.

Thank you Glenn,
I have tried a finer mesh over the interface, and results are the same with better contour color map for the residence time. I have also tried to reduce the element size of the entire domain, but I faced convergence difficulties showing the transient flow behavior. I need to mention that the flow is entirely laminar and steady state. This behavior is expected in turbulent flows where extremely fine mesh results in resolving small scale eddies.
I was thinking that this problem may arise from the effect of the neighboring elements with extremely different residence time values.
I am also trying another case with finer mesh at the interface.