Reporting FEA 2

[jhml]

I’m thinking how to document a finite element analysis in an intelligent way. Intelligent documenting leads to the ability of structurizing all knowledge gained in each analysis and to rerun the analysis later on. Even when the analyst who has done the analysis is already gone for a long time, the new analyst should be able to check what has been done in that analysis, based on the knowledge written in the finite element report. He should also be able to rerun the analysis.
Structurizing knowledge gained in each analysis is not only interesting for the analyst but also for designers who might have simular design problems.

Is there anyone who could tell me, what aspects a finite element report in general should contain in order to reach the aims described above? Or maybe someone has examples of a good finite element report.

Thanks for your feedback.

Jan Hemelsoen
research engineer

 

[mloew]

Jan,

I applaud your efforts. Reporting activities (and process documentation) are typically week. I would first check out some of the resources available from NAFEMS (

http://www.nafems.org)

as this organization works hard to generate standards and establish benchmarks.

A search on Google.com with the keywords: FEA & reports and received 73,000 hits.

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=fea+reports

Good thing Google ranks them! Try adding additional keywords to narrow the search.

Please let us all know what you find out. I am sure this is a topic of much interest to this community.

Best regards,

Matthew Ian Loew

 

[tld23]

Dear jhml
My thoughts are that the NECESSARY quality assurance issues should encapsulate the modelling that has been carried out. This should them be supplemented by a modelling file which corss-references the QA and computer files. I quote from a publication of mine (in press) the principles of what the QA documentation should contain

" By now I hope that you are convinced that some sort of QA should be carried out for all analyses. My view is that the following stages should be adopted:
· Pre-analysis definition that should be independently
assessed and approved. This should cover:
o A specific and unambiguous statement of the objective
of the analysis. General statements like “to find the
stresses in the shaft” are not good enough. The
objective should be linked to the overall project of
which the FEA will be just a small part.
o Critical assessment of the overall approach. Is FEA
the appropriate technique? Are the modelling
simplifications proposed suitable, e.g. 2D?
o A statement of what analysis results are needed and
how they are to be used. Again be specific and link
back to the objective. Do you need absolute values of
the results for use in a design code, e.g. BS5500 or
is prediction of trends or relative improvement
adequate?
o For complex analyses the model should be built and
tested in stages. Define milestone analyses so they
can be tested. Don’t get to the end of a complex and
expensive analysis only to find out it does not work!
· On-going checks. These are vital to make sure the
analysis is on-track.
o If milestones have been defined use these.
o Check the results against independent data such as
theoretical solutions or experimental results. See
also §1.10.3
o Be willing to modify your analysis plan. It is rare
that building, executing and analysing a model goes
exactly to plan as originally devised.
· Post-Analysis validation, approval or sign off. Like the
first stage, someone independent of the analysis detail
should carry this out.
o The analysis should be checked against the original plan.
What deviations have been made and why?
o Do the results make sense and do they agree with the
validation, if not why not? At this stage the reviewer
should ‘dig around’ to find problems and in particular
should ask ‘stupid questions’ about the analysis.
o Are the main results what were needed as defined in the
pre-analysis stage?
o Finally will or do the analysis results meet the project
objective?

The above bullet points are rather general but they should be appropriate to most analyses. The detail and formality of the procedures to implement the above will need to be tailored to your products, company and industry. Critical components and/or products where the potential cost of getting the analysis wrong is high (i.e. in human or monetary terms) will need much more stringent procedures than non-critical parts or components. "

This approach enables the record keeping to be done as part of the QA, which should save time. Independent review should help keep the QA and records in good order. I hope that this helps.

TERRY
TERRY

 

[cb1990]

Hi Jan,

Here is a basic outline of a good report:

Background (describe why the FEA is needed)
Summary (brief section of results)
Modeling (describe model include geometry type ex. autocad,Pro/E etc., pre/post processor, solver, number and typ of elements, assumptions)
Boundary Conditions (list all constraints and symmetry)
Materials (describe all material properties)
Results (describe in detail your results including a discussion of assumptions and how they affect error)

Include figures of geometry with BC's and loading. Have generous pictures of plots and graphs of results.

Finally to make the analysis reproducible include file locations for geometry, pre/post files and solver file. You can also attach an appendix with the solver data file minus the endless list of elements and nodes.

Dont forget to compress all files in a zip or tar when done.

Good luck

cb1990

 

[JKEngineer]

As something of an aside:
CosmosWorks currently has the ability to generate html reports from a solved model. It includes sections that the user can specify as to be included or not. In addition, most of the sections provide space for the user to input information, such as that discussed by the others. It picks up the results plots from the model. It is not perfect, but it goes a long way to providing a reproducible structure to FEA reports. I believe that some of the other packages offer similar capabilities, either through html or Word reporting.
Jack M. Kleinfeld, P.E. Kleinfeld Technical Services, Inc.
Infrared Thermography, Finite Element Analysis, Process Engineering

http://www.KleinfeldTechnical.com

 

[mloew]

Jan,

I found this link to standardized formats for reporting, presentations, etc.:

https://pronet.wsatkins.co.uk/pub/english.cgi/0/13818675

Best regards,

Matthew Ian Loew

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora

 

[jhml]

Thanks everybody for the interesting comments and links.

I have searched many links on the internet about this topic, but I've found very little useful information. Yet, there is the opportunity to follow a few courses at the anker-zemer company and the genexis company. It is just a pitty that my company doesn't have any money for that...

After all, I understand that a finite element report should be seen as a part of a bigger project and it should contain a description of all issues that assure the quality of the analysis as described by tld23.
Probably, this report should then be stored in the PDM system of the company and not printed out on paper and stored in a closet as the former analysts of the company did...
Until now I don't think there is a better way for intelligent documenting but to link the FEA report to a part number or sub-assembly number in the PDM-system. In this way the knowledge gained in the analysis can be spread efficiently to all designers in the company at the moment they need it, and you can search for it very easily. Although this might seem obvious, but in the company I work PDM is until now maily used for CAD files only...

If anybody has got other ideas or additional information about this, please let me know.

Best regards to all and thanks again,

Jan Hemelsoen

 

[corus]

The questioner raises two issues here, first the QA method of checking the analysis, which has been covered by many replies, but also the retrieval of that information. The information could be saved in a database with various checks on the type of analysis/element/application/approach etc so that any other could search the database for a similar model. It's cheaper just to ask around though rather than develop some knowledge capture intelligent system.

 

[mloew]

I was just at a good technical session at the SAE International Truck & Bus Meeting & Exhibition. The session was Modeling & Analysis of Heavy Duty Vehicles & Brake Systems (Session Code: TB15) and the paper dealt with standardizing the entire analysis process, not just the reporting format.

Effective FEA for Product Development Support - 2002-01-3124
Scott Kuan, Shan Shih, Rajesh J. Somnay, ArvinMeritor Inc.

Copies of the paper can be obtained from

http://www.sae.org

Best regards,

Matthew Ian Loew

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora

 

[kan123]

An often overlooked aspect is internal documentation. Since the computer model and the final report are often stored separately, it is important that the model be more than just a "box of numbers" that only makes sense to the original analyst. This is one clear advantage that ASCII input files have over binary databases -- detailed comments can be inserted that explain various assumptions and describe individual components and materials of the structure. Unfortunately, most FE vendors push interactive building and running of models onto new users. Then it's difficult to break the newbies of the bad habits they learned in their introductory classes.
-- Kirk Norenberg