[aestas]

Hello, everyone, a problem now confused me.
i defined some F_UDMI in my udf, and a INITIAL MACRO was used:

DEFINE_INIT(my_init_func,d)
{
	cell_t c;
	Thread *t;
	face_t f;
	int i;

	/* loop over all cell threads in the domain  */
	thread_loop_c(t,d)
	{ /* loop over all cells  */
		begin_c_loop_all(c,t)
		{
			
			for(i=0; i<sg_udm; i++) 
				C_UDMI(c,t,i) = 0.0;
				

		}

		end_c_loop_all(c,t)
	}
	thread_loop_f(t,d)
	{
		if((THREAD_STORAGE(t,SV_UDM_I))!=NULL)
		{
			begin_f_loop(f,t)
			{
				for(i=0;i<sg_udm;i++)
					F_UDMI(f,t,i)=0;
			}
			end_f_loop(f,t)
		}
		else
		{
			Message("Skipping FACE thread no. %d..\n", THREAD_ID(t));
		}
	}
}

And when i run fluent, message occurred:
"Skipping FACE thread no. 3..
Skipping FACE thread no. 8.."
My model is a simple 2d Axisymmetric model:
QQ??20150526164225.jpg

i do not understand why UDMs at these two FACE THREAD are not available, i have to use UDM to define uds_flux later. Could someone explain these to me?

[`e`]

How many times does this message occur on your screen? Perhaps these threads are not featured on all parallel nodes. Do you experience the same problem while running in serial model? Similarly, are the UDM values as you expect when you check them after initialising? Note: UDM are initialised with zero when created and therefore you should choose a nonzero number for this verification task.

[aestas]

Thanks for your reply.
It occurred everytime i initialize...i don't understand why these face threads cannot be available.
For now, i used an if-else sentence:if the face value are not available, then i will get

c1 = F_C1(f,t); 
t1 = F_C1_THREAD(f,t);

and use the cell value instead.
And i donot know whether this is accurate enough. For now, i am working on the convergence of the solution...

Originally Posted by `e`

How many times does this message occur on your screen? Perhaps these threads are not featured on all parallel nodes. Do you experience the same problem while running in serial model? Similarly, are the UDM values as you expect when you check them after initialising? Note: UDM are initialised with zero when created and therefore you should choose a nonzero number for this verification task.

[`e`]

What faces have the IDs 3 and 8? If they correspond to the faces with periodic boundary conditions, perhaps it's nonphysical to allocate two UDM values at the same location.

[aestas]

I do not know how to find where faces have the IDs 3 and 8 are..
i used "message "sentence to pring out the coordinate of each point, but they are to many...

Originally Posted by `e`

What faces have the IDs 3 and 8? If they correspond to the faces with periodic boundary conditions, perhaps it's nonphysical to allocate two UDM values at the same location.

[`e`]

Originally Posted by aestas

I do not know how to find where faces have the IDs 3 and 8 are..

Look under Boundary Conditions and check which boundary has the corresponding face/zone ID of 3 and 8.

[aestas]

zone ID 3 is the axisymmetric axis.
zone ID 8 is the interior.
Does this means that all the face in the interior were not initialized?

Originally Posted by `e`

Look under Boundary Conditions and check which boundary has the corresponding face/zone ID of 3 and 8.

[pakk]

Fluent is a finite volume package. So volumes (2D volumes in your case) are important, and that is the basic "calculation unit".

Only at the boundaries, Fluent has to do something to get fluxes, so that is why F_UDMI can store values at boundary faces. (1D faces in your case). Storing UDMI's on internal faces is a waste of space, because normally you don't need them. Temperature and velocities are also not calculated on internal faces.
So for that reason it makes sense to me that F_UDMI's are not defined on internal cell zones.

At the axisymmetric axis, the flux of anything is zero. So there is no need to store flux variables, and Fluent apparently chose to also not store F_UDMI values there.

[aestas]

I am so sorry for not replying you in time because of the network.
Your explaination sounds reasonable to me, thank you~
Based on this reason, if i want to use F_UDMI to define UDS_FLUX, for example, my opinion is:
1. at the boundaries, use if((THREAD_STORAGE(t,SV_UDM_I))!=NULL) to check if F_UDMI is available at the boundry, if not (just like at the axisymmetric axis), i should use the C_UDMI value of the adjacent cells C0 instead
2. at the internal cell zones, use average C_UDMI values of adjacent cells C0 and C1 with respect to the face instead.
Am i right?

Originally Posted by pakk

Fluent is a finite volume package. So volumes (2D volumes in your case) are important, and that is the basic "calculation unit".

Only at the boundaries, Fluent has to do something to get fluxes, so that is why F_UDMI can store values at boundary faces. (1D faces in your case). Storing UDMI's on internal faces is a waste of space, because normally you don't need them. Temperature and velocities are also not calculated on internal faces.
So for that reason it makes sense to me that F_UDMI's are not defined on internal cell zones.

At the axisymmetric axis, the flux of anything is zero. So there is no need to store flux variables, and Fluent apparently chose to also not store F_UDMI values there.

[pakk]

Originally Posted by aestas

I am so sorry for not replying you in time because of the network.
Your explaination sounds reasonable to me, thank you~
Based on this reason, if i want to use F_UDMI to define UDS_FLUX, for example, my opinion is:
1. at the boundaries, use if((THREAD_STORAGE(t,SV_UDM_I))!=NULL) to check if F_UDMI is available at the boundry, if not (just like at the axisymmetric axis), i should use the C_UDMI value of the adjacent cells C0 instead
2. at the internal cell zones, use average C_UDMI values of adjacent cells C0 and C1 with respect to the face instead.
Am i right?

I don't know what you mean by "use F_UDMI to define UDS_FLUX". What do you mean by UDS_FLUX, and why is it something you need to define?

[aestas]

In some marco i need to use the face value of UDM, for example in the DEFINE_UDS_FLUX marco.

Originally Posted by pakk

I don't know what you mean by "use F_UDMI to define UDS_FLUX". What do you mean by UDS_FLUX, and why is it something you need to define?

[pakk]

The help for DEFINE_UDS_FLUX says how to deal with interior faces:

"Additionally, since most quantities in ANSYS Fluent are not allocated in memory for interior faces, only for boundary faces (for example, wall zones), your UDF will also need to calculate interior face values from the cell values of adjacent cells. This is most easily done using the arithmetic mean method. Vector arithmetic can be coded in C using the NV_ and ND_ macros (see Additional Macros for Writing UDFs)."
So yes, that is basically your point 2.

And for your point 1: I think that should work. It might not be needed, because if Fluent is smart it should never ask for the UDS flux at the rotation axis boundary, but better be safe.

[aestas]

Thank you so much! It's a fruitful conversation!

Originally Posted by pakk

The help for DEFINE_UDS_FLUX says how to deal with interior faces:

"Additionally, since most quantities in ANSYS Fluent are not allocated in memory for interior faces, only for boundary faces (for example, wall zones), your UDF will also need to calculate interior face values from the cell values of adjacent cells. This is most easily done using the arithmetic mean method. Vector arithmetic can be coded in C using the NV_ and ND_ macros (see Additional Macros for Writing UDFs)."
So yes, that is basically your point 2.

And for your point 1: I think that should work. It might not be needed, because if Fluent is smart it should never ask for the UDS flux at the rotation axis boundary, but better be safe.