| Author | Message | |||
     Steven E. Williamson (sew) Member Username: sew Post Number: 5 Registered: 02-2008 |
I have been attempting to do static thermal calculations with temperature dependant contact resistance (see my earlier post). I would like to be able to define the contact resistance by way of an interpolated table. BUT the syntax of the CONTACT boundary condition requires that this be a FUNCTION of temperature. A table is not a function. BUT there is a trick which I found in the archives of this "User's forum" at this post. Basically, the idea is to use the EVAL function, which normally wants to be evaluated at coordinates (i.e. X, Y, and Z), to instead define a function that can be evaluated with some other variable (say: q). The script then looks like: DEFINITIONS ... rb_true = TABLE('bolted-copper-apiezon-N-copper-thermal-resistance-small-temp.txt',x) ... BOUNDARIES ... CONTACT(temp) = -JUMP(temp)/EVAL(rb_true,(-JUMP(temp)/2+temp),0) ... Note that, as Robert Nelson points out in the post above, you CAN NOT define a function using the EVAL function to simplify the contact boundary condition. In other words the following does not work: DEFINITIONS ... rb_true = TABLE('bolted-copper-apiezon-N-copper-thermal-resistance-small-temp.txt',x) rb(q) = EVAL(rb_true,q,0) ... BOUNDARIES ... CONTACT(temp) = -JUMP(temp)/rb(-JUMP(temp)/2+temp) ... Now here's the problem: My spacial units are defined in MKS units but my geometry is pretty small -- a centimeter or so. So no coordinate gets larger than about 0.01 m. Temperatures, on the other hand are in the range of 0.3 to 0.5 K. It appears that EVAL does some kind of check of it's argument, and if the argument is outside the limit of the spacial dimensions, a value of zero is used instead. Because all temperatures are larger than the dimensions in meters, zero is always used, and the TABLE interpolation just returns the value of the table at the minimum of the range of data. At least that is my picture of what is going on. To get around this, I changed my table file so that the independent variable (temperature) is divided by 1E5. I need to divide every temperature that is used as an argument to the EVAL function by this same factor of 1E5. So the code above becomes: DEFINITIONS ... rb_true = TABLE('bolted-copper-apiezon-N-copper-thermal-resistance-small-temp.txt',x) ... BOUNDARIES ... CONTACT(temp) = -JUMP(temp)/EVAL(rb_true,((-JUMP(temp)/2+temp))/1E5,0) ... When I do this, everything works fine. But these work-arounds on top of other work-arounds are starting to get kind of ugly. It would be nice if (in version 6??) there could be a way to define a function of an arbitrary argument in terms of interpolation of a table of data. | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1072 Registered: 06-2003 |
There are two items at issue here. One is general usage of FlexPDE, and the other is the special treatment of "JUMP". 1. FlexPDE can utilize data presented as TABLEs, with any value as the table coordinate. TABLEs are NOT restricted to spatial coordinates. You have specifically told FlexPDE that your TABLE depends on the "x" spatial coordinate, and this is where much of your trouble arose. Ignoring for a moment the special restrictions on JUMP, the canonical use of the TABLE would be: ------------------------------------------- DEFINITIONS Q = some expression involving variables, spatial coordinates, etc. rb_true = TABLE('file',Q) ... CONTACT(Temp) = -JUMP(Temp)/rb_true ------------------------------------------ In this construction, when FlexPDE needs to process the CONTACT BC, a) it will attempt to evaluate rb_true at the coordinates of each evaluation point. b) It will discover rb_true to be a TABLE that depends on "Q", so it will evaluate Q at the current evaluation point. c) Having evaluated Q, it will use this value to interpolate in the table and return the value of rb_true at the current evaluation point. So no contortions are necessary to use tabular functions of arbitrary arguments. 2. In your particular formalism, we run into a constraint placed on the JUMP function. JUMP is meaningless except on a CONTACT boundary, so there is a diagnostic that prevents its use in illegal ways. This diagnostic appears to be over-zealous, in that it blocks its use in the definition of Q above (since at the definition point, it is not clear that Q will be used only in CONTACT statements). Ultimately, your difficulty arises solely from your desire to compute the mean value of a variable at a discontinuity. There are a few modifications we might make to FlexPDE to allow this usage: a) we could add an averaging function analogous to JUMP, that would treat discontinuities. But this is a rather special-use provision, and I don't know how general the applicability would be. b) We could relax the restrictions on JUMP, and take a "caveat emptor" approach to its use. I will try some experiments with 2b, and see what can be done. | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1073 Registered: 06-2003 |
I have removed the diagnostic that prevents mention of JUMP outside CONTACT boundary conditions. A development version of FlexPDE for windows 32-bit platforms that contains this fix can be downloaded from www.pdesolutions.com/download/xfpde5021x4win.exe This change does NOT make it possible to actually compute a JUMP outside of CONTACT boundary condition. But it makes it possible to define parameters using JUMP. It is the user's responsibility to see that these parameters are only referenced inside a CONTACT boundary condition. Attempts to compute a JUMP outside of a CONTACT boundary condition will result in a diagnostic "Cannot find JUMP neighbor". | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1074 Registered: 06-2003 |
Here is a modification of your file that uses the JUMP function in a table coordinate.
|
