Hmmm nerd senses are tingling. Or just sleep deprived...
Multi-threading isn't a magic wand that can be waved at any old pumpkin to turn it into a muscle car.
It's pretty easy to break down. In order for multi-threading to work on a process, that process has to be broken down into different tasks that can be worked on more or less independantly of each other. Look at what you are doing in Inventor, break that down into gross steps, detail those out a bit further. Which of those are dependant of each other (FEA, image processing, as noted)? Which are not? The former are a good candidate for multi-threading. The latter are not as each operation must wait for another to finish before starting.
A more general example is operating in a very large database. A look-up operation (match records with field content "Blah", match records with field content "More Blah") can be executed in parallel with each other since they don't affect each other. A generic write operation cannot be strictly done in parallel, since two operations can't change the same record at the same time - one must wait. But with some strategic organization so that the write operations must always work on unique sets of records they can be done in parallel, but it won't be the same level of improvement as the parallel read operations.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.