My previous posting regarding the baseline being cluster ready, made me realize that it would be useful to have a single requirements document that we can work from. If you need some help with that let me know. I have a boiler plate doc ready that we can start filling in (From Leffingwell and Widrig: Managing Software Requirements).
Also what will be the apps we'll use for documents? Do we want to be Unix compatible so no MS formats?
Well, any help is welcome ! So if some afordable guidelines are available and if you have some clues on doing a manual (am I right ? ) or a guideline document containing architecture and physics, than it would be a tremendous thing !
For the documents, we intended to be Linux (UNIX) compatible only (for scientific purposes and easy maintenance). So fellows like LaTeX are more than welcome...
An OpenFlower Admin.
Yep, I have some suggestions how to get started. I can put together a requirements document and forward that to one of the admins. I would suggest that we go with an OpenOffice format since it is installed on the RH distributions. That way any RH distribution can be readily used for the documentation. Secondly, OpenOffice can generate MSOffice formats so we could generate those from the same base documents for releases.
Secondly, I really like to keep docs and code together so I am a big proponent of javadoc and doxygen. If we would like to generate the code documentation we would need to make a decision on what doc generation system to use.
Thirdly, Linux is great but there is a benefit to be cross-platform. So the code and its build process should IMHO be Linux and Windows. It is not that much extra work, but it increases the quality of the code since you get two different interpretations of your code and a much wider audience. If you want to be cross platform, it is best to start early. I strongly suggest it is baked into the orginal requirement set.
And finally, you are correct, I would be interested to contribute to the 'manual'. Open source without good documentation is useless, I believe in that enough that I can take on that job.
I think OpenOffice is a good idea because it allows also to windows users to read document in its original format, but LaTeX gives better quality documents above all for equations, it's easier to mantain beacuse you define a style and it's directly applied to your documents, it is available also on Windows, and you can always generate a pdf, which is readable on all platforms.
I shouldn't be really difficult to port C++ code to windows too.
Well the idea to do a document with OpenOffice is ok for us. THe think is that we believe that the quality will not be very good. Another important point is that we think it is best to make available to users a document in pdf format than Word or OpenOffice. So if there is an easy way to do it, then it's ok for us.
But I think we will discuss about the choice of LaTex vs. OpenOffice shortly, because as the user AP suggests we can define a general document style that will be used for every document easily.
As for the compatibility with Windows platforms, it's ok for us : the only thing is that someone has to do it ! And here, the main development team has only access to Linux OSs. Anyone who wants to deal about this particular point ?
Considering a manual, we were really thinking about doing one because we believed it was the key issue of such a code.
Doxygen seems good for us !
See you soon.
An OpenFlower Admin
After some discussions with the other admins, we have come to the conclusion that it would be by far easier and better to create the manuals in LaTeX : we can manage the sources directly using CVS and it will be mainly used by scientists that use LaTeX on a daily basis.
So, I think we will go for a LaTeX version...
I think latex is the best choice.
Porting openflower to windows should not be too difficult if it will be fully written in standard C++.
Microsoft Visual Studio can handle it, and also qt librairies are available for free also for Windows.
I forgot to say, I think it's too early to think to a windows port.
In my opinion, in earlier development phases it should be better to work on a single platform, in order not to lose time.
It's my opinion too concerning LaTeX and portability to Windows.
See you soon,
Though I can see that visible progress is necessary at this early stage of the project, in order to spark enthusiasm from potential volunteers, I am also thinking that Theodore is quite right suggesting that Windows portability should be at least in a requirements spec or vision spec early, for those reasons he has mentioned earlier.
Surely a tricky issue for any admin team! (But less so if a volunteer happens along who is particularly interested on helping out with a Windows port.)
I am very interested in the openflower project. I can help with the portabilty to Windows, since I do not have a Linux OS.
Why did the project choose C++ and not simple C language? I just ask because I usually use C rather than C++.
Well, thanks a lot for visiting us. We are happy that you would be interested in working on making the software available for Windows platforms.
Why did we choose C++ rather than C ?
Mainly because C++ is an "extension" of C, and because it is becoming the standard in OO programming. We could also choose Fortran (because it is more efficient for scientific computations... even though it is less and less true) but no f90 compilers are freely available. And it is also true that what is done in C++ can partly be done in C as well... but it is much more complicated ;-)
I like your idea for a planning document. I think it will be a valuable contribution. It will very helpful for any new person trying to see where the project is headed, and how they might be able to help. Also, it can be used as a point-of-reference for discussion threads, etc, on suggestions for possible future directions for the project.
The planning document is a really good idea.
I still believe that Windows portability is not a problem if the code is developed strictly in C++.
Portability problems may apper when developing the GUI and the graphical post-processing tools, but I don't think it's a good idea to integrate all these things in the solver.
Better to have separate tools, in order to keep the code light and clean.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.