Dear Sir,

i have modelled some piping isometrics with lot branches coming out, in caesar ii in a same file ... i mean a complete one model.....but when i analyze it, it tooks even one hour for analyzing and still continues to find solution...... then i stopped my pc to work.... please tell me how can i reduce analyzing/calculation time in caesar ii.....

Remember i run the static analysis...

Thanks

Are you looking at the analysis screen for that hour? Does it show a counter for the number of interations that have been completed? Is that number huge? If so, you have several nonlinear support conditions in your model that the program cannot resolve. Jobs either converge in short order or they get caught in a loop and repeat the "guesses" until you turn off your machine. I suggest you search this forum for convergence discussions to learn more.

Or maybe you just have a very slow machine.

Friction is often the enemy of reasonable analysis.

Even when I was running CII 3.24 back on a Pentium 90MHz machine, a big model might take a couple of minutes.

If your machine is crunching for a hour w/o a solution, I would agree there is a coding problem.

I'd say "convergence" not necessarily coding :-)

Depending on the model, if the area that isn't
converging isn't of particular interest
(eg connecting piping etc), I typically will
use Y instead of +Y supports in the area,
or remove gaps... basically reducing degrees
of freedom in the model. It is also possible
to play with friction parameters, which I'm
sure a search for convergence will bring
up lots of info

-SLH

Bajwa,

Did you say your computer stopped working...after an hour of iteration... but are you saying that when it stop did it really give you a solution? - meaning it would give you an output supposedly. Or it stops and did nothing at all after that? I have experienced sometimes on very big models as far as 96 load cases (max for CII) where analyzing really takes sometimes specially if the gaps have a lot of variations, friction values are high. There is a way to minimize time on that case. However, what you are saying as an hour is long enough that maybe Dave is right that your computer could be too slow. However again, please note that at one time I ws using an Intel Celeron processor on 400 MHZ and still I have not experienced that long on pretty big models. Can you check how many iterations did CII have after it has converged successfully?

Some advice:

See how much time it takes to solve one iteration. Is this 2 seconds, 2 minutes, or 20 minutes. Based on this, you can then figure the same amount of time for each iteration.

Now, if the job is linear, you only have one iteration per load case, so you can estimate the time for the entire run. If the job is non-linear then you don't know how many iterations may be required for any particular load case.

What you want to do in this case is watch the iteration counter in conjunction with the counter for the number of non-converged restraints last iteration. As long as the number of non-converged restraints is decreasing (within a load case), then everything is fine, regardless of how long things take. It is only when the count of non-converged restraints stops decreasing, or bounces around (up, down, up, down, etc) that you have a convergence problem. Once you determine you have a convergence problem, you should find out why, kill the job, and make adjustments.

In making adjustments, 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. Details of what this report contains can be found below.

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.


Interpreting the information from the [F2] key:

Old State - New State: This indicates the status of two successive iterations. The old state is iteration "x", while the new state is iteration "x+1".

Open - Closed: This indicates the status of a directional or gapped restraint. Open means the pipe is not on the restraint, while closed means the pipe is contacting the restraint.

Direction X, Y, Z: These values define the direction cosine of the restraint.

Sliding - Not Sliding: For jobs with friction this indicates whether or not the load was sufficient to cause sliding. Details on this can be found in the "friction discussion" in the Technical Reference Manual.

Error: This value indicates the percent change in the normal force between iterations. A value of 0.5 indicates that the normal force changed by 50%, which means the friction force changed by 50%.

I hope this helps.

Thanks Richard for the explanation, by the way what is the usage of F4 key in the menu? I pressed, but no action

[F4] should print the restraint status (of all non-converged restraints) for that specific iteration.

In testing this just now, I just get a blank page. I don't know when this broke, it has been a very long time since I pressed that button ...

Well nothing is broken. The [F4] key does print the status of the restraints from iteration to iteration. [F4] doesn't do anything if [F2] has been pressed, because that pauses everything (it has been a while since I've attempted to print the iteration status). So, if you have pressed [F2], press it again to toggle it off, then press [F4].