Good day!

I have encountered a problem while running static analysis. The problem is that the analysis sometimes converge and sometimes does not (using the same model).
---The situation is that I have this 54" size Flare Line pipe and when I tried to run this in static analysis it does not converge so I change the "friction stiffness normal default value" in the configuration setup to its "lowest default value" then the analysis converge. But, when I try again the "friction stiffness normal default value" (using the same model) it will now converge. Why is this so? Please explain to me regarding this problem. Thank you.

Best Regards,
Ian

I can't give a specific reason as to why a specific change might allow a job to converge. In a nut-shell, here is what is going on:

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.

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.

One more thing I forgot to mention. If you change a configuration directive that will affect the numeric computations or results, you must go back to input and pass through error checking for the changes to get into the job. Simply rerunning the job from the Static Analysis menu won't incorporate the changes.

The program works this way so that computational changes don't (magically) affect all the jobs in the directory.

"The program works this way so that computational changes don't (magically) affect all the jobs in the directory."

Which is why I'd love to see a separate config file for each model.....

-I see it is necessary to pass through error checking if their is changes done in the configuration setup. Thank you Mr.Richard.
-Mr. Itchy you said that each configuration file need to be separated for each model, does CAESAR II recognize the last configuration file we use (on a certain model) or the latest configuration file used (from another model)? Thank you.

Regards,
Ian

Hi Ian

If you change any settings on your configuration file for your current model, then every other ._A file that is saved in the same directory will now read this configuration file which you have now changed.

We keep all our different models in separate directorys to prevent overwriting the config files.

Once a project is underway, I hope users aren't changing configuration files from one job to the next. I believe the configuration settings should be consistent throughout a project. With that approach, all jobs in a project can be held in that same folder with a single - reviewed and approved - configuration file.

That said, if I wish to "test" some setting, I move the job into another folder with the modified configuration so as not to affect the project settings. When moving jobs, you may want to take along the existing configuration settings. They are held in the file CAESAR.CFG.

If users share a folder, they better agree on the configuraton before work begins. And watch out if you are running in a shared environment such as a network. You may want to make CAESAR.CFG a read only file.

No matter what you do, you can always see the settings that were used in the analysis in the existing output. Click on Input Echo, clear the check boxes, then click on Setup File, then OK.

Finally, when archiving your work, include that CAESAR.CFG file...

Continuing the idea of an "approved - project wide" configuration file, this is why an administrator can set a password on the master configuration file in the program directory. Then, unless you know this password, users can not make changes to configuration directives that affect the numeric results.