[hani]

Dear Alberto,

This message is written on behalf of the administrators of the OpenFOAM-extend project at SourceForge (note that this project is currently not affiliated with OpenCFD - it is a community initiative). It does not mean that we will take active part in this discussion, but we feel that we need to say that we are following the discussion and that we of course support community contributions such as the one by Holger. We also have a comment regarding your latest proposition:

What you are describing was exactly the purpose of the OpenFOAM-extend project. Please see the original slides on the OpenFOAM-extend project, from the second OpenFOAM Workshop: http://powerlab.fsb.hr/ped/kturbo/Op...Zagreb2007.pdf. OpenCFD was invited to be one of the originators of that project, but they politely declined.

You can see in the slides that the OpenFOAM-extend project is prepared for a review process, through the Forge directories. Until now this review process has not been activated and we try instead to keep the trunk as clean and bug-free as possible. Forging and Tagging to a larger extent is however something that would make sense, so we can still do improvements of the repository of course. Documentation in LaTeX format would fit perfectly into the same structure, where people can do preliminary work in the trunk, and Forge it when the documentation has been reviewed. The contributors would be acknowledged both by their names in the document, but also by their commit to the repository.

Initially, the OpenFOAM-extend project hosted a bug-fixed version of the OpenCFD release, but that was made obsolete by the git repository provided by OpenCFD with release 1.5.x. We are not aiming at reproducing features that already exist.

OpenFOAM users who would like to contribute to the OpenFOAM-extend project must ask the administrators for permission to do so. This is not something we like, but we feel that it is necessary in order to be able to maintain order and quality in the project. As we understand it, the documentation project wasn't completely open for people to do whatever they liked either, so we guess that you understand why we need this control.

Please read about the OpenFOAM-extend project and tell us what part of your suggestion is not already fulfilled. We are aware that an involvement by OpenCFD would be ideal to incorporate features from the dev-source into the vanilla release. They are always welcome to join the project, or to start a new similar project together with the community, making the OpenFOAM-extend project obsolete. We are however in no control of OpenCFD or any other people involved in the OpenFOAM CFD toolbox.

You have also privately contacted the OpenFOAM Workshop committee. The OpenFOAM Workshop is another community initiative, which is not connected to OpenFOAM-extend. Also in this case, OpenCFD was invited to be one of the originators of this activity, but again they politely declined.

Note that the OpenFOAM-extend project and the OpenFOAM Workshop are community initiatives that are currently not affiliated with OpenCFD. They are driven on a non-profit basis, and the purpose is to provide the community with two alternative ways to improve the code and share information related to OpenFOAM.

The OpenFOAM-extend administrators.

[lakeat]

Understood!

[alberto]

Dear Hakan,

thanks for your reply.

This message is written on behalf of the administrators of the OpenFOAM-extend project at SourceForge (note that this project is currently not affiliated with OpenCFD - it is a community initiative). It does not mean that we will take active part in this discussion, but we feel that we need to say that we are following the discussion and that we of course support community contributions such as the one by Holger.

I appreciate the explanation, even if I disagree on the approach, since I do not see how such an important part of the community can not take part to a discussion regarding the future of the project. However I can understand there might be reasons not to discuss in public, and I respect the decision.

We also have a comment regarding your latest proposition:

What you are describing was exactly the purpose of the OpenFOAM-extend project. Please see the original slides on the OpenFOAM-extend project, from the second OpenFOAM Workshop: http://powerlab.fsb.hr/ped/kturbo/Op...Zagreb2007.pdf. OpenCFD was invited to be one of the originators of that project, but they politely declined.

Yes. My proposal was an attempt to involve OpenCFD(r) again in a similar (or the same) project, with the additional conditions at their advantage I put (mainly the perpetual licensing terms to them, since it seemed to be one of the major problems that prevented them from accepting contributions). Of course it would be ideal to work all together on a single repository. Unfortunately, at the moment I did not receive any reply from OpenCFD(r) on this and on any other topic discussed in this thread.

You can see in the slides that the OpenFOAM-extend project is prepared for a review process, through the Forge directories. Until now this review process has not been activated and we try instead to keep the trunk as clean and bug-free as possible. Forging and Tagging to a larger extent is however something that would make sense, so we can still do improvements of the repository of course. Documentation in LaTeX format would fit perfectly into the same structure, where people can do preliminary work in the trunk, and Forge it when the documentation has been reviewed. The contributors would be acknowledged both by their names in the document, but also by their commit to the repository.

This infrastructure seems very functional for contributors to me, but it does not help new users and beginners (see after why).

OpenFOAM users who would like to contribute to the OpenFOAM-extend project must ask the administrators for permission to do so. This is not something we like, but we feel that it is necessary in order to be able to maintain order and quality in the project. As we understand it, the documentation project wasn't completely open for people to do whatever they liked either, so we guess that you understand why we need this control.

I have nothing against this requirement. It is actually correct to have some control on submissions to avoid problems and keep the project organized.

Please read about the OpenFOAM-extend project and tell us what part of your suggestion is not already fulfilled. We are aware that an involvement by OpenCFD would be ideal to incorporate features from the dev-source into the vanilla release. They are always welcome to join the project, or to start a new similar project together with the community, making the OpenFOAM-extend project obsolete.

The -extend project is very similar to what I was suggesting. I actually tried to merge the current existing infrastructure when thinking to my proposal, which was clearly oriented to involve OpenCFD(r) again in community initiatives. Extend is a very good initiative, and it solves most of the problems related to code contributions.

What I feel is missing, and this emerged from some discussions I had with friends and colleagues that use or tried to use OpenFOAM, is a single point of reference, where they can find information on how to start, and some documentation to learn how to become familiar with the code, what version to use to have a stable environment and certain features, ... In other words, a new user or a beginner has in front two realities, and it might not be straightforward to understand what he has to do, whatever release it picks (official or -dev).

Holger tried to put together something to address the problem of the lack of systematic documentation of the high level solvers, which is what I feel is desperately needed, and I frankly was surprised and disappointed when OpenCFD(r) attacked the initiative so aggressively.

My proposal was an attempt to find a way to have well organized community initiatives without worrying about legal aspects, and involving OpenCFD(r). At this point, the decision is neither mine nor of the community.

I have no interest in taking an independent initiative (I clarify just in case someone was wondering about that), since it would contribute to divide and confuse the community even more, and that's not something I want. However I'm surely willing to help to improve the current situation, and I will follow its development.

In the interest of the project, I think the problems related to the trademark should be solved once for all, in the most transparent manner. It is clear I would like OpenCFD to be part of this, but it is clear as well that a solution has to be found at a certain point, whatever their position will be, since it would be much worse to stick to the current situation, with all the initiatives under the threat of the trademark policy.

We are however in no control of OpenCFD or any other people involved in the OpenFOAM CFD toolbox.

I am well aware of this.

You have also privately contacted the OpenFOAM Workshop committee. The OpenFOAM Workshop is another community initiative, which is not connected to OpenFOAM-extend. Also in this case, OpenCFD was invited to be one of the originators of this activity, but again they politely declined.

I find it is quite hard to follow all these initiatives if they are treated independently. For example, it came automatic to relate workshops and -dev/-extend projects to the same people. Sorry for the misunderstanding.

Note that the OpenFOAM-extend project and the OpenFOAM Workshop are community initiatives that are currently not affiliated with OpenCFD. They are driven on a non-profit basis, and the purpose is to provide the community with two alternative ways to improve the code and share information related to OpenFOAM.

Yes, this was very clear.

Best,

[l_r_mcglashan]

Hello everyone,

Maybe I've gone crazy, PhDs can do that to oneself. I've just started to use Git, and I seriously think this could play a part in all this.

First, watch this talk;

Linus Torvalds on Git.

Arrogant, yes, but deservedly so. I thought that the part about trust was the best. A lot of this discussion seems to centre around the reliability of contributors (is the documentation they produce good enough/correct etc.).

Well, OpenFOAM uses Git. I can clone OpenCFD's version. But say someone writes their own amazing solver for something I'm interested in. I can pull their version (merge their openfoam with mine). If it's rubbish, I can junk it. If it's good, it will spread. The simple fact is that if a contribution is rubbish, it won't get very far.

I suppose this depends on the size of the userbase and whether people are willing to share their work. But I think this might be worth thinking about. It will work for documentation as well.

[gschaider]

Originally Posted by l_r_mcglashan

First, watch this talk;

Linus Torvaulds on Git.

Arrogant, yes, but deservedly so. I thought that the part about trust was the best.

Could you summarize for those of us who don't have the time to watch a 70min stream (even if it is Linus "No 'U' in the last name" Torvalds) ? Or at least tell us at which time the bits you're refering to happen?

[l_r_mcglashan]

It is rather long. Apologies.

12:15 and onwards for 10 minutes. There's also a transcript here: Search for 'audience laugh' on that page and read the next few paragraphs if you're interested.

[olesen]

Posting removed

[alberto]

Originally Posted by olesen

As for all the carping about OpenCFD being restrictive about trademarks etc. Well, yes they have a trademark that they need to protect against the risk of dilution and against the risk of misrepresentation/confusion (see point 5 of their policy). IMO an offering like 'www.openfoam-documentation.org' clearly falls into this category (besides obviously violating point 10 of their policy).

I'm sorry, but minimizing it to "yes they have a trademark" is a stretch in my opinion. It is true they have a trademark they must enforce, as required legally. But it is true as well they try to enforce it even on different names like "FOAM", on which they simply have no right, being a common name. They should have fixed that problem before establishing a trademark policy if they wanted.

Moreover, they refused to rediscuss the naming of the project to verify the compliance with their trademark policy. It is surely OK from a legal point of view. It speaks by itself when you claim you drive an open project too, especially since the initiative was very far from being commercial and competitive with them (is a sponsored documentation project feasible? who would pay to release documentation on the features he paid to include?).

Point 5 of their policy is funny. Do you imagine a Microsoft(r) .Net(r) or a Java(r) developer that are forced to define themselves "developer using Microsoft(r) .Net(r) developer" or "developer using SUN(r) Java(r) technology"? It is quite clear that if you are not associated formally with OpenCFD, you are not a developer of the official release, but you still develop that code. It seems simply another way not to recognize that important developments are going on outside of the main release, mainly because of their closure towards any kind of contribution not tied to a support contract. I frankly fail to see where the ideas of open source and open development are in all this.

Best,

[olesen]

Posting Removed

[alberto]

Originally Posted by olesen

If I follow your argumentation correctly, you would also claim that since 'windows' is a common word it couldn't be used for a trademark for anything?!?

If you however argue about common names and not common words, I don't know of any other use of "FOAM" as a name in the CFD area that would make it a common name.

"Windows" is a common word, and it is also a specific name of the container shown on your screen when an application is run, so it has a specific meaning in the IT area, and it existed before the specific operating system we are discussing about. As a consequence, the distinction does not apply in such a straightforward manner.

Technically a common word cannot be used alone in a trademark, and it is common practice to combine it with something else to create a unique trademark. In the US trademark system however, it is practically possible, essentially due to the absence of controls and of transparent rules, to register whatever you want, and this is at the base of the discussion about reforming patent and trademark systems.

Foam is a common name in general, and it is also widely used in physics, fluid dynamics and, as a consequence in CFD. Let's look at the definition of foam, again from OED: Foam: The aggregation of minute bubbles formed in water or other liquids by agitation, fermentation, effervescence, ebullition, etc). There are specific CFD applications that deal with polymeric foams too for example.

Looking at it from a strictly legal way, there is another important difference however: Windows is a registered trademark of Microsoft(tm), "foam" is not registered by OpenCFD(r).

[alberto]

For your information, I have not received any comment from OpenCFD(r) at this point, and I do not think at this point there is any interest on their side in finding a solution to the problems affecting the development of an active and growing community.

I think at this point any further community contribution should be oriented towards the only truly open community oriented initiative that originated in these years around FOAM. I am clearly talking about the FOAM-dev/-extend ( http://sourceforge.net/projects/openfoam-extend/develop ) initiative, where it is actually possible to take part to the development of the code, with the idea of creating an open code that can be a reference for the CFD community.

In my personal opinion, to make things easier and more clear to everyone, some additional step is necessary to

• protect the community initiative from future troubles
• give to contributors an easy and safe way to identify the project they contributed to, without any kind of ambiguity

In particular, I would suggest to rename the project and replace the logo, and to proceed to spread the new name and logo as an independent community initiative. To be clear, I would remove references to "FOAM" in the new name, logo and code, clearly recognizing the new project as a fork.
This step is painful and annoying, but at this point it is also necessary, since the trademark policy ( http://tarr.uspto.gov/servlet/tarr?r...entry=79040040 ) has very wide implications, and covers almost all the important activities around the code itself. In particular the policy applies also to

• educational activities, lectures, tutorials
• consultancy activities
• customization of the software

I think others and I tried to discuss, without any result, with OpenCFD(r) for quite a long time to find a solution together, in order to avoid this kind of decision. Unfortunately it was not possible, since no discussion actually started due to unilateral positions.

However, it is time to look forward, to build on the existing community initiatives, and to work on the expansion of the collaborative environment originated around the -dev/-extend initiatives and the workshops. Clearly the final decision on how to proceed exactly is not mine, since I am not associated with any of the involved parts, and moreover, because there is people active in these initiatives with more experience and involvement than me. On my side, I will support their efforts, and my contributions will more oriented in that direction.

Best,

[olesen]

Posting Removed

[alberto]

Originally Posted by olesen

Alberto,

Since you obviously have very strong opinions and have decided upon a particular course of action, I shall let the matter rest.

Dear Mark,

what you define "strong opinions" are the natural and direct consequence of the absence of any kind of reply from upstream developers to the issues raised in this thread, and before on the discussion board and during private communications.

Before easily concluding that I have strong opinions, you should make an effort with your memory, and remember that I was not exactly against the trademark policy OpenCFD(r) originally introduced. You and me discussed about it when it was introduced the first time ( http://www.cfd-online.com/Forums/ope...rk-policy.html ), and I was not exactly strongly opinionated.

I still think that the trademark policy could not be a problem if used correctly, and not against community initiatives without any commercial interest, as they did very explicitly. Unfortunately the attitude of upstream developers, and their openness to discuss of alternatives and shared solutions does not exist, and this leaves, in my opinion, no alternative to a fork, since, in the current situation, one part is clearly at a disadvantage with respect to the other.

We should not forget that upstream developers

• refused to take part to the documentation project, to which they have been invited before its initial launch.
• did not accept to discuss of alternative naming of the documentation project (even if they said they would have done that in emails).
• did not discuss on the proposal of creating a community repository for code contributions and documentation, with clear advantages to them.

In the light of this, what you read in my previous post is simply a natural and rational consequence, and not really an unmotivated and irrational strong opinion.

If you have other concrete proposals to make that might address some of the problems discussed in this thread, and you think might be accepted by OpenCFD(r), I think all the thread followers will be happy to read and discuss them. I will surely consider them carefully. Defending the current situation, at this point, seems pointless to me, since it seems quite evident it is unbalanced.

Best,

[zeliboba]

Originally Posted by alberto

Discussed solutions

• Forking the code, renaming it.
• Documenting the code replacing the trademark with another name.

it is already done, why you do not like http://freefoam.sourceforge.net/ project? they closely follow opencfd development and IMHO avoid trademark issue.

Originally Posted by alberto

• Users (all, without possibility of selecting them if the quality of the code is adequate) can submit working good quality code, reviewed by other community members (which means no additional work for OpenCFD(r), to clarify) with experience in the field. Code has to respect basic quality requirements, style, formatting. In the case of solvers, a tutorial case has to be provided.
• Users can submit documentation to the repository,...

this will not work: review by community members is time-consuming and inefficient. what is really needed for the code:
- good building system for fully automated build (again I refer to freefoam). this ensure that can be at least compiled without problem.
- unit testing framework (I did not find it in OF). this ensure that new code does not break existing code.
- solver needs not simple tutorial, but kind of validation test case with comparison against established analytical/experimental/numerical data. at least one can clearly see if solution is converged to the right result. this also can be considered as integral testing.
- style/formatting issue can be solved easily with GNU indent utility, choose any style and publish it.

unfortunately, documentation review is really manual process.

Originally Posted by alberto

• OpenCFD(r) can take the code it considers worth to include in the main official release from the repository according to their needs, and without any obligation to do so, or to maintain the code available in the repository.

btw why do you want to have code in "official" release? does opencfd trademark or words "official release" ensure higher quality? for me the described tests are better insurance.

OF-dev community is rather good model. bit bulky but acceptable. I'd prefere them to move repostory to git and have better technical integration with opencfd and freefoam branch

[alberto]

Originally Posted by zeliboba

it is already done, why you do not like http://freefoam.sourceforge.net/ project? they closely follow opencfd development and IMHO avoid trademark issue.

How does it workaround point 11 of the trademark policy ( http://www.opencfd.co.uk/trademarkpolicy.html ), which is what they use against "foam-documentation.org" and "The FOAM documentation project"?

this will not work: review by community members is time-consuming and inefficient.

It depends on what you mean with review. In my opinion a CFD code needs, ideally, to be reviewed by someone before being published. In the end it is supposed to be a scientific project, and as a consequence some sort of revision becomes necessary. Of course the revision process becomes much easier if the developer provides a working test case with a trivial configuration so that the implementation is shown to work, and the main file contains references to the literature where the implemented technique was developed.

what is really needed for the code:
- good building system for fully automated build (again I refer to freefoam). this ensure that can be at least compiled without problem.

I agree, but we are not far from that in OpenFOAM(r) already. If you exclude some glitch with paraview/parafoam, the compilation of the code on Linux workstations is very easy.

- unit testing framework (I did not find it in OF). this ensure that new code does not break existing code.

I'm not an expert of this. Would this be easy to implement? Require many code modifications to the existing code? Affect performance? Could you point to some framework to do this?

- solver needs not simple tutorial, but kind of validation test case with comparison against established analytical/experimental/numerical data. at least one can clearly see if solution is converged to the right result. this also can be considered as integral testing.

This is music to my hears, since I have been saying the same for a while. It surely takes a lot of time, and in some case it is quite hard to find cases with analytical solutions. There are a number of interesting databases however, that can provide a lot of validation cases (ERCOFTAC, iCFD, ...) Comparing to experiments is a test for the physical model, not for its implementation. It is extremely important too, but it is a step further.

- style/formatting issue can be solved easily with GNU indent utility, choose any style and publish it.

Without any doubt. It takes a few minutes to set it up in whatever good code editor if the rules are set

btw why do you want to have code in "official" release? does opencfd trademark or words "official release" ensure higher quality? for me the described tests are better insurance.

Since we are talking about a community project, I think it is right to at least try to put parts together to address problems, and that what I tried to do, clearly without much success. There is no quality implication in my use of the word "official": there is good work going on both in the official release, and in -dev/-extend one.

OF-dev community is rather good model. bit bulky but acceptable. I'd prefere them to move repostory to git and have better technical integration with opencfd and freefoam branch

Could you explain how you would integrate branches better? Are you suggesting to add a branch with freefoam and create a unique repository with the official, -dev and freefoam releases?

Best,

[zeliboba]

Originally Posted by alberto

How does it workaround point 11 of the trademark policy ( http://www.opencfd.co.uk/trademarkpolicy.html ), which is what they use against "foam-documentation.org" and "The FOAM documentation project"?

it is better to ask experts, but I do not see anything that can be used against freefoam.

Originally Posted by alberto

It depends on what you mean with review. In my opinion a CFD code needs, ideally, to be reviewed by someone before being published. In the end it is supposed to be a scientific project, and as a consequence some sort of revision becomes necessary. ...

you expect to much from (open-source) code :-) scientific project can be based on the code, support and development of the code should not be a scientific project (ok, maybe computer science project). btw, above one of OF-dev members said "this review process has not been activated", OF-dev exists for at least 2 years, so forget the review. code should be compiled without errors, pass unit tests and integral test. it should be a robust tool, leave the rest for scientists.

Originally Posted by alberto

I agree, but we are not far from that in OpenFOAM(r) already. If you exclude some glitch with paraview/parafoam, the compilation of the code on Linux workstations is very easy.

I have really different opinion (see here). and again: freefoam already have proper build system.

Originally Posted by alberto

I'm not an expert of this. Would this be easy to implement? Require many code modifications to the existing code? Affect performance? Could you point to some framework to do this?

I'm not an expert either... basically it helps not to introduce new bugs, when fixing old. to your questions:
- easy/difficult is relative category
- most probably no
- no. there is nothing to do with performance, unit testing is performed on compilation/installation stage.
- personally I do not use any at the moment, you better check wikipedia

Originally Posted by alberto

... Comparing to experiments is a test for the physical model, not for its implementation. It is extremely important too, but it is a step further.

do not see the difference between analytical solution and experiment for the purpose of integral testing. at least correct input should give correct output. and you need to know how correct output look like.

Originally Posted by alberto

Could you explain how you would integrate branches better? Are you suggesting to add a branch with freefoam and create a unique repository with the official, -dev and freefoam releases?

first, it should be git, not svn. if I understand it correctly, currently OF-dev team implement all new feature from upstream manually. this is stone age. with git it is possible to do it (semi)automatically. it saves man-hours and (more important) reduce possibility of errors caused by copy-paste. see discussion here and here

if OF-dev converted their repository to git, then you can easily include/remove any branch, OF-dev to OF or vice versa. merge any patch to any branch, do (almost) whatever. true flexibility is possible. of course to really achieve this flexibility everyone need to follow git rules and practice for commits, but this is not a rocket science. (well, I have to note that opencfd practice is far from ideal or even good: separation 1.5 and 1.6 repositories is something)

[alberto]

Originally Posted by zeliboba

it is better to ask experts, but I do not see anything that can be used against freefoam.

Yes, it is better to ask. I might be stubborn, but I would avoid any reference to <put_whatever_here>Foam

• to explicitly distinguish the initiative and clearly state that it is a fork
• to avoid any further problem

you expect to much from (open-source) code :-) scientific project can be based on the code, support and development of the code should not be a scientific project (ok, maybe computer science project). btw, above one of OF-dev members said "this review process has not been activated", OF-dev exists for at least 2 years, so forget the review. code should be compiled without errors, pass unit tests and integral test. it should be a robust tool, leave the rest for scientists.

Well, I strongly disagree on this, but I'm supposed to be a scientist .
I think basic review and validation has to be done, or it becomes too expensive in terms of time and money to do it by yourself everytime you use the code, and at that point you look at other solutions, sometime commercial sometime open, where this is done. The complexity of the review process can be easily reduced:

• Limiting it to new features.
• Forcing the contributor to provide one or a few simple cases with basic physics that is respected

I would add that contributions do not come in huge quantities, so with some time investment it is possible to activate a review process.

A review process is not extremely necessary if the group of contributors is trusted (even then, we all make mistakes!) and relatively small, but if the number of contributors grows, it becomes a must to avoid quality problems.

I have really different opinion (see here). and again: freefoam already have proper build system.

I understand what you mean! I tried to package OpenFOAM in RPM's, and doing it the right way is painful!

I'm not an expert either... basically it helps not to introduce new bugs, when fixing old. to your questions:
- easy/difficult is relative category
- most probably no
- no. there is nothing to do with performance, unit testing is performed on compilation/installation stage.
- personally I do not use any at the moment, you better check wikipedia

do not see the difference between analytical solution and experiment for the purpose of integral testing. at least correct input should give correct output. and you need to know how correct output look like.

The difference is the following: the analytical solution to the model you are implementing (if it exists) is exact, and your code should give you exactly that solution. If you simulate an experiment, you are not sure your model represents the physics involved in the experiment. This is especially true for complex models (multiphase, reaction, combustion, ...). Moreover, what experiments? What kind of error does affect them?
Both kind of works are OK, but to check if the numerics is correct and the model is implemented correctly, it is much easier to find an elementary case where you can define the analytical solution, and use it.

first, it should be git, not svn. if I understand it correctly, currently OF-dev team implement all new feature from upstream manually. this is stone age. with git it is possible to do it (semi)automatically. it saves man-hours and (more important) reduce possibility of errors caused by copy-paste. see discussion here and here

if OF-dev converted their repository to git, then you can easily include/remove any branch, OF-dev to OF or vice versa. merge any patch to any branch, do (almost) whatever. true flexibility is possible. of course to really achieve this flexibility everyone need to follow git rules and practice for commits, but this is not a rocket science. (well, I have to note that opencfd practice is far from ideal or even good: separation 1.5 and 1.6 repositories is something)

We should ask why exactly SVN was chosen, but if I remember it right, it was because it allows atomic commits. I actually find git more efficient myself.

Best,

[olesen]

Posting Removed

[PattiMichelle]

I've been reading the posts and am also saddened by the stance of OF folks. I have looked at funding combustion-code source modifications through them, but now I'm becoming leery of doing that since I might loose the code I "buy."

I have to say that there is a real issue about the learning curve for OF if it gets fragmented into various forks - a noob like me may not find even how to get started! (i.e., what to download, how to set up .cshrc - or not! - how to compile - or not! - etc., etc., etc.) I'm my own sysadmin, laboratory worker (I hate changing vacuum pump oil, but my laboratory won't run without this) and still have to write papers and attend conferences...

One of the blessings of OF was that it was easy to install and get test-cases running. In reading all these posts I can see that ease slipping away. (I have no idea what "git" is though I've been using opensuse for years - but it doesn't sound friendly...) Please, let's keep the newbies and pseudo-sysadmins in mind when designing this - or else new folks will bounce off the confusion-bubble surrounding (some new fork) and opt for (inadequate?) commercial software... as I have in the past for other opensource software.

Patti

[alberto]

Originally Posted by PattiMichelle

I've been reading the posts and am also saddened by the stance of OF folks. I have looked at funding combustion-code source modifications through them, but now I'm becoming leery of doing that since I might loose the code I "buy."

I have to say that there is a real issue about the learning curve for OF if it gets fragmented into various forks - a noob like me may not find even how to get started! (i.e., what to download, how to set up .cshrc - or not! - how to compile - or not! - etc., etc., etc.) I'm my own sysadmin, laboratory worker (I hate changing vacuum pump oil, but my laboratory won't run without this) and still have to write papers and attend conferences...

One of the blessings of OF was that it was easy to install and get test-cases running. In reading all these posts I can see that ease slipping away. (I have no idea what "git" is though I've been using opensuse for years - but it doesn't sound friendly...) Please, let's keep the newbies and pseudo-sysadmins in mind when designing this - or else new folks will bounce off the confusion-bubble surrounding (some new fork) and opt for (inadequate?) commercial software... as I have in the past for other opensource software.

Patti

Thanks for your post, because I think it reflects what many new and not so new users think.

I would not jump to the conclusion you will lose your code, developed using a support contract, if a fork takes place. First, an official release will still exist, and your code would work there. Second, at least initially, a fork won't be much different from the official release, as a consequence a port, if required, would not take much time and effort.

The whole idea behind the documentation project is to make the code more accessible and more friendly to users, reducing the learning curve. I would not support an effort in the opposite direction, since it would mean contradicting what I have been saying for years.

I do not think a fork will lead to a significant change in the user experience, especially for newbies. If a fork will take place, since no other solution will be found, I promise that I will take care of making installation and system configuration process well documented.

About Git, we are on one side discussing of it to simplify contributions. Git is already used by OpenCFD(r) to provide code fixes after a major release (for example, 1.6.x is hosted in a git repository). From a user perspective, git requires you to know two commands:

git clone

and

git pull

Once the code is downloaded from the repository, the same procedures used to compile OpenFOAM apply, without any additional difficulty.

Best,