[Kmech]

I have problem to recognize output value of my CFD solution but there are many heat transfer coefficient in solution.

In this solution there are Surface heat transfer coefficient, wall heat transfer coefficient and Specified Y+ based HEAT TRANSFER COEFFICENT.

In this results What is Y+ based HEAT TRANSFER COEFFICENT? Please give proper reason for particularly Ansys Fluent CFD.

[LuckyTran]

It's not specific to Fluent and not special to Fluent. You deal with this everywhere in heat transfer. "Heat transfer coefficient" is not a unique parameter. For any amount of heat flux, you define a heat transfer coefficient for a given reference temperature. There are as many distinct heat transfer coefficients are there are reference temperatures (i.e. an uncountable number).

The specified Y+ based heat transfer coefficient takes a user input of y+. The reference temperature value is obtained locally via the temperature at the specified wall Y+ value. The heat transfer coefficient is then calculated using this temperature at Y+ of (some number). The idea is that using this reference temperature at some Y+ value, you get a heat transfer coefficient that is more universal than some arbitrary free stream reference temperature value because all boundary layers look just about the same once I am inside the boundary layer. If none of these benefits appeals to you, then just simply don't use the specified Y+ based heat transfer coefficient and continue to use your own reference temperature.

[atelcikti1]

actually it has been implemented in Star CCM+ for a long time. Its better to see in Fluent also. If you dont have defined reference temperature ie. simple problems like flow in pipe, its better to use yplus based htc.

I have now a good question i think. Do we have access to other flow variables (rho, velocity etc.) at specific yplus. Fluent simply implemented to find reference temperature, i guess background is ready. Did they put into UDF variables, anyone has info?

Originally Posted by LuckyTran

It's not specific to Fluent and not special to Fluent. You deal with this everywhere in heat transfer. "Heat transfer coefficient" is not a unique parameter. For any amount of heat flux, you define a heat transfer coefficient for a given reference temperature. There are as many distinct heat transfer coefficients are there are reference temperatures (i.e. an uncountable number).

The specified Y+ based heat transfer coefficient takes a user input of y+. The reference temperature value is obtained locally via the temperature at the specified wall Y+ value. The heat transfer coefficient is then calculated using this temperature at Y+ of (some number). The idea is that using this reference temperature at some Y+ value, you get a heat transfer coefficient that is more universal than some arbitrary free stream reference temperature value because all boundary layers look just about the same once I am inside the boundary layer. If none of these benefits appeals to you, then just simply don't use the specified Y+ based heat transfer coefficient and continue to use your own reference temperature.

[LuckyTran]

Originally Posted by atelcikti1

actually it has been implemented in Star CCM+ for a long time. Its better to see in Fluent also. If you dont have defined reference temperature ie. simple problems like flow in pipe, its better to use yplus based htc.

It's much older than Star. Rescaling based on inner coordinates has been around for over a century and was what motivated Prandtl to come up with boundary layer theory in the first place. Not that I wasn't aware of its implementation in Star since I've been using it for over a decade. Btw, it was implemented in Fluent before it was implemented in Star.



y* based heat transfer coefficient is just a means to rescale wall heat fluxes or wall BC's. Unless it is a wall flux, it makes no sense to request flow variables at a given *. If you want actual cell properties at a given y*, that would just be the cell properties. Conversely, you have the Tref, just calculate the properties at the given Tref.