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:
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)
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), .
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.
... 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?|
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.
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