Great FEA report for the win!
?ukasz Skotny
? Nonlinear FEA Enthusiast ? Structural Steel Expert ? Engineering Tutor and Blogger
I’ve recently posted a tip about writing good FEA report… and I must admit that what followed surprised me! This is the most discussed topic to date. Naturally, I figured I will expand some of my ideas into a longer post.
Let’s give it a try : )
FEA report: business or tech?
I strongly believe that the reports that you do have 2 sides, the business one and the technical one. I don’t want to dwell into the business part here (you can learn more about reports in my FEA course if this interests you). Just be aware that regardless if you are an employee, business owner or even a student you do “business” with your reports. The “business” part of your report will strongly impact your career achievements. After all, this is all that’s left after your hard work is done!
However, there is the technical side of the reports as well. And I want to focus more on this end today : )
I can say, that most of the reports (that I had to verify, or use) were completely useless. Initially, I assumed this has to be a bad luck! But then I realized that there is a “line” of bad reports “in search” for each engineer that does good reports.
If you would think about it, Customers want to have good reports (at least most of the time). If they get it, from their current “engineering provider” they are happy and well. But if they are not satisfied, they will search for someone else . And of course this is why they can find you! So you will have to deal with all the bad reports they will give you as an input data!
First of all: write the report for yourself
It always surprises me how often you have to go back to your work from previous years. Eiter Customer wants to change something, or use the same design in different conditions. Or perhaps an external verification office have some questions?
Whatever the case may be, quite frequently you will have to put down what you are doing to check what you did previously. Based on that, you will have to give recommendations, answer questions or explain some choices.
It’s good to have a report where you actually wrote what you did and why. It will help you a lot in those tasks, I believe : )
Seems obvious right?
For whatever reason, a lot of comments comfirmed what I saw myself. That most reports are basically “automatically generated” printouts with tables containing numbers or some other low-form of engineering.
Michael put it nicely in one of his comments:
I once got a report from another firm that contained 130 pages, of which about 100 pages were ‘element temperature load on member number…’. I don’t think they actually check what was in the report before sending it.
So the first and most obvious advice would be, don’t do that to yourself! There is a high chance you will have to go back to this in few months (or maybe even few years). What will you do then?
Secondly: focus on assumptions
Depending on the task you are doing the list of things you will have to include will differ of course. But there are always common things as well right?
You will use various codes and documents you will reference. Naming them (and writing chapters or pages) will help you to find what rules you were using before. This alone can save you a lot of trouble later and makes your report more usable and easier to understand. If this happens often in your industry, you may want to include which version of the document you are using.
Describe all the conditions that you and the Customer agreed on. This will be a great help, not to mention that you will have all the agreements in one place! This is always handy, especially if disputes appear after some time. Luckily this happens rarely I think (or I’m just blessed with good Customers). Regardless, having all the assumptions in the report means that in future there will be no arguments about whether someone said something or not. Also, you will simply have easy access to all important decisions that were made!
Finally: the great missing pieces and the takeaway!
Read the full text on my blog!
Want to learn FEA?
GREAT! I have a special free FEA course just for you!
Vibration Fatigue Engineer at Mercedes Benz R & D India
6 年You are Absolutely Correct! Report is the ONLY PRODUCT for a FE Engineer to sell. Whatever hard work and Engineering thinking goes to solve must and should be reflected in the REPORT. Even now I receive reports which doesn't even have Basic information of CAD data and version used, Loading and Boundary conditions applied,,, Material properties used.....
Principal Engineer at 2H Offshore
6 年Nice article! During all these years, I have to "unravel the mysteries" of somebody else reports, acting as a third party checker or when it is necessary to replicate an older calculation to generate new results. I think most of the analyst (and I include myself in this group) think the report is the most boring part of the job, and in many situations is done very close to the deadline. But I agree that the report is very important and found your tips very useful. If the report contains a lot of useless input and output data (in most of the occasions, in a veeeeery small font) and few explanation about the design premises and discussion of the results, it can give the impression that the author is not very confident of his work, or even is "trying to mess" (it is a joke ;) ) .
Numerical analysis specialist (FEA/CFD/CAE), Development Engineer, Trendspotter
6 年HTML tables and storytelling was my reporting recipe for years. In HTML tables, you can display alternatives next to each other. Each cell can link to background information, possibly 3D graphics which the reader can explore herself. Add some storytelling to supplement the concise, hierarchical information presented in the tables. If you use autogenerated PDF reports to hide the essentials as a needle in the haystack, you will have difficulties making friends. Friends in high places will be particularly difficult to reach. Storytelling is a much better means for that purpose. (Btw., I am no opponent of autogenerated reports per se. I once developed a system which autogenerated the HTML tables referred to above. That setup kicked ass!)