What lessons did you learn in your CFD business?
 

Hi everyone, this is a non-technical question.
If you're working in a commercial CFD company, or running one, what lessons did you learn ?


I'm looking to learn :


- difficulties you observed along the way
- things you would've liked to tell your younger self
- what mistakes cost you the most in time and resources


Please feel welcome to share anything else that you would like. :)



Thanks and regards
~sayan

Not in the business but when I was learning I wrote a simple open source solver. It was called iNavier. It was something i wrote so that i could learn navier stokes on unstructured grids and i put it online so that if someone wants to learn could play with it.

What i learned is that those who used it, many of them used it as if they are doing a favour to me. Often they would send me request and i would be spending my time doing their work.

That experience was main reason that I created Wildkatze to be closed code. If someone pays for it then he takes it seriously too and values my time.

Never releasing anything important for free. And definitely never going open-source. :rolleyes:
Learned my lessons while trying to do extra work for someone and making some great things for free.


Good lesson for people : always get paid : https://youtu.be/jVkLVRt6c1U

Dear Sayan:

When you are in the CFD software business ...

1. You will be requested (or tricked) to do free work or given lowball offers. It's okay to walk away from time to time, no matter how desperate you are; whatever they promised are just carrots on a stick.
   
2. Industry is not very concerned about physical correctness. They just want the ability to tune their results. That's why you see a lot of adjustment factors in commercial softwares that sound physical but you don't know where they are coming from.
   
3. Along that vein, don't think that your software will have any disruptive effects. It is more important to identify gaps in your client's toolchain and address them (ANSA is a perfect example for this).
   
4. Every CFD software company only has only two branches: development and sales. If you are not a developer, you will be expected to contribute to the bottom line, even if you are not assigned directly to sales.
   

Also, a few words on "open source." If you intend to do development work on your code base for your client, do not release it under GPL. Corporate will have a huge problem with that because they don't want their work that they paid for released as well. MIT and BSD licenses are more contractor friendly in that respect.

For GPL codes that are used by private companies, they tend to be users rather than developers, and they will pay for support and maintenance (e.g., ESI for OpenFOAM). If there are development work to be done, there will be an in-house team to handle this and to restrict distribution.

Having said that, commercial softwares also get paid feature requests from specific key account clients. A judicious product manager can and will refuse them, especially if these requests interfere with their development plans. In the event such requests are agreed upon, there will be provisions allowing said features be released following a lapse period (say, 18 - 24 months after end of contract).

Hope that helps, Gerry.

Great explanation Gerry! Thanks for your help! :)

I have never worked for a commercial CFD company although i have attended a few interviews and was on nodding terms with many of the people behind UK CFD companies from the 70s, 80s and 90s like Cham, Fluent, Star-CD, CFX, OpenFoam,... and some of their larger customers in the power, automotive, aerospace industries and academia. It is a somewhat different world today and I have been rather out of touch for a couple of decades so bear that in mind. I am though pondering a semi-retirement project with a semi-commercial CFD element and so we have that in common.

In the 70s, 80s and to some extent the 90s it was pretty straightforward to create a successful CFD company in the UK because commercial CFD wasn't established in the manner of FEA stress analysis and things were growing rapidly with plenty of UK companies, research institutions and university groups having well established knowledge and experience in the area to draw on. This changed during the 90s and into the 00s as CFD became well established with lots of commercial activity springing up around the world. Today a new CFD company is going to need something more than knowing how to write and support decent CFD software to be successful against the established CFD companies. Specialisation, adding CFD to established software in different fields, low cost, etc...

Don't instantly dismiss opportunities when they arise if they aren't perfectly aligned with (somewhat naive now I look back) expectations. Take some time to assess the pros and cons.

For example, in the mid 80s I attended an interview for a development position where it soon became clear that significant CFD methods development was outside the scope of the project. So it turned into an amiable chat about their software, the methods they were currently using, where they were going with the project and where I was going with CFD software development. In the corner was a chap listening but not contributing. When the interview was over he introduced himself as the owner of the company and wanted to discuss the possibility of setting up a CFD company in which I would hold 49% and look after the technical side and he would hold 51% and look after the rest. To my regret I didn't even consider it. Different times.

Far too much focus on technical aspects of the software. What grows support is improving what clients can achieve and the technical performance of the CFD methodology is only one aspect.

Awesome explanation Andy! Thanks for your help! :)
Have a wholesome meme.

Dear Andy:

I might not be as seasoned as you, but you have indeed jogged a lot of fond memories from the good old days for me.

I started out in the days when Computational Dynamics was still a garage gig. I have also come to know individuals who worked (and still do) for Fluent (back then still in Lebanon) and TASCFlow, back then they were all tiny compared to what they have now become.

These days are definitely very different. The focus is no longer on the flow physics, but the integration of CAD, CFD and FEA into the entire product development cycle. And all that happened within 20 years!

Those were the days, my friend.

P.S. - On the part about focussing on the technical side. No matter how good you are technically, at some point of your engineering career you will be asked to switch to sales.

Gerry.

Dear Gerry,


Being able to describe and sell our work to the client (i.e our boss, or an actual client) is probably one of the most important skill we can have. Many people become successful with no technical skills, but with sometimes unethical sales techniques. They will move a paper weight and say they moved a mountain. Everyone knows a guy or girl like that. I don't blame them, they're using the skill they're superior in.



Now imagine what could a technically capable person do, if he/she became good at selling their work.



Everyone's in sales. Everyone. Some just don't know it. :)


Here's a life changing tutorial : https://youtu.be/IXXKqwrEql4


^ See what I did there?



Thanks and regards
~sayan