FEA Design Tips #002

Wow... it's the next week already O.o

This means that it's another roundup post! I will always be a week behind on what we talk about in the Facebook group (even more reason to join it!). This is on purpose - I simply want to get all the insight and those awesome discussions that happen! This way, I can share my ideas, but also all the cool stuff people are asking/suggesting in the community!

Some really cool ideas here!

Read the solver manual!

Today's tip is my superpower! When I have no idea what a parameter does I simply put a "stupid" number in... something that won't appear a lot in the model like 13526. This way when I print an input file I can Ctrl+F the number... and check what Keyword is that. Then it's only a "search away" in my solver manual for this keyword - and I know what the parameter does. Usually, with examples and commentary from people who wrote the solver! This is such a useful thing!

There is so much value in searching like that, and it also saved me several times already. I even used it during training, when someone had issues with software I haven't used before, and he couldn't find the options to define analysis properly. It's not only fast but also one of the great ways to check what stuff does! Try it - you will love it!

Make good reports!

Wow... this topic got a real attention - it looks like this is a real issue. Based on all the comments I can assume that most of us hate the "data tables" and hundreds of pages of node coordinates. Yet, they somehow appear everywhere, seemingly out of nowhere ;)

There are plenty of references, but I won't even try to bring them all to light. One of the examples would be Michael comment:

And of course...

A lot can be said about reporting. This is why I have separate lessons about it in my online course. If you want to stand out in a good way... always write good and easy to understand reports. You would be surprised how scarce this skill is!

Define the scope...

I had a very interesting conversation with the potential Customer.

He wanted me to start and finish small calculations in 2 days. But he didn't know a lot about what is there to be done.

I've seen this a lot. People usually think that they need "static design" or "stress analysis"... but they don't even know why?

Helping your Customers realize what they really need and why makes it easier for you to make a good offer, and deliver a good solution : ) Not to mention that you can save yourself a lot of effort by not doing things they don't care about!

Asking about global goals is a really good idea. I think Aleksei put it really nicely in his comment:

Check the inputs!

This is something Aleksei mentioned in the FEA Guild discussion on the previous tip, so here we go!

I do a lot of silos design... and usually "material properties" of the stored bulk solid are a taboo. Some are described in the Code (for selected materials) but usually you have to do a silo for something else : )

Theoretically, the workflow can go like this:

1. You do the model, meshing, BC and all the jazz - this takes time

2. In this time Customer "secures" material data from a supplier of the material

3. You do the loading and all the rest

4. Success! Time to go to the beach!

But... this never works! Usually, all you get is a chemical composition of this stuff, or just density, or information that it's "similar" to sand. And an ugly question arises... what next?!

Avoid those - check all the inputs at the start!

The most extreme example I was personally involved in was the case where Customer changed the material properties 4 timed during the design. Silos were recalculated 4 times... leading to awfully more work that it deserved. Not to mention that the correct (or should I say "final"?) set of data was delivered around a year after the deadline for the design have passed (yea... about that!).

Convergence issues - use Arc Length!

Convergence is just one of those things. I guess that there will be a lot of tips about this in future :P One of the problems may be, that you try to load the model over its capacity. In "normal" analysis such a thing would throw out a "non-convergence" error message. Using the arc-length method solves that problem... and can even show you the post-failure stage!

What I love about being part of the community that cares is that you can get awesome feedback. There is an issue with the advice above I haven't seen while posting it. All is ok, but it shouldn't be the first advice on convergence by a long shot. I think Aleksei can make the case himself:

That's it for today : )

I hope you like it. Let me know in the comments what do you think about posts like that. And... if you want to hand out - join our FEA community (it's fun!).

Without a doubt, advice in FEA Design Tips will be about a lot of different stuff. If you prefer a bit more "organized" learning try a free online course I've created!

Want to learn more?

This is really awesome! I have a free nonlinear course just for you!