Now the Ansys purchase is all signed and sealed and the "assymilation" has begun, do you guys believe that this could be the beggining of the end of freedom of choice in industrial CFD. Ansys now owns 2 of the top 3 commercial codes and has the financial muscle to blow everyone else out of the way, they can throw massive resources at the codes, undercut the prices of all competitors and basically set up a massive microsoft style monopoly over the CFD market. People like CD-Adpaco, BRNI currently have a good foothold in the market but will they survive the inevitable full frontal assault by the ansys machine? Can they survive staying independent or will they have to get in bed with another big CAE provider (MSC, DSS etc).

Personally I am of the opinion that to challenge ansys one of them needs to be bought by someone with similar financial muscle. What does everyone think? Myself I am worried, it won't kill CFD but it is likely to be hammer blow to code choice.

CD will be next to go to a big CAD or big stress vendor. The question is, will consolidation kill innovation? Are there any paradigm shifts in CFD on the horizon? Not that I know of. It will take a disruptor technology to shake things up. That's some way off. So, settle down and bukcle up for a good old price war.

The big vendors have mopped up the top tier CFD applications. Focus is and will continue to turn to penetrating the mass market: mechanical design engineers. To achieve this maybe innovation will centre on automation resulting in the required usability to enable the next generation of CFD user to produce useful results.

Look out for automation in grid generation especially. CFD will never be purely gridless, but if the user needs not be concerned about it then effectively it will be...

I dont understand how the hell the Fluent purchase ever got past the competition regulators.

Bend over and prepare for skyrocketing licencing fees or get involved with open source CFD codes like http://www.opencfd.co.uk/openfoam/

Ansys etc all use pretty ancient codes & are thus in the commodity & consolidation phase of their lifecycles. I would imagine that the emergence of decent OpenSource initiatives will usher in a new era.

Do not despair...

They might start discontinuing the products which did not penetrate the market.Since there has already been a MS case.The same repeat might not be allowed.

Open source is a nice idea (a bit like communism ) but in real world industrial apps it will always struggle as companies keep very strict controls on versions and QA (quality assurance). An open source code will never be able to get through large OEM's QA procedures and as a consequence smaller companies (i.e. those that supply the OEMs) are unlikely to change too.

In this regard I think commercial codes are the only likely way forward or should I say commercial code singular.

The company behind http://www.opencfd.co.uk/openfoam/ provides the high level of commercial support that companies expect. That is its entire business model!

Claiming that only the closed propriety software development model can produce high quality software is disingenuous at best. The open source development model can produce software which greatly exceeds the quality of closed proprietary solutions. Simple example: Firefox vs IE

Your claim that open source software is incompatible with a companies internal QA is laughable. It is akin to claiming that companies don't use open source software which is nonsense. Many companies use open source software supported by commercial support contracts and thus don't even realise they are using open source software.

Open source development is a much better philosophical fit for CFD software development as it mirrors the build-upon-the-work-of-others open development of CFD theory. If academia didn't take the initiative to openly publish their model enhancements we wouldn't have the powerful CFD capabilities we have today.

You also give the QA of commercial vendors far too much credit. Closed commercial codes are plenty buggy as any CFD power user would know. Open source provides the opportunity to fix bugs immediately (either inhouse or through a commercial support contract) rather than sitting on your thumbs for months while some lethargic company gets around to releasing a service pack.

Open source codes also offer the option for immediate extension and enhancement to suit your company's specific needs while proprietary vendors only focus on features that will result in more license sales to the majority of their potential market.

Open source software backed by commercial support contracts is a wildly successful, rapidly expanding phenomenon. It has been very successful in other spheres of business critical software and it is now taking off in the field of CFD. About time too!

I never claimed that the open source codes were of a lesser quality than the commercial closed source ones, and nor did I argue that closed codes aren't buggy (i work with one so I should know) and I am also sure that large companies use open source software to some extent. BUT smy QA comment is entirely valid, although it depends on the level of integration of the code in the company itself, if the software is being used to produce numerical results (not just pretty pictures) that directly change the design (i.e. no interim physical test), which I know at least one of the largest car manufacturers does, then the processes will require full ISO (or equivalent) certification for the software used.

This level of certification requires incredibly strict testing, validation, version control, change control and so forth something that I am fairly certain OPEN FOAM doesn't have (the nature of open source development pretty much prohibits it). So although I am sure open source codes are very good, until they have full QA in place large companies are going to be reluctant to use them for anything other than pretty pictures, this isn't wild speculation on my part but is based on a in depth knowledge of how the OEM's work, what CFD software they use and how QA works.

As a CFD code end user, a company has zero insight into the real internal development procedures of that CFD code. The fact that a particular CFD code vendor claims that version x.xx of their software was developed to a particular ISO standard is ultimately worthless to an end user.

The only decision an end user makes is whether to use a particular code or not. The utility that an end user obtains from a particular code, open or closed, is not magically enhanced by the fact that a particular vendor claims ISOxxx development procedures. The utility obtained is derived from the underlying quality of the code which is not dependant on any particular development model.

Finally, using ISO procedures to document the application of external CFD codes to inhouse design problems is COMPLETELY independent of the development model of that code. Substituting a CD arriving at BMWs mail room from Ansys with a CD from OpenFOAMs support company doesn't suddenly derail BMWs internal documentation procedures.

You are claiming that an external software vendor's software development model somehow magically influences an end user company's ability to methodically document this external codes inhouse use and application. Laughable.

What exactly are you guys worried about? What really matters in the end is to get good quality (fast and accurate) CFD for a reasonable price. Are you worried about quality, price or both? Monopolies aren't good for either, but I wouldn't be too pessimistic.

The cutting edge of CFD has never been in the industry but in the research labs of academia and government, who will work on innovation regardless of who owns what company. If anything revolutionary should come out of their labs I have no doubt that the industry will incorporate it in their own codes for their advantage, or they'd see new advantaged competitors pop up.

In addition, CFD application customers are not to be compared with the masses of private and business people blindly accepting Microsoft just because it comes pre-installed on their PCs. Companies who depend on quality CFD cannot and will not take any crap from the CFD industry. There has always been (and always will be) the option to support a few people to write specialized CFD codes within the company. That's been done all along in companies that can afford it, and a lot of companies actually see this as more affordable than paying for expensive software licenses. These companies often also collaborate with academia on CFD application and development. There is much more to the CFD community than a handful of commercial and open source codes. Much of it may just not be very visible on the front page of "CFD review". No need to panic.

No I am not arguing that at all, what I am arguing is that it gives the end user protection and some degree of confidence that the code they are using conforms to a set of uniform standards, and that changes within the code are carefully controlled, tested and documented. It also keeps the manufactures ISO status secure as they are using certified procedure throughout again fully documented and tested. I'm not saying its a perfect procedure, not by a long chalk, but its as close as you are likely to get to it.

I'm also not saying its magical at all, I have a friend who works for a subcontractor of a large vehicle manufacturer running CFD analysis on components. The subcontractor has to conform to a strict set of guidelines from the OEM and use only approved software, this maintains consistency and accountability throughout the analysis process. It's not perfect but as long as analysis is used to directly influence design such controls need to be in place. The same applies to the software both the subcontractor and the OEM purchase by having a certification such as ISO they know that a certain level of QA is present. As I say, the ISO system is not about quality of end product so much as it is about accountability and repeatability, such things may exist in the open source environment but big companies need a nice rubber stamp on everything to make sure they are taken to court every time something goes wrong.

You say it is laughable but you seem to be making guesses and judgment calls here where as I am talking from direct experience within both the automotive industry (for two large OEMs) and the resulting contact with subcontractors.

But this is all beside the point, this discussion is about the ANSYS merger, if you would like to argue about the relative merits of open source programming then feel free to open up a new tirade about it (whether you like it or not commercial CFD rules the waves at the mo). I would quite like to hear peoples concerns/comments about the COMMERCIAL implications CFD as an industry is faced with at the moment.

You have good examples of what will happen from the FEM and CAD worlds which reached the point CFD commercialisation is now at some time ago. MS is also a good example.

In all these cases when one company became dominant basic research and development of the software largely stopped because it had no commercial advantage. The experienced engineers left often to join small competing start up companies developing "next generation" approaches. The dominant company enjoyed large profits for the managers for a few years and then had to compete against the new companies with better technical products. In the CAD world the established companies failed miserably to compete and disappeared, the FE companies largely survived but MS has easily stomped on anything that looked like competition.

My guess is that CFD software as a particularly recognisable and important entity will recede to be a component of a computational simulation package. This is not much of a prediction because it has gone a long way down the road to happening already.

What is perhaps more interesting is whether the engineering industry looks to large software companies like ANSYS to provide expensive computational software which the engineering companies then has to match up with their own computational engineers. Or they look to an EDS-type organisation to provide the lot including the computational engineers. It is a bit more of a risky prediction to go for the latter but if this is the case then CFD evolution may be quite healthy as prices drop and a wider range of software has a wider market albeit at lower more competive prices than you will see from ANSYS.

Just speculation of course.

What you are saying is that if some salesman claims to have done XXX in developing a product you should automatically assume the product is really for unvalidated design applications. *laugh*

That's BS. How a code is created doesn't matter at all once it lands on your desk and you have to decide whether your company should use it or not. The onus is on YOU to asses whether it passes the grade, not have some salesmen tell you it passes the grade and you meekly acquiesce and sign the purchase order.

Procuring an effective CFD code isn't about who made it or how it was made but rather how you qualify and test it internally. If it passes a well designed internal validation procedure you start using it.

I manage the CFD competency at a fortune 500 company which uses a healthy blend of commercial, open source and academic collaboration codes. Our academic collaboration codes aren't developed to ISOXXX but they offer greater utility in many cases than either the commercial or open source offerings.

I would posit from your logic bereft arguments you are grasping at straws having hopelessly mired yourself in contradictory assertions. In fact I'm rather glad we don't employ a mindless cog like you.

Dear Jonas,

I think that some welcome members of this Forum are getting toooo excited and out of their chairs with this topic.

Calling people words/names is not the style of cfd-online.. Regardless of who might be right, accurate or objective..

Thanks, Opaque

When did I every say I believe what a salesmen says, but some form of certification provides the knowledge that certain levels of QA are carried out. This may not be so important in the States but over here in Europe quality control, especially for large companies, is key to their success (possibly why European and east Asian manufacturing is considered generally superior to American).

I am not sure how you wandered onto the academic or specialised code development as this was never in the discussion. I never said that ISO was the be all and all, just that for general purpose EXTERNALLY procured software, note that we are not talking about internally developed or highly specialised externally developed software here, the ISO standard can give a reasonable indication that the processes in place at the vendor conform to certain standards, whether you trust these standards or not is a judgment call.

You complain about me being a mindless cog (im glad you have claimed the moral high ground here) but you seem to just ignore the comments I make and just plow on with your point, the statements aren't contradictory, you just seem willing/able to read or understand them.

I dont know what this means, im a mindless cog

oh and can we just kill mr halls rambling and keep the main part of the thread, I would quite like to have a discussion about the topic in hand.....

We are forced by our bigger customers into being ISO certified. Then they complain that we can't add their new pet feature quickly enough and ask why. Sometimes I'd just like to say: "The procedures you force us to follow don't allow it".