Solidworks flow simulation

There are validation examples in the documentation.

If there is still concern, setup some known problems and solve them.

If the software wasn't accurate, it wouldn't be on the market.

But note, accuracy is based on the problem setup and physics. If the physics of your problem cannot be solved with the methods used or your problem is setup incorrectly, you won't get good results. But I can say from my work with it, we have gotten within degrees for several problems.

I was told this from a Dassault employee who works in the simulation group, "we can get you 80% there with 20% of the effort." I really like this statement because, in my experience, it does a pretty good job of accurately portraying SW simulation (assuming you're trying to simulation something that SW supports). It does give rise to an important question: does the remaining 20% matter? Two acquaintances of mine that work primarily in thermal-fluid simulations and who are both competent engineers (one of them has a Ph.D. from a very prestigious US university where he developed CFD codes), have told me that they flat out will not use SW (and instead go with a much more expensive package). This could be due to valid, technical reasons, or some sort of bias; I can't say because I'm not a CFD guy. What I do know is that on the structural side, SW can only create tet elements, which for a h-version code seems rather odd.

The other thing you need to keep in mind (if you're publishing your work) is what others will think. Even if SW is just as good (or even better) compared to other simulation codes, but your peers in your field look at it as an inferior code, then their prejudices against SW will partly transfer into your research. As it so happens, I'm somewhat in the same boat as you, in that I'm currently in graduate school doing research where accuracy of the results from a code is paramount. However, I'll be using one of the lesser known codes (there's only a few codes that use the p-version), and the decision to use this code is a concern for both myself and my committee advisors, which is mainly due to how this code is perceived by others.

I would argue it depends on what you are doing. If you are investigating fluid flow phenomena then you shouls find a code that has the subtleties to resolve what you need to resolved. Might be Flow simulation but i doubt it. I can think of lots of flow phenomena that very few or no codes can adequately resolve without a direct appraoch and even then the Navier-Stokes equations don't even get a vortex core right so things can get interesting pretty quick. Laminar sepration bubbles might be another that is more than a touch tricky and might be better left to a wind tunnel.

On the other hand, if you are investigating some other device that operates in the presence of say conjugate heat transfer where perhaps the flow solution just needs to be consistent and close to some control then you might be OK.

However, that is just focusing on solving a problem. I wouldn't discount what Shaun has said about the "prestige" factor or other researcher/peer bias. And SWX marketing hasn't helped aiming all there efforts at easy to use and any engineer can use it, etc. It is only recently that they have produced some technical papers on how the code actually works (the codeis actually owned by Mentor Graphics and came to them via Flowmerics which acquired Nika way back whenever). If it helps you cause you could always call it Flow.EFD. The technology in Flow Sim is pretty good and in terms of productivity tis very hard to beat but it has limitations. The lack of drudgery is something people in the research/academic community just don't seem to care that much about and the derision seems unwarranted in many cases. Maybe it is all the cheap labour......