| Author | Message | ||||
     Steven E. Williamson (sew) Member Username: sew Post Number: 7 Registered: 02-2008 |
I have been having a problem with contact boundary conditions. The symptom is a Memory Protection Fault with the following message: Memory Protection Fault --Called from init::init_ss --Called from init::initial_val --Called from control::do_runjob --Called from ccontrol::runphase --Called from ccontrol::control_loop After much whittling down of my original script, I have determined that the error is coming from the definition of a contact boundary condition between two adjacent rectangular regions. What is peculiar is that the error only occurs if the piece of the boundary where the condition is defined is traversed in opposite directions in the two regions. If it is defined by walking in the same direction over that particular boundary segment, then there is no error. Note that if the boundaries are both defined by walking in, say, the clockwise direction, then the common boundary will actually be traversed in opposite directions. I have attached two nearly identical scripts, one which fails and one which runs, to illustrate this problem. Am I doing something wrong here? Or is this a bug?
| ||||
| Steven E. Williamson (sew) Member Username: sew Post Number: 8 Registered: 02-2008 |
The problem isn't so simple. Attached is another pair of scripts (one fails, one runs) with the same shapes and dimensions as the previous pair, but shifted and rotated (about Z). In this orientation, the error occurs when the common boundary is traversed in the SAME direction. I guess the message is: if the Memory Protect Fault error occurs, reverse the direction of definition of one of the boundaries -- but you can't predict ahead of time whether it will fail or not.
| ||||
| Marek Nelson (mgnelson) Moderator Username: mgnelson Post Number: 26 Registered: 07-2007 |
Contact boundary conditions are not meaningful on exterior boundaries. FlexPDE checks for these, but apparently in a order dependent fashion and not always successfully. Your contact boundary condition is applied to all layers by default. In your case it is only present in one layer, 'L-pot'. If you explicitly declare your contact boundary to be in that layer only, then all your examples will work. i.e. LAYER 'L_pot' CONTACT(temp) = -JUMP(temp)/.5 We will have to look into why FlexPDE recognizes this situation (or not) based on the order the region is declared. For now you can just explicitly declare the contact BC to be in the appropriate layer only. | ||||
| Steven E. Williamson (sew) Member Username: sew Post Number: 9 Registered: 02-2008 |
In my examples, the contact boundary condition was specified in a LIMITED REGION, which, I thought, causes the boundary condition to be restricted to only the layers mentioned in the limited region definition (L_pot in my case). Or is this not the way LIMITED REGION works? | ||||
| Steven E. Williamson (sew) Member Username: sew Post Number: 10 Registered: 02-2008 |
As a test, I modified the sample script called 3d_limited_region.pde. I removed the heat source in the little interior box (defined in a LIMITED REGION) and added a VALUE boundary condition on its 3 interior side-walls. That value condition did NOT propigate to the rest of the model. Why then would a CONTACT boundary condition be treated differently? (My modified script is attached.)
| ||||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1083 Registered: 06-2003 |
I agree that it would seem logical to default the BC application to the layers and surfaces named in the LIMITED REGION specification. However, the necessary logic to implement this was apparently not provided when the 'Limited' qualifier handling was first written. We will add this to our development list for a later release. But if you want to make your problem run now, you will have to explicitly control the layer of application of the contact BC. | ||||
| Steven E. Williamson (sew) Member Username: sew Post Number: 12 Registered: 02-2008 |
Thank you for explaining this. I appreciate your patient replies to my questions. | ||||
| Steven E. Williamson (sew) Member Username: sew Post Number: 16 Registered: 02-2008 |
I looked more carefully at Marek Nelson's suggestion that I add a LAYER qualifier to the CONTACT boundary condition. In fact, this does allow the script to run without any errors. BUT when I finally looked at the results of the run, I realized that the CONTACT BC had been totally ignored. In the cases above that ran properly (when the boundary was traversed in the "correct" way, adding a LAYER qualifier also REMOVED the CONTACT boundary condition. I conclude that Marek's analysis is flawed somehow. One must try traversing the boundary in both directions and check carefully the results (even if the script runs without error) to be sure that boundary condition was actually applied. See also comments in this post | ||||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1087 Registered: 06-2003 |
The problem is that you have defined two boundary conditions on the same boundary face. The first definition of the interface line asserts Natural()=0. Later you retrace this boundary and specify a Contact boundary condition. You can't have both, and there should clearly be a diagnostic to reject this collision. We will look into adding the diagnostic in the next maintenance release. In the meantime, there are lots of ways to avoid this difficulty: 1) Our usual advice is that Region 1 trace the entire outer boundary and place external boundary conditions. Then subsequent regions can be overlaid to position other materials, but no new boundary conditions are normally necessary. In your case, the CONTACT will still be specified in an overlay region, but it will be the only definition of a BC for that boundary leg. 2) Similarly, if you always attach layer qualifiers to boundary conditions that are not applied over the entire layer stack, this kind of error will be avoided. For example, if you attach a "Layer 'L_lug_tab'" qualifier to the Natural()=0 in region 1, the error disappears. In fact, since Natural()=0 is the default, you can simply leave it out. |
Fails