Radiosity Solver and RSURF 1

[HVSmith]

Hi - I'm having problems using the radiosity solver.

I am trying to model a thin plate. Heat is generated on the plate and then there is radiative cooling. For a single plate I think I have the model working correctly.

However, I also require to simulate a double plate scenario, where the plates radiate between themselves, as well as the surroundings.

flash3780 kindly sent this useful link:

http://www.ansys.com/staticassets/A...article/AA-V1-I1-View-Factoring-Radiation.pdf

But I am still having trouble in getting radiation between the plates. Presently I am only heating one plate, to see if I can see any heat transfer to the other - but I see nothing

I have attached my macro file in case anyone can see anything that I'm doing obviously wrong? Or can give me any tips for succeeding?

http://files.engineering.com/getfil...7-98c8-4280-9bd0-b9f4994997b8&file=KEKRAD.mac

Thanks for any help you are able to offer, all very much appreciated.

HVSmith

 

[flash3780]

I think that one problem is that you're problem is issuing the RSURF command more than once for the same enclosure. I think that if you use SFE, you must first issue RSURF to create the elements, select those elements, and then issue SFE to apply the boundary condition. From the Ansys command reference:

If you have already issued RSURF for a surface and you issue RSURF again, ANSYS creates a new set of radiosity elements and nodes over the existing set, resulting in an erroneous solution.

Also, if you're radiating between infinite(?) plates, you may want to issue the VFSM command to prevent your model from radiating into space. But, I've found that even when scaling the view-factor sum to zero, I still need to define a SPCTEMP for the enclosure... not sure why.

You may want to start with a static problem before jumping into a transient problem... just for easier debugging.

 

[flash3780]

Oh, I forgot to mention: If you're radiating across small gaps, contact elements can handle the behavior much more efficiently (though the functionality is not well documented in the ANSYS help). Check Sheldon's page for details (the website seems to be down at the moment, but I'm sure it'll be back soon):

http://ansys.net/?mycat=search&mytype=Tips&mycategory=HeatXfer

Basically, you need to apply your boundary condition to a frictionless, symmetric contact pair (CONTA172) in near-contact (i.e. within the pinball region) using the SFE command. Here's an example that I've used recently in one of my Workbench models (input as a command snippet inserted under a contact pair):

!   Commands inserted into this file will be executed just after the contact region definition.
!   The type number for the contact type is equal to the parameter "cid".
!   The type number for the target type is equal to the parameter "tid".
!   The real and mat number for the asymmetric contact pair is equal to the parameter "cid".
!   The real and mat number for the symmetric contact pair(if it exists) is equal to the parameter "tid".

!   Active UNIT system in Workbench when this object was created:  Metric (m, kg, N, s, V, A)

nropt,full
a = cid    	! Store the contact ID in some variable

!*********ENTER EMISSIVITY HERE*********!
e1 = 0.950	! Microsil Insulation ([URL unfurl="true"]http://www.zircarceramics.com/pages/microporusinsulation/microporous.htm)[/URL]
e2 = 0.950	! Microsil Insulation ([URL unfurl="true"]http://www.zircarceramics.com/pages/microporusinsulation/microporous.htm)[/URL]
e12= e1*e2/(e1 + e2 - e1*e2)

MP, emis, a, e12,   			! Define the emissivity as a material property to the material used for contact elements whose ID is 'a'
!*********ENTER CONVECTION HERE*********!
mptemp,        1,      0,    100,    200,    300,    400,    500,    600,    700,    800,    900,   1000
mpdata, hf, a, 1,   5.77,   7.56,   9.26,  10.79,  12.14,  13.34,  14.25,  15.57,  16.72,  17.86,  19.09	! Define Gap Convection (4.20mm)

keyopt, a,  1, 2
rmodif, a, 14, 0.00e00
rmodif, a, 16, 5.67e-8		! Modify real constant number 16 for contact id 'a' to input steffan boltzman constant
!*********ENTER VIEW FACTOR HERE*********!
R1=38.55e-3
R2=42.75e-3
VF=R1/R2
rmodif, a, 17,VF			! Modify real constant number 17 for contact id 'a' to input radiation viewing factor

esel,s,type,,a
esel,r,ename,,conta174

sfe,all,1,conv,1,-a
sfe,all,1,conv,2,100

allsel

 

[flash3780]

^ Erm... mind you, later on I've issued a TOFFST command...

 

[HVSmith]

Hi - thanks for your replies - they've been useful to read and I think I have it working now.

I am also trying to model a single plate case where it is heated and then radiates to ambient.

Initially I was using RDSF to do this, but the viewfactors were all zero (can't decide if this is a problem or not, in radiating to ambient) so I tried using RAD but keep getting the warning:

"RAD option on SF/SFE command is only supported by FLOTRAN elements (Fluid141, Fluid142). Elements Surf151 and Surf152 with Keyopy(9)>0 without the SF/SFE command should be used for further analyses."

Now, I'm using Shell131 and then the RSURF command to generate Surf252's - am I better sticking with RDSF (even though there are no other surfaces) or change what I'm doing with RAD?

Thanks again for your continued help.
HVSmith

 

[flash3780]

Check out my previous thread on Ambient Radiation: thread569-298500... third post in has an example of radiation to ambient. The SF/SFE command is not required; you simply need to apply SURF152 elements which are tied to a "space node" with the proper keyopts and real constants to the surfaces radiating to ambient.

Convective coefficients can also be applied, but that does, in fact, require the SF/SFE command (also discussed in the aforementioned thread).

 

[HVSmith]

Hi - yes, I had read that a few times (and have read it many times again since) but I'm still having trouble - are you able to offer any further advice to my questions below?


Here's a small section of the code, relating to the radiation:

!----------------------------
!DEFINE ELEMENT TYPES
!----------------------------

ET,1,SHELL131 !THERMAL SHELL
KEYOPT,1,3,2
KEYOPT,1,4,1
R,1 !REAL CONSTANT
SECTYPE,1,SHELL
SECDATA,1E-6,1

!----------------------------
!GEOMETRY AND MESH
!----------------------------
BLC4,-L/2,-L/2,L,L !FOIL GEOMETRY
AESIZE,ALL,L/20 !MESS FOIL GRID 20X20
AMESH,ALL

ASEL,S,AREA,,1
ESLA,S
NSLA,S,1
CM,FOIL,NODE
CM,FOIL_E,ELEM
IC,FOIL,ALL,300
ALLSEL

!----------------------------
!RADIATION EFFECTS
!----------------------------

ET,2,SURF152 !CREATE SURFACE ELEMENT FOR RADIATION TO AMBIENT
KEYOPT,2,5,1 !KEYOPT TO HAVE ONE EXTRA NODE (SPACE NODE)
KEYOPT,2,9,1 !KEYOPT TO USE DEFAULT (1) FORM FACTOR
R,2,1,5.67E-8 !REAL CONSTANTS FOR ET 2
ESURF !APPLY SURF152 TO SELECTED AREAS OF SHELL131
N,5000,1000,1000,1000 !CREATE AN EXTRA NODE FAR AWAY
NSEL,S,NODE,,5000,5000 !SELECT NODE
ESURF,5000 !CREATE SURFACE ELEMENTS FOR EXTRA NODE
D,5000,TEMP,300 !SET TEMPERATURE OF EXTRA NODE



(I attach a macro file to this post too, incase that is easier).

I keep getting the error "The active element type cannot use and extra node. The ESURF command is ignored".

I have searched for a solution to this for a long time - do you know what the problem may be?

In many ANSYS documents regarding this subject it says "simply overlay the surface effect elements" - this hasn't been this simple for me - I think this is where I'm going wrong?

Is this all that is required for radiation to ambient then? This is quite surprising to me - my last efforts (looking at surface-surface radiation) seemed more intuitive to me (using the radiosity solver) - maybe I'm missing something?

And ideally I'd like to have radiation from both sides of my thin plate - but from extra reading it seems this is only possible on one side if using a shell? Is there anyway to get around this (like reversing normals?)?

Thanks again for any help/advice you are able to give - it really is very much appreciated.

HVSmith




PS,
I was unable to open the .wbpz file attached to your post in the other thread.

 

[flash3780]

Why do you issue ESURF twice? I think you want to delete the first one. If you're working in APDL you should be able to see the elements when they're created (esel,s,ename,,surf152) just to make sure that it was done correctly. I'd step through the commands one-by-one so you can confirm that they're doing what you think that they should do.

I'm also not seeing where you're selecting the nodes that you'd like to apply the surface effect elements to... or your emissivity. I'd think that you'd want that last part to look something like this:

!----------------------------
!RADIATION EFFECTS
!----------------------------

ET,     2,SURF152   !CREATE SURFACE ELEMENT FOR RADIATION TO AMBIENT
MP,EMIS,2,0.15      !SET EMISSIVITY 
KEYOPT, 2,5,1       !KEYOPT TO HAVE ONE EXTRA NODE (SPACE NODE)
KEYOPT, 2,9,1       !KEYOPT TO USE DEFAULT (1) FORM FACTOR
R,      2,1,5.67E-8 !REAL CONSTANTS FOR ET 2

N,5000,1000,1000,1000   !CREATE AN EXTRA NODE FAR AWAY

NSEL, S,NODE,,5000,5000 !SELECT NODE
CMSEL,A,FOIL            !SELECT DESIRED SURFACE (NODES)

TYPE,2                  !SET ELEMENT TYPE
REAL,2                  !SET REAL CONSTANT SET
MAT, 2                  !SET MATERIAL

ESURF,5000              !CREATE SURF152's ATTACHED TO SPACE NODE (5000)
D,5000,TEMP,300         !SET TEMPERATURE OF EXTRA NODE

Warning: I didn't test any of the above code; no substitutions, exchanges or refunds.

 

[HVSmith]

OK, so I was misunderstood...I was calling ESURF twice as I thought I was initially creating the surf152 on top of the shell131 I had and then later on the extra node I created.

This has now been corrected in the code.

With only the latter ESURF command I see that it is indeed creating the extra element. However, this then throws up errors such as:

*** ERROR *** CP = 33.828 TIME= 16:04:22
Radiation element 401 has zero or negative absolute temperature. The
offset temperature (TOFFST) and/or the uniform temperature (TUNIF)
must be positive.

The same message is also displayed about radiation element 421.
This is odd. I'm not really sure what the problem is? I thought I had already defined initial temperatures and the temperature of the space node...

None the less, I tried to fix this with

ESEL,ALL
IC,ALL,TEMP,300

after giving the ESURF command and setting the temperature of the space node, but this still doesn't help - I then get errors of "The value of TEMP at node 261 is 90168629.7 which is greater than the current limit of 1000000. This generally indicates rigid body motion as a result of an unconstrained model. Verify that your model is properly constrained."

I'm working in Kelvin, so the temperature offset is not required, as far as I am aware.

So something is going very wrong somewhere...

Is the problem obvious/trivial?
Do I actively have to allow radiation in /SOLU or is this implicit from the creation of surf152's?

Thanks again for any help, it's very much appreciated, this is definitely a steep learning curve for me...

HVSmith

 

[flash3780]

Apart from the radiation, what are your other boundary conditions?

 

[flash3780]

Make sure your model runs and gives the expected results before applying radiation.

 

[HVSmith]

Um, as in what other constraints I've put on the model?

I apply pulsed heating and then cool by radiation.
There is conduction in the plane.
I set an initial condition of 300K for everything.

(The pulsed heating is described by a Gaussian function).

Is this what you mean by boundary conditions? Or should I be applying other constraints since this is a radiation dominated cooling effect?

Thanks
HVSmith

PS, macro file attached in case what I've said isn't clear

 

[HVSmith]

Yes, without radiation the heat just continues to increase, as I think I would expect.

I've tried implementing radiation from both sides of the plate before in many ways, using RDSF seems to work, but I can't help but feeling it's not true, since there is no other surface to radiate towards. But the results are roughly similar to a numerical solution I have.

Hopefully I'll be able get this SURF152 working and it should be a more accurate representation and closer match to the numerical model.

 

[flash3780]

I'd test the script on a well-posed steady-state problem before moving on to a transient problem... fewer things to go wrong there. Also, perhaps a TOFFST,0 wouldn't hurt anything. The radiation end of things seems correct.

I apologize, I'm not able to run your script at the moment because I've got a few things in the cue. I am a bit suspicious of the volumetric heat input...

 

[HVSmith]

OK, simple mistake on my part I'm afraid. I was counting elements (required for my Gaussian do-loop) after creating the SURF152, but this needs to be done before, otherwise temperatures go hay-wire.

I've included a TOFFST,0 as you suggested, for completeness, it can't harm as you say.

The volumetric heat input was calculated at the very beginning of the project. I've been through it again since you remarked upon it and all the numbers seem fine to me and give reasonable temperature results (at least in the expected ball-park).

However, the results obtained using SURF152 are somewhat different to those when I use the radiosity solver method to apply RSURF's to either or both sides of my shell element, results summarised as follows:

SURF152:
Time 0.9805s, Temp 2597K
Time 1s, Temp 771K

RDSF (2 sides):
Time 0.9805s, Temp 2490K
Time 1s, Temp 613K

RDSF (1 side):
Time 0.9805s, Temp 2618K
Time 1s, Temp 785K


All of these numbers are in the right ball-park (I have a separate numerical solver that I'm benchmarking against which has T~2350K at 0.9805s and T~800K at 1s).

I'm still confused as to which method (RDSF or SURF152) to actually use.

I also need to convince myself that the SURF152 is actually working correctly. Do you have to do anything to "call" the radiation into action, or is it just going to happen given the prescence of the SURF152?

The numerical analysis I have assumes heat radiating from both sides - from what I understand SURF152 can only be applied to one load-key of a shell, is this correct? I've tried moving the space-node around (+/- in the z direction) seeing if this makes any difference but as far as I can see it does not. Do you have any suggestion for a way to implement radiation from both sides via the SURF152 route, or similar?

Thanks again for your help - really useful to get feedback from folks on this

HVSmith
PS, most current macro attached if required

 

[HVSmith]

Hi - again!

I tried to check that the SURF152 radiation implementation was working by doing a test without any radiation defined at all, and, as expected the temperature just continued to rise.

However, I am still struggling to decide why the results of the SURF152 and Radiosity Solver method are inconsistent. I attach some .jpeg images of the final results so you can see. My gut instinct says that SURF152 is the way forward.

I've also still been struggling to find a way to implement SURF15s on both sides of my 3D shell - do you happen to know if there are any work-arounds for this?

Thanks again for your recommendations/suggestions
HVSmith

 

[HVSmith]

OK, so I failed to upload all image files...here goes again...

 

[HVSmith]

And again...

Thanks once again for any insight you can lend!

 

[flash3780]

It's not surprising that the two different (numerical) radiation solvers end up with slightly different results. You might try tightening your convergence criteria to match the two results more closely.

I'd imagine that your SURF152s will solve much faster, since the Radiosity solver is trying to calculate view factors.

To complicate things further, there is a third radiation solver, the AUX12 radiation matrix method (which is supposed to be more accurate than the Radiosity solver, though more computationally expensive). I think that SURF152 elements are probably most appropriate for your problem as well, since you're only radiating to space.

I believe the RADOPT command adjusts the convergence criteria for the Radiosity solver, whereas (I think) the CNVTOL command sets the convergence tolerance for SURF152 elements.

Also... a quick tip: When comparing results it's a good idea to match scales to get a better idea of what's going on.

 

[HVSmith]

Thanks for your comments, it's been really helpful to get your take on things. I will certainly look into matching the scales.

Are you able to add any comment/suggestion as to how I can extend the SURF152 elements to look at radiation from both load-keys of the underlying 3D shell?

From what I've read they can only be applied to one load-key, but in reality radiation will occur from both, so is there a way to model this? Or is it a limitation that I should just be aware of?

Thanks again
HVSmith