cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Node numbering and fatigue

346gnu
12-Amethyst

Node numbering and fatigue

We have a simple model (plate with hole)

 

It has 2 loadsets, Loadset 1 and Loadset 2.

 

We create and save the mesh

 

We then carry out a linear static study first with loadset 1 - Analysis1. Then with Loadset 2 - Analysis2. i.e. 2 distinct analyses (not summed or combined).

 

and the constraints are unchanged

 

The saved mesh is reused and therefore we now have 2 results directories with consistent mesh.

 

We can then carry out a fatigue analyis using the results from analysis 1 and then 'append' a fatigue analysis using results from analysis 2.

 

(sometimes loads move about, hence 2 analyses. The real study requires many more load positions than 2 but this is keeping it simple and manually debug-able using the ascii output)

 

Now a description of the problem encountered ...

 

The h-element section of the .neu files, first 6 elements:

 

h-elements 840   Analysis1            
1 6 22884 23759 23753 23762 0 0 0 0
2 -12 23759 23943 23753 23762 23954 23946 0 0
3 6 23759 23758 23943 23954 0 0 0 0
4 -12 23758 23945 23943 23954 23952 24165 0 0
5 6 23758 23757 23945 23952 0 0 0 0
6 -12 23757 23756 23945 23952 23766 23951 0 0

 

h-elements 840   Analysis2            
1 6 23368 24237 24231 24240 0 0 0 0
2 -12 24237 24421 24231 24240 24432 24424 0 0
3 6 24237 24236 24421 24432 0 0 0 0
4 -12 24236 24423 24421 24432 24430 24643 0 0
5 6 24236 24235 24423 24430 0 0 0 0
6 -12 24235 24234 24423 24430 24244 24429 0 0

 

Why oh why oh why has Mechanica changed the node numbers !!!

 

Third party fatigue solvers don't like this ,,,, and these are the ones that are supposed to work with Mechanica.

 

Apart from the pair highlighted which have a difference of 484 in the node numbers, all other pairs of node numbers have the difference of 478.

 

From the h-node section of the .neu file the pairs of node numbers have the same co-ordinates (reasonable proof that the mesh is consistent)

 

I have only just started this investigatation into why our life contours are poor and am hoping for a revelation regarding this. Do I really have to write code to work on the output files to change this? what is the obvious user error?

 

Anyone? (even PTC development he asks tentatively)


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
7 REPLIES 7
ckatsis
1-Newbie
(To:346gnu)

Why can't you run both load sets in a single analysis? Still not summed or combined.

346gnu
12-Amethyst
(To:ckatsis)

Hi,

It is a contact analysis.

Each load has it's own input time history and/or

There is a geometry change (this is a mechanism, easiest to visualise a conrod in a single stroke engine)

The stress state at each time step gives us a stress history. We therefore modify positions/loads for the next part of the history. This history is one of the inputs to the fatigue study.

We are ignoring results near contacts (amongst other 'reasonable' assumptions), .

Thanks

TimO
1-Newbie
(To:346gnu)

I believe we have done this before by setting up each load case in individual analysis, then running both analysis in a design study. In these cases the mesh geometry and numbering is preserved.

346gnu
12-Amethyst
(To:TimO)

Hi Tim,

I will have a look at this design study method, any particular reasons for using a design study?

346gnu
12-Amethyst
(To:346gnu)

... the results of a bit more testing, hope it's useful. I can see the limitation with the design study approach that, should one wish to create an additional step in the stress history, (or modify the load in a single step), then all steps need re-running.

Only acceptable if the analyses are quick.

For each of the following, create and reuse a single mesh file
REF7Design study. Cf Tim O'OK
REF7check. Run a1 then a2NOK, renumbering
REF8run a1. remove from session. Open and run a2NOK, renumbering
REF9close Pro/E. Open and run a1. Close and open Pro/E. Open and run a2NOK, renumbering
REF10batch a1 then a2NOK, renumbering
Noted that the CPU and elapsed time were significantly better for the study. Model is small, will improvement scale?
TimO
1-Newbie
(To:346gnu)

They have the design study setup so you can rerun analyses while studying the impact of specified parameter changes. I believe this is pretty sluggish with larger models though, but I can't say that with much confidence.

In cases you want to process the results in a 3rd party app where you have combination of different constraint sets, contact, or mixed studies (static,modal,dynamic runs together) this appears to be the only option. If an assumption needs to be changed, everything has to be rerun.

Fortunately if you can make linear assumptions in your model, the process of results is pretty quick as mentioned with Christos' comments above relative to solving each load set in a single analysis.

As far as your comment on performance scaling, I doubt it. It probably is just running faster because of some of the shared mesh files. If you are running nonlinear, those convergence steps are the bottleneck. Assuming the model gets bigger, this will slow down a bit.

346gnu
12-Amethyst
(To:TimO)

Thanks Tim,

Unfortunately we can't stretch the assumptions to linear.

Running a single analysis with multiple loadsets with contact or changing constraints is 'meaningless' ... in some cases could we be permitted to bend this rule? Although, these studies would be very lengthy and being able to run and post process individual studies as work progresses has many advantages.

Nice to have the confirmation that an assumption change = complete re-run

Also, if a component moves (but in itself does not change), the mesh file gets confused.

We shall design the work within the current limitations but I guess it would be nice to:

1.Have consistent node numbering when a mesh file is reused

2. Component level csys mesh file structure

Bye for now

Announcements