Keywords: design, fatigue, optimisation, finite element analysis, API, homogenisation.

The current state of computational mechanics for the design analysis of engineering products has reached a stage where there are about six large general-purpose FEA codes that undertake nearly all the analysis in the world. Over the years such codes have added, and will continue to do so, many capabilities and features at a fast rate, because of changing hardware and user demands for ever-increasing competency and integration into product lifecycle management (PLM) environments. Clearly if 20 or 100 users want or demand a certain feature, then a developer will respond to this. Also, if a competing programme is seen to be offering more, then this may trigger the inclusion of features. If lots of users wanted to be able to calculate the torsion-bending constant of an arbitrary cross section; or they wanted to know stress-strain curves and failure criterion for carbon nano-tubes then these would be in the codes.

As opposed to the ever-increasing generality of FEA, the results of the FE-NET survey in November 2001 on the use of product and system optimisation (PSO) in industry revealed that a large range of methods were used for this. Many of these were in-house because the information and data were confidential and therefore of great local value. Also in the research literature there is evidence of an ever-increasing range of methods that can be applied to PSO. Thus the conclusion can be reached that for any individual company or product very specific algorithms need to be applied to achieve best performance.

Another reason that there is an increasing divide between generality in FEA commercial codes and user requirement is in the area of in-house data, especially materials data. In the last century much research data on metal fatigue was published; this is not the case today. Such data has commercial value and whilst the owner wants the data to be used they do not wish to give it away. Thus the marketing of an EXE computer code containing the data that can link to commercial code is an easy way of resolving the situation.

In the area of training and internal QA processes inside an organisation it has often been said that more than 90% of FEA is never used because it has been undertaken as part of a learning experience. Often an early user will find interesting ways to navigate through the code and a lot of human and computer time is expended by trainee analysts solving the same problem in many different ways and with different mesh situations. The company may wish to standardise navigation and options and implement its own QA for model checking. All of this can readily be accommodated by having a Application Programming Interface (API) between the user and the FEA which limits and controls the use of the FEA to the organisation's aspirations.

The emergence of Application Programming Interfaces (APIs) for some general-purpose FEA codes is now enabling all the points raised above and many more, to happen. This paper talks about the general issues and describes how APIs work and what they can do for a user, and gives a few examples from the areas of material characterisation, structural endurance and structural optimisation.

purchase the full-text of this chapter (price £20)

go to the previous chapter
go to the next chapter
return to the table of contents
return to the book description
purchase this book (price £90 +P&P)