I'm working on a model of approx 300 000 nodes and 600 00 elements. The model has been combined from different smaller models using ID offsets to prevent any possible ID conflicts. Now there are elements and nodes with IDs as high as little above 20 Million. While renumbering elements takes about 15 minutes the renumbering of nodes was not finished even as I left it on overnight. Has anyone encountered a similar problem?
PS. Renumbering is crucial because of an API in excel that dimensions a vector based on max node ID and excel cannot dimension an array with 20 Million entities.
To have this model in the pre-renumbering state is critical for improving FEMAP performance, please send the model in the original state to FEMAP developers, they will investigate to see how to improve FEMAP, problems like this will help a lot to increase the FEMAP performance, ok?.
Please send me copy a of the original model (without renumbering) or directly to Mark Sherman (SIEMENS PLM) at the following e-mail address:
sherman dot mark at siemens dot com
Thanks Blas for the quck answer!
I'm afraid I cannot send the model due to confidentiality reasons. While trying to solve this problem I have however noticed the following:
- Selecting even only one (the last) node and trying to renumber causes FEMAP to freeze.
- When exporting the model as *.neu and importing back the error message attached was printed (even if there should not, to my knowldedge, be any entities with ID>99 999 999
- When exporing the model as *.bdf and importing back the renumbering works again (however this is not a real option as so much information is lost in the transfer).
I certainly understand the problem in sending us the model, but obviously without it, it is difficult to know what is actually happening. The message that you provided definitely indicates something somewhere is referencing an ID that is either less than 1, or greater than 99,999,999. There are 2 things I would like you to try...
Honestly, I don't know if either of these will help us track down the problem, but it is somewhere to start.
The rebuild I had already tried and it didnt help. The model info fucntion was a nice way of plotting model entitie numbers an IDs. However it did not reveal any too high or possibly negative id:s.
A corious thing is that exporing a neutral file of a group that contains the whole model solves the problem. However then I end up with a model without groups, layers analysis sets etc. which is not ok either.
Also the renumbering problem only occurs for nodes so probably the problem is related to these.
If you are willing to try a few more things, possibly we can track this down. Your last post reveals some helpful information. When you renumber nodes, it is not only the nodes themselves being renumbered but also references to those nodes on the other entities. Based on your comment that exporting a neutral file with no groups, etc solves the problem .. I suspect the issue may be in references to nodes within one or more of the groups.
In the model that has problems try deleting the groups then renumbering... if that works then we will know it is somewhere in there. Alternatively, you could selectively delete groups to narrow down which one(s) cause the problem. If that does not reveal anything, then try deleting other things like the analysis sets.
How about Results? Do you have any in the model? A large amount? If so, maybe delete those and see if that helps.
I know the model is proprietary however I will make one suggestion if you would want us to look at this issue. Delete all your geometry. Delete all loads, constraints, elements, properties and materials... assuming any of these are at all proprietary. Then use the Modify->Move To->Node command, select all the nodes, choose the origin (or any location you like) and turn on all three coordinate check boxes. This will move all nodes in the model to a single location. Since location isn't involved in renumbering it should not matter for this problem, but a model with just a bunch of nodes at the origin should no longer be that proprietary. Based on our previous comments, you may need to leave the groups defined in the model though.. if the titles reveal anything, you can change or remove them ... again that should not impact renumbering. If you do want to send us that model, but don't want to post it to this forum, I can give you my e-mail address.
Thanks grudy for the extensive answer!
The solution was to delete all groups and then the renumbering worked perfectly! I was considering finding the guility group(s) by deleting only a portion at the time and trying to renumber as you mentioned. However as there were hundreds of them it seemed like a time demanding solution. Also fortunately we create the groups automatically so these were easy to re-create. An API that removes nodes from groups may have been another option if the groups would have been manually generated.
Great! I'm glad you got around the problem. Sorry to keep asking questions, but there was still obviously something wrong, and I'd like to make sure it doesn't happen for you in the future.
How were your groups "automatically" created? Through one of our Group->Operations commands? an API? or some other method? It appears there might be something not quite right in how they are created... or at least something that renumber isn't expecting.
Something I should have asked before... is this a large model (millions of nodes?) with a large number of groups? Just want to make sure that "renumbers forever" isn't caused by some inefficiency in our code.
One final offer, if you want me to look at your groups, you can use Neutral Write, turn off all the options but "Write Groups" and send the Neutral File... it contains nothing but the IDs of the entities contained in the groups. Again I certainly understand if you don't want to do this.
Sorry, Ive been busy without time to look at this for a few weeks. Now I've identified the group that is causing the problem. However I'm not sure what exactly is wrong. The group does reference nodes and elmenents that do not exist anymore but this doesnt seem to be a problem w.r.t. renumbering the nodes.
What's interesting however is that the group contains 2832 different node IDs when choosing Group -> Node-> ID... and Pick->Copy as List. It is clear that the entity selection IDs are only added (+) ids, no nodes have been removed or excluded. All other selection (Color... Layer... etc.) are empty.
However when choosing List -> Group for the same group the message window will fill up with approx. 130 000 rows of ID info, and the shown IDs are apparently only a fraction of the total number of nodes in the group (not all are listed in the message windos). So it is clear that somehow there is a large number of hidden IDs in this group that probably is messeing things up. Also, using the entity selectors it is not possible to get rid of these nodes. e.g. by excluding all nodes of the model.
Again, without actually seeing what is in the group it is hard to give any real guidance, but... when you say you are getting 130000 lines to the message window are you talking about Group Rules or Selected Entities? Do you see anything "funny" about the IDs in these lines? Are there duplicates? IDs outside of the range of nodes in your model? Invalid IDs?
One of the strange things is Pick->Copy as List should copy all of the selected node IDs... whether or not they actually exist. So that says only 2832 nodes are selected by IDs. The huge number must be selected by another rule, clipping, or some other option... what else is in the group? How many nodes are in the model? You could try using Group->Operations->Condense to convert the group to all node IDs.. then use Pick->Copy as List to see how many are really selected.
My previous offer still stands...if you want me to look at your groups, you can use Neutral Write, turn off all the options but "Write Groups" and send the Neutral File... it contains nothing but the IDs of the entities contained in the groups. I still certainly understand if you don't want to do this.