OpenFOAM acquired by SGi
 

Dear all.

I've noticed that OpenCFD has been acquired by SGi.

http://www.sgi.com/company_info/news...t/opencfd.html

would you please comment what will likley be the impacts of this on the future of OpenFOAM?

thanking in advance

best regards.

I always considered CFD Online as one of the main forums regarding OpenFOAM. To not see an official announcement here is odd. Therefore, I gather that SGI and OpenCFD are not really in touch with their user base. This does not bode well.

I just sent SGI a message concerning that lack of notification on this web site. Lets see how long it takes for them to respond, assuming they respond at all.

Greetings to all,

I guess I'll have to start off with the disclaimer that I'm in no way associated to OpenCFD nor SGI, nor should the following post should not be interpreted as professional views on this subject.
Now, on with my points of view :rolleyes:



:eek: Holy... no wonder the bug report side and the repos weren't doing much in the last few days since 2.0.1 was released... and I thought they would be on vacation... apparently they were in transition mode!
But this is sort-of weird... a couple of weeks ago, two forum users were having problems with building OpenFOAM on their SGI supercomputers...

OK, breaking down the news, the breadcrumbs are as follows:

• FAQ: http://www.openfoam.com/faq/ - the paid support side will remain the same, with added benefits... well, at least in experience and technological portfolio.
• OpenFOAM Foundation is now operational: http://www.openfoam.org/ - this is something that Prof. H. Jasak was pushing for... or at least is what I deduce from his presentation from a while back.
• The OpenFOAM(R) trademark is going to continue to be OpenCFD's... at least in the short term... I can't find any info on the long term... probably it will be SGI's sooner or later...
• Summing up what has been written at www.openfoam.com in the past and present, I think things will go along pretty much the same way as always...

Some theories (without going into conspiracy theories :rolleyes:):

• (:confused: ex-)OpenCFD should now have easier and extended access to various different hardware's, virtualization technologies (i.e., Linux on Windows or even bare-metal Linux) and whole lot more funding...
• This should expedite some new developments on OpenFOAM, like GP-GPU and RISC-like processors being officially supported. This would improve SGI's ability to sell über-clusters...
• (@Martin Hegedus) OpenCFD's drifting away from the community around OpenFOAM for the last couple of years or so could be considered as indicative that they consider the community to be already mature enough to hold on its own.
• The newly formed OpenFOAM(R) Foundation gives out a vibe of still being defined as to what it will really do. One reason I say this is because I can't find the whole list of the people on the Board of Directors...
• The new foundation seems to be more oriented to providing a gateway to the social coding provided at the OpenFOAM repositories in GitHub. Of course a lingering problem will be: who will officially take care of gathering the various contributions into a single repository... will it be the foundation or will it be the contributors themselves...
• I can only assume that the foundation should set better rules for forking, branching and contributions... but probably the current rules will still apply.

But this paragraph sort-of hits a nerve on the news release:As most news reports around the world, it lacks specific information... such as: "make their own contributions" to where and/or to whom?
Oh well, same old, same old :rolleyes: This is what the Internet is for :D I can only assume that GitHub's social coding is what they had in mind...

Best regards,
Bruno

I live in the Silicon valley, close to SGI corporate headquarters and NASA Ames. A big part of SGI business is HPC to DoD, NASA, etc. SGI also gets other types of funding from the US government and I doubt SGI can survive without it. CFD codes such as OVERFLOW, CFL3D, COBALT, etc. run on them. When SGI creates a supercomputer such as Pleiades http://www.nas.nasa.gov/hecc/resources/pleiades.html for NASA they work very closely with NASA to get NASA's codes running on it (compilers, debugging, etc.). SGI explicitly knows the coding details. SGI may not be able to add coding to OpenFOAM in a meaningful way due to U.S. government export restrictions (ITAR, etc.) Frankly, the last thing DoD, DoE, or NASA wants is details of their codes leaking out somehow. I doubt Henry Weller and company will be allowed to take OpenFOAM to the next level. I love this statement from Mr. Weller "The open source model provides customers with the code transparency and the full view into the inner workings of the software they need to have confidence in the results, particularly when they perform safety calculations for projects such as nuclear reactors or aircraft design." LOL, nuclear reactors and aircraft design? Sorry, I don't think so.

As another data point, I am writing a small CFD program for education use, etc., called AeroTroll CFD (www.hegedusaero.com/software). I was explicitly told by the US State Department that I need to get a Commodity Jurisdiction (CJ) to distribute my code overseas. And SGI is a US company. So the same rules apply to them.

I guess time will tell.

OK, then I'll a touch of salt of conspiracy theory:

• There are some breadcrumbs (in the git repos) that indicate that the current OpenFOAM 2.0 version is actually a direct descendent of 1.5 or 1.4, with 1.6 and 1.7 being parallel releases. I say this because some relics that were already dumped in 1.6, came back in 2.0. Additionally, while the git repo of 1.7.x has history tracking back to 1.6.0, the 2.0.x starts without past history.
• The new features in Star-CCM+ 6.04, parallel meshing with feature edges and so on, are also bleeding-edge features on OpenFOAM 2.0! And the release dates aren't very much far apart.

Now, legally there is no problem here, because the new features in Star-CCM+ might have had some help from OpenCFD and vice-versa. And the parallel development of releases is also part of the nature of software development.

So, core developments such as GP-GPU support and adding code that uses algorithms already published in one way or another, that will also not break the other legal bindings... well, this is probably business as usual. Or at least I hope so!

Thank you for your posts
 

Hello, we have indeed seen this post. The press release went out to a number of wire services around the world, and we appreciate the user who posted it here.

We also welcome (and will read) your posts concerning OpenFOAM, and will engage in these CFD Online forum discussions going forward.

With regards to the OpenFOAM community,

Ron May
SGI

Maybe. Lets hope so (edit, oops I should have written "Lets hope not". Bad grammar and in a rush. Sorry). But the fact is that if one cent of DoD money goes into this effort there is a very good chance it will be restricted.

For example, there is Chimera Grid Tools. http://people.nas.nasa.gov/~wchan/cgt/doc/man.html Seriously, there is no special technology in it. In fact NASA Ames would probably benefit if it was made open source. But it is restricted because DoD put a little funding into it. There is SUGGAR and DIRTLib. Again not exactly cutting edge technology. In fact the juicy parts probably comes from the computer graphics/movie industry. I know my overset technology does. Yet it is restricted because DoD put some funding into it.

OK, in the end, I'm a US citizen and I'll have access to the SGI version (edit: if it becomes restricted) of OpenFOAM if I want. So it is not really rocking my boat.

So, it is what it is.

My question is whether SGI has something in place to keep the US government operations and OpenFOAM development work separate? Also, did SGI get a CJ to distribute OpenFOAM? The statement by Henry Weller concerning Reactors and aircraft is a red flag. Where did he get that idea from?

It is stated under Item 16 Category II of the ITAR regulations,

"Specially designed software, or specially designed software with related specially designed hybrid (combined analog/digital) computers, for modeling, simulation, or design integration of the systems in Item 1 and Item 2 (see 121.1, Category IV(i) and Category XI(a)(6))."

"Note to Item 16

The modelling includes in particular the aerodynamic and thermodynamic analysis of the system."

I personally was never able to get the State Department to define to me "specially designed software". Note: ITAR does not say "software specially designed for"

Also note that duel use does not apply to ITAR. Regardless of what lawyers say. If a code can be used to design missiles, fighter aircraft, or launch vehicles, ITAR applies to it. Technically I don't think OpenFOAM falls under ITAR if it is distributed freely. Freedom of speech protects it. Also, ITAR makes exception to freely distributed technical data. However, I seriously doubt SGI is going to fight that battle with one of it's major costumers.

The creation of the OpenFOAM foundation is a positive and welcome fact, in my opinion. How it will evolve is still unclear, but I don't think it is correct, at this point to evaluate and speculate without knowing more about it.

I would invite members of the community to wait and see what happens, before starting a thread on all the possible negative outcomes. This kind of attitude just "poisons the air".

Some of us hoped in an OpenFOAM foundation for a long time, and this seems to be a good opportunity. Clearly, everything depends upon the conditions contributors will have to follow. It would be nice have clear requirements on how the copyright on contributions will be managed, for example. Will contributors have to transfer it? Or will it be kept by contributors? These are defining questions, I believe, and it is likely it will take some time to figure out these aspects (based on experience in other projects). Of course having a community that does not jump to the worst possible conclusion also helps a lot and keeps "the other side" motivated too.

Best,

From the literature? If you do a literature search, you can easily figure out that behind the study of nuclear reactor safety there are very standard algorithms, the basis of which are already part of OpenFOAM. The details (currently not available in OF) are well documented in the open literature, and a google search will give you access to the technical reports of specific codes like COBRA, RELAP, NEPTUNE and others. :D

First of all, thank for your input so far.

I'd Just like to add that i'm not necessarily scared by the future of openfoam. In fact, for the little i've understood, it might be the turning point to get more in touch with the community and reduce the need of the various forks, centralizing the "good" part of code developed by this astonishing community, smoothing out the learning curve, etc...

at lest this is what i hope for :p

OK, so your point is that I do not have a bases for being concerned. Let's hope you are right.

http://www.pmddtc.state.gov/complian...gingLetter.pdf

I got this from the RELAP web site.

"RELAP5-3D is subject to export controls. Membership in IRUG by non-U.S. citizens or organizations must have prior approval from the United States Department of Energy."

and

"The INL does not intend to propose restrictions on the commercial use of RELAP5-3D by IRUG organizations, although export control restrictions may limit or preclude the use of the code for certain countries, agencies, or companies. However, the commercial use will not extend to providing the code or modified versions to third parties without prior arrangement with the INL."

Or am I miss understanding something?

Hi,

I think we should follow the money!
One really big customer for many in the OF-ecosystem is Volkswagen and it`s brands (Audi, Seat ...). The question is will Volkswagen continue to be customer under such a new condition. An alternative is OF-extend?!?
Another potential big customer might be the the US Army/Navy.
Some money from the US Navy goes to Penn State's Applied Research Lab or to other Labs.
Does OpenCFD have the the chance to get government money

Not to forget the EU!
I think many in the OF-ecosystem are interested to get EU-Funding
and I heard that OpenCFD has a not very small project with some german companies co-funded by EU. Are EU fundings in danger under new conditions.

I will add some consiracy :-) as well.
it is a strike against PRACE (Partnership for Advanced Computing in Europe) http://www.prace-ri.eu
=> the European Petaflop project
Some Computer are delivered by Cray =>Cray XE6 systems will be installed at Gauss Centre for Supercomputing (GCS) & HLRS (High Performance Center of University Stuttgart)
and OF is some Software (as well as Code Aster) to run on this machines.

That's my point. Suggar and DiRTlib, http://www.outreach.psu.edu/programs...oack-ralph.pdf, come from Penn State's Applied Research Lab, were funded by DoD, and the libraries are restricted.

Export restrictions apply to a variety of specific applications. My point is that, yes, you might not have "reactorSafetyFoam" made directly available to you in the OpenFOAM release. This does not mean you do not have the building blocks in it, and that's the whole point about having a CFD toolbox.

In the specific case, what RELAP does is to solve the multiphase Euler equations, with heat and mass transfer. It is available in at least two of the largest commercial codes. Of course some addition might be required, but the largest part of what you need is there ;-)

Best,

OK, I understand all this.

But does the OpenFOAM community have an expectation that SGI, and the employees of SGI under their own time, will be providing unrestricted research, development, and V&V resources into OpenFOAM? And at the same time those employees will be doing work for the US Government?

If the stories I heard were correct, CFD Research, http://www.cfdrc.com/, was, umm, "influenced" by the State Department to separate their consulting and CFD R&D sides. http://www.cfdrc.com/news/84-cfdrc-a...sion-spin-off- I'll let the lawyers at SGI dig into this more if they want.

This is what the SGI site says:

"In addition to providing free downloads of OpenFOAM source code from the SGI-sponsored OpenFOAM foundation's openfoam.org web site, SGI will offer:

• A fee-based OpenFOAM support subscription to help customers implement and run OpenFoam in their environments.
• A fee-based, fully supported SGI OpenFOAM distribution, including SGI message passing interface (MPI). SGI® OpenFOAM® and SGI® MPI work together to provide the best performance possible.
• Training and professional services for complex CFD deployments on SGI and in other environments.

For companies that would like to start using SGI OpenFOAM today, the full capability is available via the SGI® Cyclone cloud offering."

I'm sorry, the dots just don't connect well for me. Unless SGI wants to create a complete separate entity to do this. Or, the idea is for the open source community, without R&D effort from SGI, to fully support OpenFOAM. However, that level of vibrancy does not seem to exist. A case in point is trying to find good detailed descriptions, and use cases, for the various OpenFOAM solvers. One can not find this information at the OpenFOAM wiki http://openfoamwiki.net/index.php/Main_Page.

I've always been concerned that OpenCFD's business model has inherent pressure against the user community: if you are funded by training and supporting users, then when users help other users, it undermines your potential sales. Therefore, you will want to reduce the resources available to the community.

I've always believed this to be the reason there isn't very good documentation out there - note especially the fact that OpenCFD shut down extend's documentation project.

-Dave

I just emailed Henry Weller at SGI and OpenCFD to find out if SGI got the blessing from the US State Department. I asked them to respond to this list. Hopefully we will hear back. Obviously the SGI lawyers should know about, and have a position on, export regulations since they deal with supercomputers and the US government.

In order to sum up to the entropy I also want to express my humble opinion about this topic. It looks pretty strange to SGI buying OpenFOAM, it sounds like OpenCFD started not to have enough funding or something like that, being bought by such a company like SGI is losing your independence. On the other hand OpenCFD launched a "commitment to the users" about remaining OpenFOAM as Free Software (http://www.openfoam.com/news/open-free.php). I hope they keep their word.

It wouldn't be strange for me that in a near future we could choose between a vanilla version of OpenFOAM and the full free (cost) version, like RedHat and Fedora. Even more, I think OpenCFD was doing that all the time with specially taylored solutions for their customers.

Regarding codes like RELAP, we use RELAP here in Argentina, but as somebody said its distribution is controlled by DOE, but it is not GPL licensed.

Regards.

There's a lot of negativity on this thread, it's cheered me up in a strange way! :D

Just wanted to pick up on this. Red Hat is behind Fedora in terms of features. It's supposed to be a stable version for corporations that don't like change. Red Hat customers pay for that stability and for future updates and support. If anything I think that's what you'll find happens with OF. When they consult or develop for a company, OpenCFD do their best to ensure the extra code goes into the Git repo, and you see the results of that quite clearly with the many additions to 2.0.

What sort of documentation? I've read plenty of papers that have very useful information in them. The Wiki has been good too, but it's a small number of people that contribute. And you can still find Alberto's excellent explanation of bubbleFoam's workings on the wiki! But that was a different discussion on this forum...

I hope that people don't think I'm contributing negativity. However, I do feel uncertain.

I was actually going in the direction of creating tools which rely on OpenFOAM. I realize that the pre SGI version of OpenFOAM will always be out there. And freely available. But I want to know where it is going. Realistically. And I'm trying to filter out any Wall Street marketing hype from SGI.

Edit:
Now that OpenCFD is owned by SGI, can SGI, or one of its subsidiaries, realistically do this given US export law and SGI's work with the US government? Or, is it completely up to the users now?

A full referenced manual like Fluent's one. What is the theory behind MULES for example?

Hope this new time of OpenCFD within SGI could bring new documentation. Documenting is expensive and takes a lot of time, maybe it was difficult to do that until know, but Dave concerns are totally logical.

Regards.

Martin, this is not accurate. Suggar++ and DiRTLib are NOT ITAR restricted. foamedOver, whose development was funded by DOD HPCMP, and also developed in my group, is ITAR restricted.

While there are many issues, I am sure that this will be an improvement across the OpenFOAM community, especially if SGI embraces the community to strengthen V&V, documentation, specialized modeling, education, etc., etc.

You are correct in that Suggar++ and DiRTLib are not under ITAR. That is why I did not write ITAR. However I was explicitly told they could not be used in a program which is put in the public domain. In other words, Suggar++ and DiRTLib are not in the public domain. Well, if I am wrong, that is wonderful! Or are you saying their restrictions are not based on DoD funding?

BTW, for everyone else, a software code may not fall under ITAR, but DoD can restrict it. Even though work paid for by the US government supposedly is in the public domain.

Martin, let's take the Suggar++/DiRTLib discussion offline. It is not germane to the discussion at hand.

Interestingly, at the 6th OpenFOAM-Workshop this summer, Bradley Kuhn of the FSF, briefly touched on the issues of ITAR and GPL. Bringing this thread back to the topic of SGI's ownership of OpenFOAM, Kuhn's talk about forming a healthily open-source community was well received by the Workshop. He summarizes his point of view here: http://goo.gl/XVNS3

As far as I know, ITAR does not apply to technical documents, and software source code falls under this category, which is placed in the public domain. And public domain means that one can, at most, charge an amount which is representative of the distribution fee.

However, and this depends on how one negotiates a contract with DoD (etc.), DoD can restrict the software and the intellectual property associated with that software. How much SGI can support OpenFOAM depends on how the SGI corporation is set up and what their government contracts say. Of course if SGI is selling a flavor of Linux, I doubt any of this matters. However, CFD technology is not in the same category as a flavor of Linux.

Or so I understand. And I can easily be wrong. I sure am not a lawyer.

A lot of CFD development is not funded by DOD, and goes on due funding from other departments and entities (DOE, NSF, ...), which want and push in the direction of releasing code as open source (you can imagine I absolutely agree with this, especially if the development is publicly funded).

Of course there are technical times to follow, which for academic people mean essentially waiting for publication, then clean the code up, prepare some example, maybe some documentation. In some cases you have to ask for authorizations and go through some procedure, however there is surely a lot going on in the direction of having open source code. This is true for multiphase fluid dynamics, and also for uncertainty quantification (my two areas). Just a quick example, I am at a conference where I presented my work on multiphase flows, which has direct applications to a variety of applications (nuclear, environmental, energy, medical, ...), and one of the first question from the sponsor (a gov. agency) was if and when I am planning to release the code. ;-)

This to say that this acquisition is not likely to block a significant number of developments, and surely it is not going to block the free distribution of OpenFOAM.

If you look at the presentations of the last workshop (I was not there, just saw the slides so please correct me if I am wrong :D), one presenter involved in restricted development for ship design was explaining, among the other things, their strategy to protect their code, and the conclusion was that they essentially do not share it, and have users access to it on a set of controlled machines. Essentially, if it goes out in the wild, not much can be done to control it, since it directly links to GPL code, and as such it is GPL code. So, in the end, OpenFOAM seems to suit the needs of both parts, maybe with some legal paperwork, but it is certainly feasible to have important developments going on and some critical part kept behind the scenes.

Just one detail about what you said on Linux: distributions are subject to export control due to encryption software. In theory the release for certain countries should not contain it.

Best,

Talking about muddied waters! Yes, if one steps in this, you may be bitten! Anyway, off topic. :) (Edit: a good link on your part between encryption software and CFD!)

Correct, I don't think US export regulations will block distribution of OpenFOAM. It also doesn't block individuals, and corporations, from donating public domain efforts to it which was fully, and solely, sponsored by that individual or corporation.

So lets hope that all this meshes with SGI's strategy and position. After all, they are sponsoring the OpenFOAM Foundation. So I assume there is a business strategy behind it. I also assume they did their legal homework. If this talk of restrictions changes the landscape, I assume the business strategy will also change. If there is a change in strategy, lets hope it does not affect the foundation.

Ron May, who I assume is Ronald May (Director of Corporate Marketing at SGI) knows about this thread. Therefore corporate officers, and their legal counsel, probably know about it. So, maybe we will get some clarity on this. And, we'll probably find out soon enough if there is a course change.

Just wondering, where does openform-ext stand, i mean it seems there are some features like ggi that are not available to openfoam (of opencfd).
Does it mean that user would be able to all these features too.

So guess my question is what would happen to other branches of openfoam.

Hello,

Hrv Jasak tried to adapt/customize the additional features of OF-Extend like GGI etc. to the next version of OpenCFD´s OpenFOAM.
OpenCFD never included extentions that came from the Extend-Community, maybe SGI is more open to include Developments made by Ext-Community, and that Hrv Jasak does not have to chase OpenCFD´s development direction to keep the Ext-Communty developments compatible to latest version.

I agree, but for me 'lack of' (because I still think there's enough out there to get going) documentation is not where I've been most frustrated in my use of OF.

For me, it's been writing code that I know other people (in academia at least because that's the only environment I know) have already written. Few academics are actually willing to share code development; it doesn't agree with the quest to improve their H index. And then when we publish our work (paid for by a taxpayer often), it goes into a closed journal where nobody reads it. Or if a company funds the work then they don't want the code to be released. I find the whole thing completely hypocritical, but nobody ever brings it up on here.

Hey guys, this is very very confusing now, how about this, that a separated OpenFOAM-Extend branch be set up on this CFD-Online forum, so that we could know where to post and contribute and where to ask and question?
Let those who has doubled energy take care both two, otherwise let's just FOCUS on one please.

Why not keep it simple, let each side go it own way?

I wanna being simple and away from distraction.

Virtually all Official OpenFOAM talk is relevant to OpenFOAM-extend, likewise visa-versa. The user-base is not clearly cut between the two either. Creating an OpenFOAM-extend-only forum would create a fence where we don't need one.

The extend team has done considerable work maintaining compatibility with Official OpenFOAM, and the result is that the user base has not fragmented... and is growing faster than it would otherwise.

Banning OF-extend discussion on this forum would work against this, and add pressure to break apart the user base.

With all due respect, I do not agree with you.

hmm.... On the contrary, I think by a clear depart this would strengthen the user base and make both healthier. So the contribution system and feedback cycle would be more effective and efficient.

Should the Extend keep chasing all the way to the end of the world?? Just in some hope to keep the user community unified??? Sigh..

I hope you are right.

But the reason I asked that is that long time ago Hrv posted something that got stuck in my head. May be I got wrong impression because of that. I had hard time finding that post but i finally found it.

http://www.cfd-online.com/Forums/ope...-openfoam.html

Here is his post:


From this post, I got the impression that Hrv wanted GGI to be part of extnd project only. This is why I asked the question that what happens to features that are NOT part of openfoam of openCFD.

How this whole thing going to go further.

I totally agree with the main idea behind this.

There is however another problem however, which is not negligible: releasing a code will cost you time after you release it, because you will start being contacted by its users to solve their problems. In other words, you will have to support it in some way. If you do not do that, releasing is quite useless, or it might be detrimental to you because the number of users who claim "it does not work" without having a real understanding of how they should set a case up is large (my personal experience).

Best,

I don't think this is the right moment to take a decision in this sense. I would wait to see the "guiding principles" and the rules of the foundation.

I would say that, maybe, this is an opportunity to finally have a way to contribute to OpenFOAM(r) without having two versions, so thinking of keeping things separate at this point seems a step in the other direction.

Hint: use the one that fits your needs better. ;-)

Best,