I would like to know if someone has been able to made a fatigue analysis (through the fatigue advisor extension), starting from a non linear structural analysis.
I know that it is not allowed by Creo Simulate, and I think that it could be nice to have.
In particular, the description of my problem: I have a static structural analysis on an assembly, with non linear interactions between components; then I'd like to make a fatigue prediction on each single component but unfortunately I cannot use the static structural analysis run on the whole assembly.
Does someone have a suggestion?
You are correct Elena, you can't do fatigue analysis (as implemented in Creo's "Fatigue advisor") on a nonlinear model. What type of nonlinearity is it? Contact? Plasticity? If it's contact, and displacements are reasonably small, you might be able to create a linear model that behaves similarly to the nonlinear model. This can of course be tested before running the fatigue analysis.
Fatigue advisor can also be used to extract the S-N curves, so that you can do your fatigue analysis "by hand" outside of Creo. In Fatigue Advisor you do not enter the S-N curves explicitly, instead you enter material type, the material's yield- and ultimate tensile stress limits, etc. and from this info, the software derives the S-N curves for you. Fatigue advisor also adjusts the S-N curves for mean stress; compressive stress cycles are less harmful than tensile ones...
The S-N curves derives from testing are not always available, fatigue testing can be expensive and time consuming. So using Fatigue Advisor to obtain this info can be an alternative.
Is your loading constant amplitude, or do you have a load spectrum? If it's constant amplitude it's easier, then you can derive the S-N curves and find your expected fatigue life (with given probability) directly from the S-N curve. If you have a load spectrum, then you can run your analysis, linear or nonlinear to get your stress history, and then do your rainflow count and damage calculation in for example matlab. I have downloaded matlab scipts for rainflow count from the matlab user community and then made the damage calculation in matlab. You should be careful however, when you select your load spectrum, especially for high cycle fatigue. Results are both sensitive and uncertain; a small change in stress level often results in a significant change in fatigue life. The method can be used for comparative "what if" studies, but to make absolute predictions of failure probability vs. service time, you need quite a bit of experience from similar products, about the accuracy in your FEA-modeling technique, how well you know your load spectrum, how well you know your S-N curve etc.
You have to 'merge' your components and make a single component.
Where there are contacts, you're stuck.
Other non-linearties are also disallowed.
Fatigue Advisor is limited.
It has improved since WF4; but not much. I have seen a video that PTC released (last year?) which broadly introduced the most recent fatigue advisor improvements.
Does anyone have a link? It's not available on youtube anymore (I can't find it, so it could be just me) and it's not on the PTC support site where perhaps it should be.
I know improvements included multiple loadsets. and you can now read in your own cyclic stress-strain curve. But still limited to 100 data points for a load history so you cannot read in a useful signal and perform rainflow counting. You can rainflow count signals in Solidworks, and use PSD's and ,,,
Solidworks competitive offering is relatively better.
We use fe-safe but working with Mechanica files is quirky and the read/write of Mechanica data is more limited than with Abaqus etc where one can study component within an assy, analyse individual nodes...
Does nCode have a working interface for Creo yet?
fe-safe & nCode work well with Ansys, Abaqus, Nastran
I'll try and get this right as I am working from memory,,,
There's no besmirching of Mechanica/Simulate and they do say 'fine scale' too. Simulate model results continue to be as 'accurate' as the user is capable.
This is to do with the structure of the .s0x etc files and the interface algorithm Safe Technology (Dassault bought them) had to read these files which didn't quite work properly.
The mechanica elements are subdivided, there are P-nodes and between these are H-nodes. Results are stored in the files against these node 'types'. (Mats posted a link recently to the file structure).
When performing a fatigue study we usually only care about the stresses at the surfaces and so when reading in information to carry out the fatigue calculation one only reads in the stress values for nodes at the surfaces. (also identifiable by the normal stress=0, unless a contact surface). Only performing the calculation on the surface nodes saves time.
When we first started using fe-safe we found that reading in surface stress info only gave us fatigue solutions at the P-nodes and the results between were interpolated. But interpolations were all stored as zeros as I remember, so the model looked 'spotty' when reviewing fringes. We mustn't forget that the P-node solution would have been correct; there is no matrix to invert.
The work around was to analyse the full model and go for lunch.
We raised a call a while back and it's good that it's fixed.
There's still a node numbering frustration with Mechanica files though. I think that this has more to do with Mechanica's history than fe-safe ...
re-reading the image you posted,
... now been fixed by reading in the H-element mesh as well ...
That's why they were zeros