I am trying to do a foundation anaylsis to get a base pressure and when I generate supports using the plate mat command for the subgrade modulus and then later and the spring compression command I keep getting an instability @ a corner joint and it won't finish. I have tried several other ways to assign a different support to the corner but I am not having any success solving the issue. Can anyone help?
Hi,
Can you please attach the .std file?
Here is the latest file....
A fairly common problem with Mat footings is sliding. If the springs only resist vertical deformation, then there is nothing to prevent the mat as a whole from sliding around (or rotating). You will probably need to introduce one or more points of lateral restraint. That’s one of the instabilities addressed in the Structural Wiki here:
RAM Instability In Finite Element Analysis
(full path http://communities.bentley.com/Products/Structural/Structural_Analysis___Design/w/Structural_Analysis_and_Design__Wiki/ram-instability-in-finite-element-analysis-tn.aspx )
Seth correctly addresses the cause of the instability in your model. Here are a few observations pertaining specifically to your model.
1) You have specified the supports as
SUPPORTS
1 TO 1848 PLATE MAT DIRECT YONLY SUBGRADE 51.84
YONLY is interpreted by STAAD as a spring in Y, un-restrained against X and Z translations, and un-restrained against all three rotations.
When every support node is assigned YONLY, the structure does not have any ability to resist a force along global X or global Z. In load cases 1 through 7, there are several instances where forces are applied along X and Z. So, your structure is unstable along FX and FZ, and the situation is exacerbated by loads acting along those directions.
Sometimes, users specify the YONLY type to model a friction-free contact surface at the base of the mat. If that was your intention, additional supports which can resist FX and FZ are required.
But if that is not your intention, change YONLY to "Y". "Y" is treated by the program as
FX is restrained
FY has a spring
FZ is restrained
MX is free
MY is restrained
MZ is free
2) Your primary load cases like 2 (ICE), 3 (LIVE) 4 (WIND), etc., are pure component load cases because they cannot act in isolation from other cases like the DEAD load case. The only load cases whose results are of use in this model are the combination load cases - the ones with the REPEAT LOAD command. Consequently, it makes sense to use the SPRING COMPRESSION command for the combination cases only.
One of the following 2 ways may be used to address this.
a) Ideally, it would have been preferable if cases 1 thru 9 were not solved at all. If you are running a recent version of STAAD, convert them to REFERENCE LOAD cases - a feature which was introduced in STAAD.Pro 2007 Build 01. This will convert them to data that won't be solved until they are referred to later in the combination cases. Refer to section AD.2007-1001.1.12 of the STAAD documentation for details.
b) Move the SPRING COMPRESSION command from its current position to just before load case 10. So, even though cases 1 through 9 will be solved (without SPRING COMPRESSION), you need to simply ignore those results.
The instability problem will be resolved through one of the above.
One other thing. You have 2 sets of moving load generation commands which have been provided after load 24. Since these too are component load cases, it would be best if they too were move up and placed prior to the first combination case. As you are combining each generated case with other primary cases, some reshuffling of data will be required if you follow this suggestion.
Hi Kris can you kindly post a sample syntax of the spring compression support that you moved just after all the component loads. I can't seem to get it right I always get and error when i run my analysis.
thanks