[Martin Hegedus]

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.

[santiagomarquezd]

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.

[l_r_mcglashan]

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

Originally Posted by santiagomarquezd

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.
Regards.

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.

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.

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...

[Martin Hegedus]

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:

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.

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?

[santiagomarquezd]

Originally Posted by l_r_mcglashan

What sort of documentation?

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.

[egp]

Originally Posted by Martin Hegedus

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.

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.

[Martin Hegedus]

Originally Posted by egp

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.

[egp]

Originally Posted by Martin Hegedus

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

[Martin Hegedus]

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.

[alberto]

Originally Posted by Martin Hegedus

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 ), 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,

[Martin Hegedus]

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.

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.

[arjun]

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.

[elvis]

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.

[l_r_mcglashan]

Originally Posted by santiagomarquezd

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.

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.

[lakeat]

Originally Posted by elvis

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.

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.

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.

[marupio]

Originally Posted by lakeat

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.

[lakeat]

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

to break apart the user base.

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.

Hrv Jasak does not have to chase OpenCFD´s development direction to keep the Ext-Communty developments compatible to latest version.

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..

[arjun]

Originally Posted by elvis

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 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:

Originally Posted by hjasak

This is absolutely brilliant - thank you lordvon. Shame on me for not reading the forum.

I have had a feeling for a long time something like this is going on at OpenCFD: the features already implemented (at least one by me) are offered as:

" This functionality is not yet part of OpenFOAM but we have a
detailed plan to implement it and are looking for sponsors; would you be
interested in sponsoring this work?"

For the record, you can have the sliding interface and all other topo change + dynamic mesh code in 1.6-ext without charge, tested and working properly and with tutorials.

Thank you, it is wonderful to know what is going on... I have also heard that Icon are looking for people to work on GGI to put it into "their version" of the code and sell this to their customers. My solicitor (and Mark Olesen, no doubt) will be de-ligted by a wonderful written proof!

Hrv

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.

[alberto]

Originally Posted by l_r_mcglashan

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.

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,

[alberto]

Originally Posted by lakeat

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?

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.

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.

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

Best,