Great FEA report for the win!

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

Each of those will depend on the task. But usually, there are the “great unknowns” in each report. I’m not saying that each and every detail should be there (that would simply be too much)! However, you should include basic information about everything. I would say that the list should have at least:

• Boundary conditions
• Mesh information
• Mesh refinement if you did it : )
• Material models
• Loads
• Analysis types
• Outcomes of the analysis
• Discussions of outcomes
• Conclusions

Sure, depending on the report there may be more, but those are usually here. My experience is, that loads are usually well described. This is most likely because there are usually clear rules on how to calculate those.

The same goes for outcomes, and even material models (although I admit I usually work with metals, where the models aren’t as complex as in some other cases).

There is a bit problem with mesh, but I can even live without that… I mean, ok meshing is important, and maybe deserves more. But I think that if I put at least few pictures of various mesh details I should be fine. I will be able to say (or at least estimate) if the mesh was ok or not.

The biggest issue I have when verifying reports are boundary conditions! I don’t think I have to convince you, that the way model is supported will impact your outcomes. But somehow, those very rarely get into the report (apart maybe from the “node” and “directions supported” table that is useless anyway).

I’ve made plenty of stupid boundary conditions mistakes in the past! I’ve learned (luckily not the “hardest possible” way), how important boundary conditions are. One stupid “last minute” choice, that seems completely unimportant, may seriously impact your analysis. Just be sure to think about your support, and describe them in the report – trust me it makes sense : )

We will discuss boundary conditions in the future post : )

Takeaway!

What I would remember about this:

• Do a report that you will be able to use later… because you actyall may have to!
• Always include all the assumptions and codes/coduments that you use… everything will be clear, you will be able to recall those later, but also “prove” that something actually was agreed upon in the past.
• Describe all the important parts of your work
• Don’t forget about the boundary conditions!

Do you want to learn more about FEA?

Great! Just take my free FEA essentials course – sign up below this post: