QUESTION:
At ANSYS v11 and earlier, it appears that LDREAD,EHFLU does not read surface heat fluxes from HF emag (HF119/120) as surface loads in a thermal analysis. Is there a workaround?

ANSWER:
The problem appears to exist only when the emag and thermal elements exist on the same side of the surface to which shield conditions were applied in the HF emag model using SFx with the SHLD label. The APDL workaround (see ehflu.mac) used in the model attached to this solution appears to work fine.


Additional background that may be useful:

1) SFLOSS (ETABLE item NMISC,8) is the total surface loss (in Watts for all surfaces experiencing surface loss) for the HF119/120 element.
2) ETABLE item NMISC,9 is the lowest face number flagged with SHLD condition for which nonzero surface loss is calculated.
3) ETABLE item NMISC,10 is the surface heat flux (in W/m^2) on the face number identified by ETABLE item NMISC,9.
4) ETABLE items NMISC,11 and 12 are next highest flagged face number and corresponding surface heat flux in W/m^2.
5) ETABLE items NMISC,13 and 14 are next highest flagged face number and corresponding surface heat flux in W/m^2 after the NMISC,11 face number.
6)Supposean element has only one face with the SHLD flag. If you divide SFLOSS (NMISC,8) by area of the flagged face identified by NMISC,9, you'll get the surface heat flux reported as NMISC,10. I checked this at v11.
7) The attached test model and macro seem to work (total solve time ~2 minutes). The macro writes a command file defining heat fluxes that can be subsequently read into a thermal model when LDREAD,EHFLU does not read in the values (which seems to happen only when HF emag and thermal elements appear on the same side of the boundary flagged with SHLD).
8) I haven't yet checked the MFS for this modeling scenario. If I determine that surface heating is not transferred using MFS, then, until the code is enhanced to account for this case, user


QUESTION:
At ANSYS v11 and earlier, it appears that LDREAD,EHFLU does not read surface heat fluxes from HF emag (HF119/120) as surface loads in a thermal analysis. Is there a workaround?

ANSWER:
The problem appears to exist only when the emag and thermal elements exist on the same side of the surface to which shield conditions were applied in the HF emag model using SFx with the SHLD label. The APDL workaround (see ehflu.mac) used in the model attached to this solution appears to work fine.


Additional background that may be useful:

1) SFLOSS (ETABLE item NMISC,8) is the total surface loss (in Watts for all surfaces experiencing surface loss) for the HF119/120 element.
2) ETABLE item NMISC,9 is the lowest face number flagged with SHLD condition for which nonzero surface loss is calculated.
3) ETABLE item NMISC,10 is the surface heat flux (in W/m^2) on the face number identified by ETABLE item NMISC,9.
4) ETABLE items NMISC,11 and 12 are next highest flagged face number and corresponding surface heat flux in W/m^2.
5) ETABLE items NMISC,13 and 14 are next highest flagged face number and corresponding surface heat flux in W/m^2 after the NMISC,11 face number.
6)Supposean element has only one face with the SHLD flag. If you divide SFLOSS (NMISC,8) by area of the flagged face identified by NMISC,9, you`ll get the surface heat flux reported as NMISC,10. I checked this at v11.
7) The attached test model and macro seem to work (total solve time ~2 minutes). The macro writes a command file defining heat fluxes that can be subsequently read into a thermal model when LDREAD,EHFLU does not read in the values (which seems to happen only when HF emag and thermal elements appear on the same side of the boundary flagged with SHLD).
8) I haven`t yet checked the MFS for this modeling scenario. If I determine that surface heating is not transferred using MFS, then, until the code is enhanced to account for this case, users will need to use nested do loops (APDL) to effect the bi-directional coupling for the case of temperature dependent electrical resistivity. This is a hassle, but very doable.
9) LSCLEAR seems to `miss` SHLD and PORT surface loads ` these do not get deleted unless you issue SFDELE, SFEDEL, or SFADEL as needed. I don`t think leaving them in will hurt the thermal solution but it may trigger a bunch of nuisance warning messages that, in my experience, can take as long as or even longer than the solution itself to process (model size dependent).





Show Form
No comments yet. Be the first to add a comment!