User: unknown || Login || NEWS: WCFA2024, Two lectures in Prague, Records from W2TFP, FABER funded!
Concept of the Project
Introduction
The project is aimed into a category, which is already full with commercial packages doing the automated fatigue calculation. I have some experience gained through the months, when I tried to find such a software for my employer ŠKODA VÝZKUM s.r.o.. There was none among the commercial packages, which would fulfil all our requirements. These software tools have been already programmed for years, with much larger staff than I can imagine at all. It seems that they are improving year after year, but there are still some points, which I do not like. If you are interested in those commercial packages, see Sec. 4.1 in my PhD thesis.
Calculation of fatigue damage is a pretty complicated task. Even if you get all necessary material constants and load history and description of the manufacturing technology used and whatever else ... you have no certainty, that the result of calculation is well. You need some experience to recognize it.
There are subjects in the fatigue calculation, solution of which is still under process. I've specialized on the multiaxial high-cycle fatigue in my thesis. The calculation is relatively simpler and faster in contrast to the low-cycle fatigue, so one could expect that no substantial improvement can be achieved after so many years. But I've managed to get better results and there still seems to be a space open for a further improvement.
Except for the multiaxial fatigue, there are other areas, which should be of interest:
- fast fatigue solution in low-cycle fatigue, where plastic zones occur;
- thermo-mechanical fatigue;
- damage due to creep mechanisms;
- growth of cracks;
- vibration fatigue;
- welds;
- etc.
It is funny, that many of the areas separated here usually amalgamate one with the another in the case you need to do some fast and very necessary fatigue computation.
The knowledge of all these problems is still evolving, while the computation procedures are getting to be more and more complicated. Software producers are trying to offer a suitable solution to engineers, who require it. My feeling from the implementation process is, that a method how to program and compute the problem is often more emphasized than the verification that it leads to a good prediction. I found very scarce data on usability and accuracy of many multiaxial methods, which are already implemented.
The software producer often try also to shield their implemented methods from other competitors. This is another reason, why the potential user gets only a piecewise information, how the method used works, where it was tested, with which effect, etc.
At last, if you are not currently cooperating on some project for implementation of any new method into one of the commercial fatigue postprocessors, you don't have any possibility how to test different approaches, behaviour of less known or completely new methods or other deviations from the solution already implemented. This is the point, I hate the most.
What Next with PragTic?
To Researchers & Scientists
If you are resercher in the field of fatigue of materials, you face necessity to program anything you develop as a new. As the methods of calculation are more and more developed, they grow as well as regards the effort, which has to be invested into their coding. What's more, if you extend the area of the new method's potential use towards more complicated engineering structures than the common polished fatigue specimen is, you are confronted with necessity to operate over FE-data.
It is very well possible, that you love Matlab and are ready to use it for this purpose. But you should be also aware of the fact, that in order to prove your method as the best you have to implement also the other existing methods. As regards implementation of e.g. new multiaxial methods into the commercially available fatigue software, any update froze somewhere in the starts of the nineties of the last century. So, this part of work is up to you.
Still, this is not enough. Since the fatigue phenomenon is strongly influenced by statistics, you have to expect that you have to repeat all calculations for many different test specimens and load conditions. I can tell you, even if I tried to optimize this point in my software, it's still terribly tedious work.
I can imagine, that there have to be more software codes built in order to solve the same problem. But I haven't heard about anybody, who would offer his work to others. Don't you think, that to do the same work is a bit useless?
To Engineers
Well, here we are a little bit too ahead of PragTic's features. But my view on the present situation follows.
The fatigue software packages are relatively expensive. When I looked for this information in the spring 2005 the common price for a package including weld and heat modules was over 50000 Euro. (The only exception I found was WinLife, price of which was set to something like 10000 Euro in the full - basic & multiaxial package.) The prices mentioned overcome price of most of the FE-software.
The user has to pay an annual maintenance, which lies somewhere between 15% and 25% of the purchase price. Sure, you can skip it - and the software will remain to be a property of your company. But this is not the right choice, the fatigue postprocessors of FE-solution are young and still in rapid development. What about an expectation that you will not pay for 3 years and then again start to give money for the maintenance? Well, it can work if you have very good contacts with that software company. Otherwise, you'll be forced to pay back the skipped maintenance or even buy the software again.
Well, you have this mighty new (and expensive) software. It nicely reads the FE-data and produces wonderful color maps of fatigue damage on the examined virtual component. Great, you are the lucky one! But maybe you have some experience from the work with the FEM. You are a bit sceptic: "Have I done everything right?" You know, that e.g. unsuitable setup of boundary conditions in the FEM can lead to disastrous quality of results. However the physical and mathematical basis of the FEM is O.K., it can still happen.
You start to read and reread manuals of the chosen product, you even search information on the internet. And then the ugly, black truth finally emerges. However the researchers try to improve the solution, it still has very many degrees of freedom - i.e. points which can be solved either in this or that way, but you're not sure which. The fact, that the unknown is not only one, means that you can achieve good results even by a combination of wrongly set partial computations. What's more probable - deviation of your results from the reality will be substantial.
In such a situation, one would expect, that he will rule over the computation process. He will have access to detailed description of the computational background, of the method used itself and also of its verified use. I don't think this is the case. The software packages have very beneficial features, the automation usually works well, but... they provide very poor feedback on quality of given options and setup.
The manuals are very often too brief, since the competing software producers don't want to open up their particular solution. What would you think about a method briefly sketched in the manual pages and claimed to be proven on many occassions (no more facts), when you find that there is only one report on it in the International Journal of Fatigue, which is focused above all on the automation process not on its prediction quality?
It is common, that the software producers disclaim any potential problems resulting from the use of the software. Thus, the only guarantee you have is the name of the company and this high price paid for the software. Well, they wouldn't sell it so expensive, if they wouldn't be right. Hope you so? Or are you a little paranoid as regards this question?
When I make short conclusion:
- To buy the fatigue postprocessor is relatively an expensive step.
- So the maintenance is.
- Results of its use have to be closely examined, if they really hold true.
- Number of potential employees able to penetrate under the surface of the computational process and to say expertly what the result mean is low.
It is clear that the major potential users of the software are large industrial units.
Wouldn't it be interesting to built an independent computation system, based much lower and demanding a bit more work on data? What about to release it as a freeware - at least in the basic variant? I believe, that at least the point 1. mentioned above could be set aside.
To be continued later... Sorry, the project is still under construction.
Development in 2011-2014 supported by:
