| Author | Message | |||
     Steven E. Williamson (sew) Member Username: sew Post Number: 11 Registered: 02-2008 |
I have run into a problem with CONTACT boundary conditions. The symptom is the cryptic error message: "NONSYMMETRIC MAP". The trace-back is as follows: NONSYMMETRIC MAP An internal processing error has occurred. Please contact PDE Solutions Inc. ---Called from sparsemx::inchol_factor ---Called from coupling::build_precon ---Called from cgsolve::do_linear ---Called from control::do_runjob ---Called from ccontrol::runphase To find where this error was coming from I pared down my much larger script and eventually isolated the problem to a pair of CONTACT boundary conditions specified on SURFACES in a limited region. Commenting out one or the other (or both) SURFACE boundary condition allows the problem to run. But with both conditions in place, the problem fails. I have attached the "pared-down" script that produces the error. The geometry consists of a rectangular region of material 1, which is overlaid by a smaller rectangular region of material 2 centered in the first region. Both regions have the same length in X. Originally, I had placed both surface and side wall CONTACT boundary conditions in the second region definition so that there was a boundary resistance for the entire interface between the two materials. I eliminated the side wall boundary conditions while trying to zero in on where the error was coming from. I realize that the remaining geometry is not particularly physically realistic. Am I doing something wrong with this geometry, or is this a bug?
| |||
| Steven E. Williamson (sew) Member Username: sew Post Number: 13 Registered: 02-2008 |
I noticed that in another post, refining the mesh eliminated a NONSYMMETRIC MAP error in a problem with contact boundary conditions (though the geometry was quite different I think). I tried setting "MESH_SPACING = 0.05" and indeed, the problem ran with no error. So I have a work-around -- but I would like to understand what happened to cause the error in the first place. | |||
| Steven E. Williamson (sew) Member Username: sew Post Number: 14 Registered: 02-2008 |
I added back the contact boundary conditions on the side walls of the central region in my example, and now, with one such side wall condition I am again getting NONSYMMETRIC MAP errors. With both side wall conditions, I get a Memory Protection Fault with the following trace-back: 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 So I take it back. I do NOT have a work-around. I have played with the mesh spacing but making it smaller seems not to help. This is getting frustrating. I have attached a modified version of the script with the side-wall boundary conditions. (Note that I included a LAYER qualifier on each to be sure that I did not have the problem mentioned in my earlier thread).
| |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1084 Registered: 06-2003 |
This error occurs in the Incomplete Choleski factoring procedure, because the Contact boundary condition processing is not building a symmetric storage structure for the matrix. We have corrected this problem, and the correction will be in the next maintenance release. In the meantime, you can SELECT ICCG=OFF and the solution should proceed. | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1085 Registered: 06-2003 |
PS Boundary condition specifications continue in force across subsequent path elements until explicitly changed. This means your sidewall CONTACT condition continues across the exterior wall, which encounters the problem discussed in your earlier post, that CONTACT BCs cannot be applied to exterior boundaries. You will need to break the CONTACT specifications when tracing the exterior boundaries by inserting a NATURAL(temp)=0 or NOBC(temp) in the path sequence. See attached.
| |||
| Steven E. Williamson (sew) Member Username: sew Post Number: 15 Registered: 02-2008 |
Setting ICCG = OFF did indeed remove the non-symmetric map error. And I certainly agree with the necessity of those extra natural side-wall boundary conditions -- I had them in some of my trials, but somehow managed to delete them at some point in my efforts to figure out what was causing the problem. But I have another problem. I have attached a script which, it seems to me, should produce the same geometry as the previous test case (e.g. the attachment in your last post). I have broken up the original (non-limited) region into two regions, one non-limited and one limited. I still define the central region bounded by CONTACT boundary conditions in yet another limited region. When this script is run, the side-wall boundary conditions of the last region seem to be ignored. What is more strange (to me) is that if I reverse the order of definition of the last two limited regions, then the region with the CONTACT boundary conditions is totally ignored leaving a hole! For this geometry, the original method of defining the regions is obviously simpler, but I'm trying to understand the intricacies of how the region definitions work. I don't understand why the attached script doesn't work just as well as the simpler 2-region version.
| |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1088 Registered: 06-2003 |
A REGION (whether "limited" or not) describes a 2D figure in the (X,Y) projection plane. REGIONS declared later hide any REGIONS declared earlier if they overlay them. If a REGION is declared twice with the same boundaries, the earlier is hidden by the later one. Your regions 2 and 3 are the same, and should be declared only once, with parameters declared for each layer. Each extrusion surface is gridded as a 2D mesh problem, following the region overlay rules for all regions that exist in the surface (as controlled by "Limited" qualifiers). In any surface in which both of your regions 2 and 3 regions exist, the earlier declaration is overlayed and hidden by the later. This is the actual cause of your disappearing boundary conditions. You also have the same trouble as discussed in another thread, namely that declaring a contact boundary condition where an Natural has already been declared will cause loss of the contact condition. See attached.
|
