Node numbering and fatigue

[346gnu]

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.

[ckatsis]

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

[346gnu]

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]

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]

Hi Tim,

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

[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
REF7	Design study. Cf Tim O'							OK
REF7	check. Run a1 then a2							NOK, renumbering
REF8	run a1. remove from session. Open and run a2							NOK, renumbering
REF9	close Pro/E. Open and run a1. Close and open Pro/E. Open and run a2							NOK, renumbering
REF10	batch a1 then a2							NOK, renumbering
Noted that the CPU and elapsed time were significantly better for the study. Model is small, will improvement scale?

[TimO]

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]

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