I have this 2013 CII file with around 86 lines in it (and one 130' tall digester). I have been going through adding line numbers and cleaning up some support/nozzle modeling issues. All of a sudden, when I run error checking I have 7 error 44E errors (Intersection Coordinate Mismatch exceeds allowable). Six of these are reported with the same Y (vertical) mismatch of about 12.5inches.

I went back and looked where I made changes and the changes all seem valid (meaning the coordinates in CII match those in the original model).

Is there a standard procedure to track these errors down? Tomorrow I plan on adding in only the lines with the vertical Y errors and look for the bad dimension/connection.

By the way, the "Connect Geometry through CNodes" is set to true. Is this a bad practice? Does the value of this toggle affect Flexible Nozzles with Complete vessel Model systems?

This is indeed a hard problem to track down. The issue could be with one or more elements, but from what you describe I suspect an issue with only one element.

To save time I suggest the following:

1) make a copy of the current job, with the error.
2) using the "File/Open" dialog, at the lower right corner you can open earlier editions of the job, from the \backup directory. The job names have been changed to include the time-date stamp of the last "save" operation. (There are only 25 revisions here.)
3) Pick one of these, perhaps the 5th one down. Open it, see what's there and what's not, then error check it. (Note, error checking will put that current model over in the \backup directory, so you want to be careful doing this.

Your goal is to find the most complete model without the geometry mismatch. Once you find that, error check every two or three elements until you discover how the problem occurred.

Rich,

I tried looking at backup files before I posted and almost lost everything so I'm reluctant to take that approach now.

Question, what are the coordinates reported in the coordinates table based on? When I created the *.cii file I had all of the branch head positions as coordinates (like 150 of them). Apparently, CII strips these out as it finds that the lines are connected and then gets rid of the over specified coordinates. Is this what is happening? Now I only have one global coordinate (and its in the middle of the model). It is correct though.

What is the significance of the "node pair" reported in the "Intersection COORDINATE MISMATCH"? For instance the first one cites nodes 4270 TO 13225. These nodes are not connected directly although 4270 is a restraint with a cnode that has 13255 on the other end of a rigid, no weight element.

Also, sometimes the error report list the nodes of an element in a forward mode (from to) and then other times it lists them in a backward mode (to from), Is there any significance to this.

My intent in these questions is to try to understand the reporting to see if it can help me figure out where to look for the dimension bust.

I'll start by looking at the first reported error pair.

Thanks for you reply.

PS I have posted this to support.

Is there a way to see everywhere a node number is used? Be it a "From-To", CNode, Restraint, SIF, Bend Angle, etc.

Disconnected Cnodes one at the time till I found the problem. Problem resolved.

And now you know why this is such a hard problem to offer advice on. As to the coordinates you mentioned (specified in your CII file), these are indeed ignored if the system is all connected. Typically you would only need one coordinate, the location of the starting node in the model. Everything else can be located from there, based on the delta dimensions you enter.

Typically this problem is caused when closed loops are formed, and one (or more) elements have incorrect delta dimensions. There is no way for the software to know which element(s) is (are) incorrect. An improper connection with a CNODE will cause the same problem.

As to the backup revisions, it is wise to make a copy before you start the recovery process. As I stated earlier, each "save" generates a new backup, and deletes the 25th oldest copy. Also note that the Error Check process performs a "save" first.


I'm glad you resolved the issue.