User: unknown  ||   Login  ||  NEWS: Tutorials, WCFA&PUM, FADOFF jobs: (1), (2), MATDAT, Case Susmel, DTMA2011

 

Title PragTic

Concept

PragTic SW

Author

FAQs

Bugs

 

Fatigue Lounge

PiU Prize 2010

Bulletin

Users

User Profile

Conference List

Photo Gallery

Forum

Reports

Links

Sponsors

Conception of Fatigue Databases

Acknowledgement

Development of this internet database proceed with financial help from Czech Science Foundation (Project GACR 101/07/P350). I would like to thank for this help.

Origin - Why FatLim Was Formed?

The conception was born in my mind, when I wrote my PhD thesis. I had a serious problem then - I calculated fatigue prediction for more than ten multiaxial fatigue methods on 129 experimental results. This formed a huge heap of data, which I had to process.

But, first, I doubted if all the experimental data are correct. I used secondary sources and was unable to find e.g. the original papers by Nishihara & Kawamoto. I had to believe, that the secondary references are right and that there are no reproduction errors. As I found later, there are many of them.

Second, I had to process the data as regards statistic properties of different formed group of experiments with similar loadings. I used to save the results to Excel and subsequently formed a relatively efficient procedure how to add new experimental results to the present data group. But now I get near to 400 experimental results and Excel is giving it up. This is the right time to switch to another way of data manipulation.

Third, although I would like, it is nearly impossible to report in detail on achieved prediction results. I believe, that the scientist should analyse his results and give some conclusion to his analysis. But he also should allow to others to check his detailed results or even browse over them in a search for their own goals. Under current circumstances, I am not able to reproduce full details of my work to any scientific paper. But I can't stand those papers which show only overall sums of results.

Fourth at last:

It is fairly traditional that each author develops his own criterion for fatigue life prediction and verifies it by his own experimental data. Then some other author's data are not satisfied by that criterion, and a new one is suggested. Thus too many proposed criteria have been accumulated, and this testifies, in fact, against the approach of reduction. Many criteria have remained isolated each from other, without comparison or competition.

reproduced from S. Stefanov, Int J Fatigue 1996

Well, if I have a tool in my hands, which allows me to do fast computations over many different load regimes and experiments, should not I try to overcome this fractionalism? And if I got some results, should not I allow anybody to see it?

I have to agree with Stefan Stefanov. There are still newer and newer multiaxial methods, but the experimental results on which they are tested are very mild. We should begin to map the current situation as regards existing computational methods - and the databases here are the very start of this process. I think, there are still other experimental results, which can broaden these databases.

Recent State (But Heavily Reconstructed Meanwhile)

Exactly, there are several dependant databases, which altogether serve to show you your desired data. These are:

  1. database of users
  2. database of references
  3. database of materials
  4. database of fatigue limits
  5. database of prediction results

I tried to finish all of them to the final state before the Fatigue 2007 conference, but it is already clear now, that I have failed. Well, I currently spent all the time I promised to the Czech Science Foundation, which so honorably gave some money for it, to invest into their creation. It looks now, that any further changes will take some time, but I will try to keep a steady, although slower pace.

Nevertheless, it is very well possible, that you will find some buttons non-functional, but I think that malfunction causing to give you inadequate data should not happen. It is much more probable, that you will get nothing :-)

Because the final state of desired functionality is far ahead, I will try to describe you at least my plans in the next chapter.

Last Development

As I noted in the header of the last paragraph, very many changes were implemented meanwhile. Thanks to my experience with FatLim, I continued in my reflections about the current situation in fatigue research. I do not know about any such a broad analysis of this problem and the results are apparently quite worse than those usually reported in research papers. It seems that the activity of researchers is too often impeded by two facts: (1) unavailability of some fatigue solver that would allow fast implementation of new methods and their efficient and quick testing (PragTic solves this problem nicely); (2) unavailability of experimental data for testing of new proposals.

From now on (March 2009), the most important database is not the one covering fatigue limits only. The most basic item now is a fatigue curve (currently only of the S-N type, but an extension to Manson-Coffin curves is planned to follow soon), while the fatigue limit is only a specific point on it. Each fatigue curve is composed of individual experimental points with possibility to link the S-N curve parameters derived from the data points. A specific specimen type is related to each fatigue curve. Individual load channels are linked to the fatigue curve independently and the loads induced on them need not to be harmonic or constant only.

The two fatigue database interface representations are built around the same core with the information, i.e. the database set is only one. The representation of data is wholly dependant on the point, from which it is called - i.e. either FatLim or FinLiv.

The problem started to be a bit too huge for me and thus I have to take a rest for a while, before I continue with it, rearrange the structure a bit again and fill in the respective data. Meanwhile, I welcome any your suggestions.

Full Functionality

I will use bullets so that it would be more clear:

  • Description of computational methods - I wrote some theory to PragTic Help, but it is clearly unsatisfactory. Well, is anybody there, who would like to help?
  • Identification of the computational way - currently, there are only results given either by PragTic or by an analytical solution. It would be great if anybody would like to add his own solution from other software, but how to identify it?
  • Signing - I planned that any privileged user will be able to sign any item of database. His signature will be a mark, that he saw the data, compared it to the original paper and it corresponds. It is a pity that I have failed to introduce this concept already now, because it allows to separate all the reproduction errors occuring in secondary references.
  • Editing - I have had to simplify the editing of existing items due to lack of time. Any edition of existing item can be done only by the person who created the item (or by me as administrator). Originally, I hoped that any privileged user will be able to edit any item. This will create a new temporary entity in the database, while the original creator (manager) of this item will be notified about the edit proposal. He has 30 days for either acceptance or dismissal of the proposal. If he does nothing, the new proposal will be applied, while the proposer will become manager of this item. If the original creator and the proposer will not unite in their opinions, there is still the forum, where they can open their problem to other users.
  • Result details - the user should have fast access to information concerning the tables of experiments and results. What was the material? How it was computed? Well, with PragTic - but what was the precise setup? All these facts cannot be integrated to the same table - it is already large enough. I plan to add there small popup windows, which will inform the user about these details. But alas, I'm lacking time to find the right way... Do you know some simple solution? The content of these popup windows should be filled from the databases, i.e. no permanent html file should be there.

Conclusion

Well, I have to sum it up. I wanted to offer you a fully integrated interface to a set of accessible databases which would allow you to estimate, which multiaxial fatigue method is suitable for your use. Although I currently failed to built it in its planned scope (as regards the interactivity above all), I think there are still data which are very useful. So, test it and write me whatever you think over it!!! And if you become a privileged user, you can join our forum and discuss your opinion there.


papuga@pragtic.com

Title FL_DB

Concept

References DB

Material DB

FatLim database

FinLiv database

FatLim job file for PragTic

Glossary

 

FADOFF Project

FP7 Project

 

WCFA & PUM

Application to the WCFA & PUM

Payment of the WCFA & PUM

Transport to the WCFA & PUM

Time Schedule of the WCFA & PUM

What Next? - Evaluation