I have spent a large part of my life working on process simulators and I have for quite some time now thought about starting a Sourceforge open source chemical process simulator.
I have had a look at yours and while it is encouraging and I applaud your efforts, I would like to start a serious discussion around the following topics:
- Why Pascal? You can get a C++ (GCC) compiler for just about any platform and I think C++ is more suited for some of the complexities you will face. I do not think Pascal is as main stream, or standardized or mixable with other languages? Most of the open source packages that are available for Lunix or Windows is in C++ so that you can compile the package for whatever linux version you are on. They all have C++ but not Pascal.
- What framework (for the GUI etc) are you planning on using? Obviously you need something that is relatively platform independent. I know Firefox using GTK++ (C) and I was thinking of using that, but I have been playing with wxWidgets and I think that would be the best framework since it is open source, platform independent and quite powerful and well supported. It is C++. It could be done in Java, but Java is too slow for serious large scale numeric code.
- What about a thermo databank provider? I am curious about where you got the current one that you have? I was thinking of asking DIPPR for example for a test database.
- As for the flash code that is in your code currently, Rachford Rice is totally insufficient for any real practical flash. It convergence is poor and by no means assured. You need a flash algorithm with phase stability testing (Michelson's) and appropriate multiphase support and intelligent convergence acceleration.... Writing a flash is not trivial, and I speak from a lot of experience. I have not seen any open source flash code but I need to look some more. Of course ideally your flash must be restartable (continue from a previous solution or suggested solution if one is available) and various specifications (PT, PH, PV, PS) need to be supported. Any simulator needs a very very decent flash!
- What about extensions? Are you aware of something called CAPE-OPEN? Have you looked into a free simulator called COCO? It is far more advanced but not open source. I was thinking of talking to them and seeing if it could be made open source. COCO is nice but some of their unit ops need serious attention. The problem with being platform independent is that you can only use what is common to all platforms, and CAPE-OPEN is COM based (so no using it on lunix). Also, you want people to be able to easily add their own property calculation methods or unit ops by just typing some code right inside the simulator. There are free macro languages that can be embedded. We need to look at how Firefox plug-ins work exactly.
- Speaking of COM... Will the simulator user interface and engineering models be separate? I think there are many advantages to that approach, though it has to be correctly done. Will it have an OLE interface (though thats not possible if you want to run natively on lunix)?
- You also need to decide if your unit ops are going to be equation based (I saw some mention of that in the mixer) or sequential modular (solve one by one). Open equation is of course the rave, but once you have massive systems, you can have problems solving. I think the middle road is the solution here: Allow models to be written equation based (though not the thermo and dont go overboard) and have the main system be able to either solve simultaneously or sequential modular. This gives you the most freedom and flexibility.
- You will need a distillation model for sure and writing one is not trivial, but I am fairly sure we can get some existing starter code somewhere...
- Sourceforge has a lot of powerful math routines and libraries. Since this would be an open simulator, one of the first things I would do is to get some of those so they can be used in the code.
I understand that you need something to get people involved and get it off the ground, but having a good longer term vision and some serious code is essential.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given that you prototype has been downloaded something like 583 times, there is definitely a need for this. Consider how many other open source packages have grown and become huge successes! You just have to get to the critical mass point where it is useful and people can easily extend it.
I also think the simulation market is ready for this. I could go into the politics of which company is doing what, but lets not go there.
If I did win the lottery Id quit my job tomorrow and start and open source simulator. I wonder if one of these large engineering companies would sponsor a serious effort?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have spent a large part of my life working on process simulators and I have for quite some time now thought about starting a Sourceforge open source chemical process simulator.
I have had a look at yours and while it is encouraging and I applaud your efforts, I would like to start a serious discussion around the following topics:
- Why Pascal? You can get a C++ (GCC) compiler for just about any platform and I think C++ is more suited for some of the complexities you will face. I do not think Pascal is as main stream, or standardized or mixable with other languages? Most of the open source packages that are available for Lunix or Windows is in C++ so that you can compile the package for whatever linux version you are on. They all have C++ but not Pascal.
- What framework (for the GUI etc) are you planning on using? Obviously you need something that is relatively platform independent. I know Firefox using GTK++ (C) and I was thinking of using that, but I have been playing with wxWidgets and I think that would be the best framework since it is open source, platform independent and quite powerful and well supported. It is C++. It could be done in Java, but Java is too slow for serious large scale numeric code.
- What about a thermo databank provider? I am curious about where you got the current one that you have? I was thinking of asking DIPPR for example for a test database.
- As for the flash code that is in your code currently, Rachford Rice is totally insufficient for any real practical flash. It convergence is poor and by no means assured. You need a flash algorithm with phase stability testing (Michelson's) and appropriate multiphase support and intelligent convergence acceleration.... Writing a flash is not trivial, and I speak from a lot of experience. I have not seen any open source flash code but I need to look some more. Of course ideally your flash must be restartable (continue from a previous solution or suggested solution if one is available) and various specifications (PT, PH, PV, PS) need to be supported. Any simulator needs a very very decent flash!
- What about extensions? Are you aware of something called CAPE-OPEN? Have you looked into a free simulator called COCO? It is far more advanced but not open source. I was thinking of talking to them and seeing if it could be made open source. COCO is nice but some of their unit ops need serious attention. The problem with being platform independent is that you can only use what is common to all platforms, and CAPE-OPEN is COM based (so no using it on lunix). Also, you want people to be able to easily add their own property calculation methods or unit ops by just typing some code right inside the simulator. There are free macro languages that can be embedded. We need to look at how Firefox plug-ins work exactly.
- Speaking of COM... Will the simulator user interface and engineering models be separate? I think there are many advantages to that approach, though it has to be correctly done. Will it have an OLE interface (though thats not possible if you want to run natively on lunix)?
- You also need to decide if your unit ops are going to be equation based (I saw some mention of that in the mixer) or sequential modular (solve one by one). Open equation is of course the rave, but once you have massive systems, you can have problems solving. I think the middle road is the solution here: Allow models to be written equation based (though not the thermo and dont go overboard) and have the main system be able to either solve simultaneously or sequential modular. This gives you the most freedom and flexibility.
- You will need a distillation model for sure and writing one is not trivial, but I am fairly sure we can get some existing starter code somewhere...
- Sourceforge has a lot of powerful math routines and libraries. Since this would be an open simulator, one of the first things I would do is to get some of those so they can be used in the code.
I understand that you need something to get people involved and get it off the ground, but having a good longer term vision and some serious code is essential.
Given that you prototype has been downloaded something like 583 times, there is definitely a need for this. Consider how many other open source packages have grown and become huge successes! You just have to get to the critical mass point where it is useful and people can easily extend it.
I also think the simulation market is ready for this. I could go into the politics of which company is doing what, but lets not go there.
If I did win the lottery Id quit my job tomorrow and start and open source simulator. I wonder if one of these large engineering companies would sponsor a serious effort?