Dear all,

It’s my 1st time in your discussion forum. It’s truly amazing the huge amount of topics you have covered here. Reading those topics by itself can such a great training course!

I have been going thru the topics for the past couple of hours looking for one that explains the terms that is shown in the “Incore Solver” when you press F2 “Single Step Thru Restraints”. I mean the terms that explains the status of the non-converging restraints. For example you would see something like this

Node: 10 DIR: 0.000 -1.000 0.000
OLD STATE OPEN NEG NOT SLIDING
NEW STATE CLOSED POS SLIDING ERR=***

What is the meaning of each term shown in my example? I might be missing some term, if you know other ones please include them in your explanation?

I have some basic knowledge on how to solve non-convergence problems based on the information you can get from pressing F2 at the Incore Solver, but it’s not enough in solving all the convergence problems that I face. Would anyone please provide me with a guideline on how to solve the different types of convergence problems (due to the different causes) using the information obtained from F2 function?

Node: 10 DIR: 0.000 -1.000 0.000
This is information for the restraint at "Node 10". The "DIR" provides the direction cosine of the restraint. So "0, -1, 0" indicates some type of "Y" restraint.

OLD STATE OPEN NEG NOT SLIDING
This line provides the status of the restraint for the previous iteration. Here it means the restraint was "open", "not sliding", with a load in the "negative" direction.

NEW STATE CLOSED POS SLIDING ERR=***
This line provides the status of the restraint for the current (new) iteration. Here is means the restraint "closed the gap", "started sliding", with a "positive load". The "ERR=" is the percent difference in the "normal force" between the two iterations. Asterisks mean that the number was too large to print in the space we allocated. (Which means it really exceeded normal tolerances, and this is why this restraint didn't converge.

Thanks alot Mr. Richard for the informative reply!

But i still don't get what you mean by "normal force". Do you mean the vertical force caused by the weight components (sustained loads)? Why would the normal force change between the different iterations?

My 2nd half of the inquiry was about how to use the information obtained from the status of the non-converging nodes in solving convergence problems. I would appreciate it alot if you shed some light on that issue.

Hi Ahmad,

The program solves a set of equations which if expressed in Matrix Form is:

[P]= [K][D].

Symbols have their usual meaning.

In case of non linear supports ( like one way acting or supports with friction), the stiffness matrix [K] changes between the load cases. Also within a load case the "final stiffness matrix" is arrived after a series of iterations.
Normal force is perpendicular to pipe axis.

Let us take the case of friction.

First the program uses srings to model the frictional resistance. These springs have stiffness values equal to the "friction stiffness value" selected in the .cfg file.The displacement at the point is computed with the spring stiffnesses in position and KD is computed i.e. stiffness times displacement. If this value is less than friction coefficient times normal force, the springs remain ( this is " non sliding" case ),else , if they are higher, the springs are replaced by force ( now added to the load vector) equal to friction coefficient times normal force ( this is "sliding" case). The program then runs :

[P]= [K] [D] again with the new boundary conditions ( considering the fact that it has slided now) . Hence the normal force has to change as you are solving a "different"set of equations now.

Remember , if the restraint slides, the friction force you get to see are the vector components of the resultant force "mu times N" in the two orthogonal directions.

Also remember use of frictional non linearity can result in violation of "nodal" and "elemental" equilibrium.This is a fact one of my colleague discovered recently.

I hope I have answered your question.

Regards

Because a +Y lifted off, or perhaps sat down. Each iteration is independent.

1) The system parameters are used to define the global stiffness matrix [K] and load vector {f}. This defines the system of equations [K]{x} = {f}.

2) In a system with non-linear boundary conditions, each load case must undergo an iteration process. In this process, the above system of equations is solved for {x}. Then, at each non-linear boundary condition, the status is checked. If the boundary condition changed (a +Y lifted off, a gap opened or closed, etc), then that DOF in the stiffness matrix [K] is altered. When all changes to [K] have been made, the next iteration for that load case begins. This process is repeated until all boundary conditions are within the convergence tolerances.

3) The only convergence tolerances users can control are for friction and large rotation rods. Items like +Y supports, gaps, and soil restraints are either on-off, or yielded-nonyielded.

4) CAESAR II doesn't have an iteration limit. If the job doesn't converge, we don't give an answer. We feel no answer is better than a wrong answer.


If during the solution, you click the [F2] key, CAESAR II will give you a list of the restraints that are not converged at that time. Changing characteristics of any of these restraints may allow the job to converge. Details of what this report contains are discussed in my post above.

For jobs with friction, please read the section on friction in the Technical Reference Manual. Additionally, the magnitude of the "coefficient of friction" can be changed globally for all restraints using the "load case options" tab of the static load case editor.

I can not say how any one specific boundary condition change will affect the system of equations in [K], and the subsequent matrix decomposition. When you encounter this behavior, all you can do is play with the system, using the list of non-converged restraints as a guide.

Mr. Richard and Mr. Anindya, thanks a lot for the time you took in preparing and typing your reply!

I got what I came for from this forum. Although I was looking for a quick-fix or a written doctrine on how to solve convergence problems  But I realized from reading your reply and other topics in the forum that you can only know the general thing that is causing your non-convergence issue and from there you’re on your own of discovering the right way (or may be one of the right ways) in solving your problem thru common sense, logic, trial and error, educated guesses and –many times- by pure luck 

One last thing before I close this topic, I was hoping that the developers of CII would take my suggestion on evolving the F2 function to display the non-converging nodes and their status in layman’s terms. And it would be more appreciated if they would also explain what is wrong with those nodes and give suggestions on how to solve them in understandable engineering terms 

Thank you all. Have a good day.