One problem we commonly face is non-convergence. CAESAR cycles between 2-10 "solutions" that fail to agree.

The current work practice is the user makes a note of what the problem is and where among one or multiple of these "solutions."

I would propose that CAESAR dumps this information into (yet another?) file that the pre-processor can read and provide at least cursory information visually in some form.

Node numbers a different color... A different arrow at the restraint...

Thanks for taking the time to read.

Would be great to have it as an additional tool increasing productivity.
Thanks, Michael- for the proposal.

I do agree.
Another option could be to be able to export the content of the list box
of the incore solver in a simple text file.
I guess this would be quite easy to get and would be a time-saving feature.

Corrado Vannella

There are various reasons a model may not converge. When that happens you have to apply Engineering judgement as to why this is happening and what a possible modification might be. The program will not arbitrarily change your model behind your back.

Here is a presentation we did on convergence for our CAU-Express a couple of years ago:

Richard,

Thanks for the info.

Apologies if I was unclear: The suggestion is only for a graphical display of that same information that's shuttled away only within the processor.

I guess nobody thought about a tool to solve the non-convergence but one to suggest visually a little bit more comfortable the possible reasons, as Michael suggested.

Just because the discussion entered in details, which is the reason Autopipe hasn't usually non-convergence problems? I know very well this not means necessary accuracy or convergence to the "right" status, however also their results seem to be reasonable and anyway reasonable closed to Caesar. Is something in Fortran routines unattached from the beginning?

the intention was to say "untouched", unchanged from the time when the routine has been written.... In fact is Caesar written using SAP IV engine?

No SAP-IV.

Hello, everyone.

I wanted to chime in to this conversation to say that we have, in fact, discussed options to help with non-convergence in the past, and we are very interested and appreciate your suggestions. We will discuss some of the above suggestions with our development experts.

As Richard indicates, what we want to maintain is your ability to apply your engineering knowledge and judgement when making decisions on non-convergence issues, rather than having the software automatically alter models without any reporting coming back to you (i.e., your model changed somewhere, you have no idea now, but now it magically converges? Sounds a bit scary to me!)

In addition to the great suggestions made, some future possibilities might be some sort of a wizard or a prompt that comes up that gives you common options/tips that help fix convergence issues. You could then go try those options to see if it remedies the problem.

MOST OF ALL, I think it would be important to then have a report or some indication on your output reports where things were changed to fix convergence issues--even if it is a log file of some sort that you can go back and look at to see what was changed. Or, as Michael suggests, something visual on the model to show where changes were made.

Does this match with some of what you are hoping for with these suggestions?

Disclaimer--this is not currently in development or planned for our product yet, but your feedback is key in us understanding what users need and would appreciate most in the future.

Technically speaking, solving convergence issues can be pretty complex and unique to each model/job, so that is what makes this request pretty challenging to solve. However, we are listening and discussing, so keep the feedback coming.

Stephanie Corken

CAESAR II Product Owner
Hexagon PPM (CAS)
stephanie.corken@hexagon.com

Stephanie,

I believe we're all on the same page. I would also be concerned about CAESAR making decisions for us unbeknownst to the user (even if shuttled away in a log that we'll eventually get complacent about reading).

I think we both agree (for the foreseeable future) the user needs to conclude the underlying reasons for the convergence problem and not the software.

Whether a "wizard" can verbosely offer some guidance, or an "assistant" visually depicts the regions of the model causing convergence issues, in both cases we're only helping the user arrive to their own conclusion how they can best fix the convergence problem.

To work, though, CAESAR needs "give up" conditions in order to end-loop the processor. This in of itself should also be helpful towards solving convergence issues.

I say this because currently, I remove non-converging load cases and fix the stresses in the convergent load cases. By doing so, the previously non-convergent load cases often come closer to convergence.