Some general comments and questions

[aikidoka]

Firstly I want say well done to Daniel for DWSim it's a good start and
it has covered a lot of ground.

Secondly, i'm somewhat mystified as to why we, and I saw we because if
I added up all the hours i've spent on this type of thing ill probably
regret it, why we bother to do this at all.

It seems to me that ultimately it's doomed to failure for a number of
reasons.

1. There is no shortage of commercial simulators of both the full
blown expensive variety and cheaper 2nd or even 3rd tier options.

2. All the major simulators are available freely as cracked versions,
if you want to go down that route.

3. The problem with the main simulators is accuracy in the
thermodynamics packages, not the features offered by the simulator.

Where then do the open source simulators help in this respect?

It seems that most of them are written in the authors favourite
language, for obvious reasons, without regard to who else knows the
language, then if you want to contribute, you have to learn a new
language as well, no trivial task for somebody working in their spare
time. And at the end of the day we are creating a second rate version
copy of a commercial package.

I don't understand who the target market is for type of product?

Another problem is the obscure languages that have been chosen in the
past, e.g. Python. I can see no obvious reason for choosing it.

Congratulations on Daniel for choosing VB as he rightly says its a
language understood by a wide variety of people.

My feeling is that all these packages are being developed by
enthusiasts, the problem with this is it is the nature of enthusiasts
to want to 'own' the package, if not legally then psychologically,
therefore true cooperation is by nature going to be very limited.

I recently contact one person about the possibility of cooperation and
the emails ran dry very quickly, i.e. after 1. I can therefore assume
that cooperation was not a high priority.

Right now i'm struggling to see any benefit of open source development
and a lot of negatives. If any open source project developed a unique
and beneficial feature that helped it to get used the commercial
packages would copy the code in an instant.

Sorry if this is negative, but I would to hear some positive responses
to give me some motivation to do something.

[KP]

Hi,

I've been reading this group (and its precursor) since the effort was
made to revive Sim42 some years. I am not involved with the DWSIM work
but I have been working on my own simulator project using the much
blighted (in this group) Python programming language (See Sim21.zip in
this group). Your criticism is understandable and I will try and offer
my reasons for working on an "open source" simulator and reference
your comments as well:

1. While there is no shortage of relatively inexpensive steady-state
process simulator, there is no knowledge transfer when using these
products. In my experience, companies that offer simulation software
go to great lengths to hide/obscure functionality from users. Open-
source software can help alleviate this problem. In addition,
engineering education has become such that simulators are essentially
blackboxes to many new users. I think this is a very serious problem.
Open-source software that is cleanly and simply written would help
raise the level of discussion among new users.

2. The piracy problem is endemic to software as a whole, process
simulators are nothing new in that regard.

3. Open-source thermodynamics would really be helpful to many users.
Many commercial simulators have serious thermodynamic flaws that are
simply not publicized and new users continue to happily ignore
consequences of bad thermo. Open source can help provide verifiable
and validated results.

All sucessful open-source projects are driven by a core of enthusiasts
and good software takes time and effort to produce. Working on this
project has really taught me a lot about engineering that I did not
consider before. I view this as a learning experience for myself and
others.

With regards to the programming language issue, I think it's largely a
question of what you're interested in. If you're just interested in
the engineering and getting something up and running, using a known
and tested technology/language is probably a good idea. I'm interested
in another route to development, so that's why I continue struggling
with Python and its ilk. The language is a opportunity to try
something new and different, not an obstacle.

In general, I think your criticism reflects the "problems" of open-
source software as a whole. There tons of sites out there that try and
answer that question, read them and come to your own judgement. My
study leads to me conclude that open source is beneficial, you may
come to a different conclusion.

By the way, if you're interested in something that most other
simulators don't have, look into contributing to the ASCEND project.
Somebody from that group posted here recently looking for help and
contributions.

I hope this is positive enough :)

[John Pye]

Hi all

Some good comments from KP here. I would like to add a couple of further
comments.

Firstly, about Python. It's open, first of all: the whole language is
open-source and runs on any platform you care to think of. That's
important because a lot of open-source aficionados don't use Windows.
Python has been around for 17 years - since 1991 (same as VB), and is
very mature and stable. It's used for everything from low-level file
processing to operating system applets to websites to GUI programs.
Together with numpy/scipy/matplotlib you have a scientific computing
language approaching Matlab, but with better GUI capabilities. If you
write in Python then you're not limiting yourself to Windows.

Secondly, about open source thermodynamics. I have recently been working
on a platform-independent software library for doing high-accuracy
thermodynamics using Helmholtz fundamental equations. It is intended
that this could grow to incorporate more fluids, and other types of
property relationships, and hopefully be of some use in other open
source simulators. If this of interest to anyone, the details are here,
let me know if you'd like to collaborate:

http://ascendwiki.cheme.cmu.edu/FPROPS

This library is written in C, so that it can be fast, and
platform-agnostic. It's currently wrapped for use in ASCEND, but
wrapping for use in Python or other languages will be straightforward,
using SWIG

DWSIM already seems to have some pretty nice thermo capabilities; I'm
not sure how well this would mesh with that, but I'm happy to give any
assistance I can.

Cheers
JP

[aikidoka]

Thanks for the replies guys, I forgot to mention one aspect, here in
the UK if I get of my butt and develop something remotely related to
engineering, even if its 100% in my spare time, using my own computer
etc. The source automatically belongs to the company I work for,
regardless of whatever GNU or other license I stick on it. (there was
a recent test case in the involving some financial trading software
which was written in 'spare time' the guy lost the case). In not sure
what the legal situation is in other countries but its probably the
same in many places.

This has always been a tricky situation ever since I wrote my first
object oriented simulation program back in the late 80's, the source
code, although of no interest to my sponsors, probably languished on a
floppy somewhere until the floppy became no longer usable, that's what
happened to my copy. Not really a big deal as it was more of a
prototype than a real program. It languished as the copyright didn't
belong to myself anyway.

More positivity, the only way I see open source simulation really
working is if there are several projects each focusing on a specific
aspect , e.g. interface, thermo, distillation, reaction models, etc
etc. This would have a number of advantages.

[Matt Henley]

That is something you must review BEFORE you start on a project.  Where i live (Texas), its not automatic but it is not unusual to have such a clause in your employment contract.  In the US the legalities of that also vary by state. 

The last employer that I worked for had such a clause (it was a small British company) and I had them attach a clause stating that software not specifically written for my company and on my equipment remained mine.

I am definately not a lawyer and the laws for such vary a lot so its very important to understand that before you commit code.



Matt Henley

[chris_dk]

Choosing language based on popularity is very shortsighted. In my
opinion Python is much better than VB; it means fewer lines of code
and thus easier maintenance.

Also, VB.NET only runs successfully on Windows so that's another
disadvantage. I have filed bugs for the VB.NET specific bugs in dwsim
and they have not been fixed yet.

In my opinion a successful long term free software / open source
project is characterised by the following things:

1) A benevolent dictator settting the course and overall design of the
project
2) Active community involvement
3) Companies paying for enterprise versions (Mysql), lots of money in
support (RedHat) or a company backing like Sun do it for OpenOffice

Number three is especially important if the project is going to reach
more than a handful of enthusiasts, IMHO. That's also why I think a
project like Ubuntu cannot be called successful yet (what happens if
they fold). This point is however something that can take a long time
so one shouldn't give up after one year.

Regarding KPs point regarding knowledge transfer / hiding of
functionality from the user: IMHO dwsim is more or less the same.
However, there's a very good reason why simulators are the way they
are today: because of usability / graphical models that everyone can
easily understand.
I have been thinking about this last point some time now. If you don't
hide the functionality but makes the user use a command / text
interface he looses touch with the overall flowsheet calculation. If
you make a graphical ui with drag and drop the user will get a better
overall feeling with the results / flowsheet because he can
immediately see the effects of a change. This is my experience from
seeing my colleagues work with both types of simulators.

The ideal simulator would be easy to understand and make it possible
for the user to go under the hood and see the governing equations.

Software is hard. Joel Spolsky says it takes 10 years to make great
software so it demands a lot of effort and endurance.

[aikidoka]

I would argue differently in that lesser known languages are harder to
support, it's harder to find people other than yourself to help with
the effort. I've looked at the sim42 code and personally i find it
easier to rewrite stuff in C# than to bother learning to use python,
which i would not regard as a mainstream language. I dont care
that .net only works on Windows because thats what most people use,
most of the time. It also has the advantage that i can use Fortran,
VB, C#, C++ or a number of other languages in the same program without
a lot of effort, hopefully thereby re-using old code with minimal
effort, an important consideration when your doing this as an unpaid
hobby.

[chris_dk]

On Oct 3, 10:00 pm, aikidoka <manders...@hotmail.com> wrote:
> I would argue differently in that lesser known languages are harder to
> support, it's harder to find people other than yourself to help with
> the effort.  I've looked at the sim42 code and personally i find it
> easier to rewrite stuff in C# than to bother learning to use python,
> which i would not regard as a mainstream language.  I dont care
> that .net only works on Windows because thats what most people use,
> most of the time.  It also has the advantage that i can use Fortran,
> VB, C#, C++ or a number of other languages in the same program without
> a lot of effort, hopefully thereby re-using old code with minimal
> effort, an important consideration when your doing this as an unpaid
> hobby.

You can argue all you want. That doesn't help Daniel at all.

Only two people are working on dwsim; and that's with a so-called
popular language.

Most of free software is written in C, Java, python, perl and C++. Not
C#/.Net.

Anyway, if you don't see open source as viable then don't use or
support it.

[Matt Henley]

I would argue that the developers should use whatever makes them most productive in writing, documenting and maintaining the code.  Regardless of language, making the assumption you will get additional team members before you have a functioning and usable project is a fatal mistake.  Once you have a functioning and usable project, if people want to join the team they will learn the language. 

Why would you not regard python as a mainstream language?  What are your criteria for "mainstream"?  I have seen its use much more as a scripting language because it has very good interoperability with other languages such as C++, C 

and Fortran and it is interpreted.  

I can certainly name a lot more applications written in C or C++ than C#, VB or Delphi/Lazarus, but I wouldn't argue that any of those languages is not mainstream.  

Matt Henley

[aikidoka]

"Most of free software is written in C, Java, python, perl and C++.
Not
C#/.Net."

Thats exactly my point C, Java and C++ are all usable within .Net with
very little effort. Leaving the programmer to choose from several
languages that he is most familiar with.

I dont like 'obscure' (my definition) languages because i've seen
commercial simulator interface projects run into serious problems due
to the language that was chosen.

I'm not sure how to help daniel, because, with all due respect, im not
sure what daniel is trying to achieve.

On Oct 3, 11:15 pm, "Matt Henley" <nwm...@gmail.com> wrote:
> I would argue that the developers should use whatever makes them most
> productive in writing, documenting and maintaining the code.  Regardless of
> language, making the assumption you will get additional team members before
> you have a functioning and usable project is a fatal mistake.  Once you have
> a functioning and usable project, if people want to join the team they will
> learn the language.
> Why would you not regard python as a mainstream language?  What are your
> criteria for "mainstream"?  I have seen its use much more as a scripting
> language because it has very good interoperability with other languages such
> as C++, C
> and Fortran and it is interpreted.
>
> I can certainly name a lot more applications written in C or C++ than C#, VB
> or Delphi/Lazarus, but I wouldn't argue that any of those languages is not
> mainstream.
>
> Matt Henley
>

[Daniel]

aikidoka, any help is very appreciated.

Let me clarify some things about DWSIM:

1 - I develop it because I LIKE it, I have fun with it and I just like
equilibrium thermodynamics very much!
2 - VB.NET was chosen because it was easier for me (coming from the
Excel VBA world), simple like that;
3 - Initially DWSIM wasn't meant to be an open-source software.

Since the beginning I decided to use free tools only. So I discovered,
as everyone else here, how hard is to find anything really "free"
about thermodynamics and process simulation/modeling, something that
could be used in a project like this. I had to do all by myself,
reading papers again and again until I could understand and implement
them in DWSIM. One of the reasons that keeps me going on is the
satisfaction of seeing something that you never thought you could do,
like Michelsen's stability and flash algorithms, working and working
very well. In my opinion, the biggest challenge in the development of
DWSIM will be the Rigorous Distillation Column. I think I'm capable of
doing it, but sure it will take so much time of my life... and it must
be very well planned before I start to type the first line of code.

With an open-source project like this everyone can see how a graphical
process simulator works. You will quickly find how the GUI code logic,
the user interface itself, is way way more complex than the
thermodynamics behind it. In this aspect DWSIM is a mess, but thank
God it works reasonably well. If I was to start it now from the
scratch, sure I would do something more organized, more understandable
even for me... hehehe

Well, what is my objective with DWSIM? Right now it would be great if
it could be used for teaching purposes... it is nice to see a
simulator doing all its calculations and, even nicer, seeing HOW it is
doing them! What I don't like about commercial simulators is that you
have to trust what it tells you. If you wish to study how they work,
you are limited to know only what is written on the user manuals and
that's all. Of course you can have your engineering judgment on your
side, but this is very subjective and vary from person to person.

Even if you don't like it, you have to agree that the vast majority of
chemical engineering students uses Windows only, and Excel as the
primary tool for their needs. With DWSIM being written in VB.NET, its
code can be understood easier by everyone, not only us, developers.
They can even copy some thermo code and use it in Excel in very little
time, with very little effort.

But as I told you before, this is just a coincidence. And I'm sorry
for my english... always learning.

Regards,
Daniel

[chris_dk]

On Oct 4, 12:48 am, aikidoka <manders...@hotmail.com> wrote:
> "Most of free software is written in C, Java, python, perl and C++.
> Not
> C#/.Net."
>
> Thats exactly my point C, Java and C++ are all usable within .Net with
> very little effort.  Leaving the programmer to choose from several
> languages that he is most familiar with.

You can call C code directly from Python. Using Jython you can run
Python code using the JVM. Using the JVM you can also run Scala and
Ruby.

Also, if your project should be easily maintainable you would chose
one language to do 99% of the work and the rest in C for parts that
are performance sensitive.

.NET is nice but is not the great revolution you're advocating. In
fact it is an evolution of Java not a revolution at all.

Also, what examples do you have of simulators with big problems
because of the language?

It's very easy to pick on open source projects because everything is
transparent but the same software rules that apply for open source are
valid for proprietary projects as well. That's why questions like "why
is open source always so bad" are very narrow minded when you think of
the proprietary world with the recent Spore fiasco from EA, the worst
software in the world from McAfee and Norton and millions of Windows
machines that are controlled in bot nets sending massive amounts of
spam and holding companies hostage afraid of DDOS attacks.

[mande...@hotmail.com]

Who gives a flying f*** what language is developed from which. The fact is
that C++, C, VB, C#, FORTRAN are all more widely known, especially by
engineers than Python or Jython or whatever other obscure language you want
to mention.

The fact is that the top professional programmers all try and stick to the
most well known languages as that's where they tend to get the best Jobs and
it looks better on their CV.

I'm not going to give details of commercial projects an internet forum for
obvious reasons. But the fact is the more obscure the language, the less
support there is for it, so when you run into real problems in the real
world, its damm hard to fix them. Secondly, the more talented and
commercially minded people stick to the better known languages, because its
better for their careers.

The more obscure the language, the higher the development cost, the less
supportable it is, and the overall likelihood of failure is far higher.

--------------------------------------------------
From: "chris_dk" <sorensen.c...@gmail.com>
Sent: Saturday, October 04, 2008 10:25 AM
To: "Open source Process Simulator" <op...@googlegroups.com>
Subject: Re: Some general comments and questions

[mande...@hotmail.com]

Daniel,

I think our reasons for developing are quite similar, I like the maths also.
Also I was prompted by some shoddy work in a previous company and just
thought I could do it better, at the time I was a heavy user of sim software
and hated a lot of things about the way it had been done.

I have a very particular purpose in mind for what I want to develop but a
lot of the code is common, so hopefully I can do something which will help.

--------------------------------------------------
From: "Daniel" <dani...@gmail.com>
Sent: Saturday, October 04, 2008 12:58 AM

To: "Open source Process Simulator" <op...@googlegroups.com>
Subject: Re: Some general comments and questions

>

[Matt Henley]

Congratulations aikidoka/manders999!

You have managed to create a thread that illustrates one of the major problems with collaborative open source software development:  It is a whole lot easier to waste time arguing about the choice of programming language/program name/database format/icon set/mascot/color scheme/logo than it is just sit down and program.

Was this done just to prove a point or were you actually interested in an answer?  That's rhetorical, I really don't care why you bothered.  

Thanks for reminding me why learning 3D animation (blender.org - C/C++/python for scripting) is a much more enjoyable and rewarding use of my leisure time.

Matt  Henley

[aikidoka]

A couple of points:

It wasn't my intention to get into the language issue, obviously it
hit a few raw nerves.

I would say though that its obviously a pretty important decision if
you want to get something working and quickly, far better to spend an
hour or two debating a fundamentally critical choice, such as
language, that to head merrily off potentially down a blind alley and
waste hundreds or thousands of hours of programming. Everybodies
definition of blind alley will be different so lets not get into that
one...

Secondly, nobody is forcing you to read the thread, so why complain
about it wasting your time?...

Lastly I think its been quite educational for myself, because I agree
with you that it looks like cooperation is difficult to achieve in
that sense it achieved what I wanted, which was an understanding of
the psychology of the people doing this sort of thing.

As to sitting down and programming, most of my code already exists in
one form or another and this has helped me to decide were to take it
in future...

On Oct 6, 3:43 pm, "Matt Henley" <nwm...@gmail.com> wrote:
> Congratulations aikidoka/manders999!
> You have managed to create a thread that illustrates one of the major
> problems with collaborative open source software development:  It is a whole
> lot easier to waste time arguing about the choice of
> programming language/program name/database format/icon set/mascot/color
> scheme/logo than it is just sit down and program.
>
> Was this done just to prove a point or were you actually interested in an
> answer?  That's rhetorical, I really don't care why you bothered.
>
> Thanks for reminding me why learning 3D animation (blender.org -
> C/C++/python for scripting) is a much more enjoyable and rewarding use of my
> leisure time.
>
> Matt  Henley
>

> On Mon, Oct 6, 2008 at 4:28 AM, <manders...@hotmail.com> wrote:
>
> > Who gives a flying f*** what language is developed from which.  The fact is
> > that C++, C, VB, C#, FORTRAN are all more widely known, especially by
> > engineers than Python or Jython or whatever other obscure language you want
> > to mention.
>
> > The fact is that the top professional programmers all try and stick to the
> > most well known languages as that's where they tend to get the best Jobs
> > and
> > it looks better on their CV.
>
> > I'm not going to give details of commercial projects an internet forum for
> > obvious reasons.  But the fact is the more obscure the language, the less
> > support there is for it, so when you run into real problems in the real
> > world, its damm hard to fix them.  Secondly, the more talented and
> > commercially minded people stick to the better known languages, because its
> > better for their careers.
>
> > The more obscure the language, the higher the development cost, the less
> > supportable it is, and the overall likelihood of failure is far higher.
>
> > --------------------------------------------------

> > From: "chris_dk" <sorensen.christof...@gmail.com>

[John Pye]

mande...@hotmail.com wrote:
> Who gives a flying f*** what language is developed from which. The fact is
> that C++, C, VB, C#, FORTRAN are all more widely known, especially by
> engineers than Python or Jython or whatever other obscure language you want
> to mention.
>
> The fact is that the top professional programmers all try and stick to the
> most well known languages as that's where they tend to get the best Jobs and
> it looks better on their CV.
>

Again, Python is not an 'obscure' language. Of the around 16,000
projects monitored by Ohloh, there are around twice the open source
projects written in Python than in C#, and Visual Basic isn't even on
the radar:

http://www.ohloh.net/languages/compare?l1=csharp&l2=python&l3=visualbasic&measure=commits&percent=true

FWIW I think that 'professional programmers' tend stick to the Microsoft
platform, but the fact of the matter is that open source programmers are
a different group of people, with different goals from those people.
These people tend to choose Python, as the numbers above show.

You might want to look at this list, too:
http://wiki.python.org/moin/OrganizationsUsingPython

> I'm not going to give details of commercial projects an internet forum for
> obvious reasons. But the fact is the more obscure the language, the less
> support there is for it, so when you run into real problems in the real
> world, its damm hard to fix them. Secondly, the more talented and
> commercially minded people stick to the better known languages, because its
> better for their careers.
>

This birds-of-a-feather-flock-together seems equally to be causing many
open source people to cluster around Python, C, PHP, etc: free software
clumps together because you can put together free bits to make more free
bits. Likewise commercial software clumps together. I think that there
are two different world views here.

> The more obscure the language, the higher the development cost, the less
> supportable it is, and the overall likelihood of failure is far higher.
>

This just sounds like big business conservatism. Citations please!

Cheers
JP

[Craig Morris]

With regards to obscure languages and commercial simulators, I wrote
the first version of Hysim in a language called RatFor, which gave a C
like syntax to Fortran, which at the time was the "only" language
engineering programs could be written in. Later as C languages
adopted better floating point support, we rewrote Hysim in C, despite
being told it was inappropriate and a while later I did another port
into C++, which at that time was so obscure the only way you could use
it was with a preprocessor that generated the C++. That C++ version
of Hysim would eventually morph into Hysys. I think it is reasonable
to say that Hyprotech was reasonably successful in its day, despite
the seemingly continual use of what were then unusual languages for
the application.

Craig Morris

[Matt Henley]

Wow that brings back memories... i recall RatBas -- Rational Basic

[mande...@hotmail.com]

Craig,

I think they are fair comments. I also think you had the foresight to
choose a language that was destined to become the almost de-facto standard
for software development. If you had chosen another language we don't
necessarily know what the situation would have been.

Programs like Hysys have also raised the visual bar considerably, any new
program has to go from scratch to a similar standard, immediately to be
anything more than a curiosity. As spare time is limited, I personally
don't want to spend time on issues that are not productive, and the time
risk to me personally of adopting a new, lesser known language is relatively
high.

Anyhow this is a hobby, but its only fun if I get a good and working system
at the end of it.

I'm pretty much fixed on .Net for the moment, it has too many advantages
that can really help to speed up the programming effort.

--------------------------------------------------
From: "Craig Morris" <cr...@redtree.com>
Sent: Tuesday, October 07, 2008 1:40 AM
To: <op...@googlegroups.com>

Subject: Re: Some general comments and questions

>

[Daniel]

Matt's words in a previous message are pretty adequate for this
thread:

"My advice for anyone wanting to start on something like OpSim (or any
open source project for that matter):

Don't announce anything. Don't form committees. Don't take votes.
Don't spend time having long email discussions on the name, language,
database backend, requirements, license, etc.

Write code in whatever environment makes you productive.

When you have something that works for your minimum set of
requirements, announce it and let people adapt to your decisions if
they want to contribute. "

I think that this philosophy works well. Starting with version 1.3
source code, Prof. Samuel Cartaxo was able to implement a basic heat
exchanger without any problems. And in my opinion, it is harder to
understand something that is already done than do it for yourself from
scratch. Sometimes I rewrite my own code because I can't understand
some parts of it... and it ends better than it was in the previous
"version", because programming itself is a continous learning process.
That's what I like about it.

[mande...@hotmail.com]

All good advice and exactly the sort of thing I wanted to learn from this
thread. Thanks to everybody that contributed, so far.

--------------------------------------------------
From: "Daniel" <dani...@gmail.com>
Sent: Tuesday, October 07, 2008 2:01 PM
To: "Open source Process Simulator" <op...@googlegroups.com>

[paolog]

My twopence in an earlier post on a different forum

http://opensource.cheme.info/index.php/topic,26.0.html

Paolo

[Step]

KP wrote:
> 3. Open-source thermodynamics would really be helpful to many users.
> Many commercial simulators have serious thermodynamic flaws that are
> simply not publicized and new users continue to happily ignore
> consequences of bad thermo. Open source can help provide verifiable
> and validated results.
>

Some time ago I tried to write Cubic Plus Association (CPA) equation
of
state for OllinTS project. But stucked on incorporating the base cubic
EOS.
The association part is complete, the only what left to be done is to
connect
it to the base cubic EOS (in few places b_mix parameter of cubic EOS
should
be substituted). As I hadn't time complete it, I don't have any real-
life usage
examples, but only a piece of code (CPA.py) which I want to donate.
The code is closely based on article of Michelsen (Fluid Phase Eq. 180
(2001) 165-174),
and is documented. I also may consult what should be done to finish
it, or
may help.

File is named CPA.py

Waiting for suggestions.

Thanks.

[aikidoka]

I would like to understand this a little more. Write now im not sure
how open source helps this particular problem and exactly what these
problems are that are referred to. My usage is mostly around
Hydrocarbon/Oil pseudocomponents. The biggest flaw i am aware off
centers around interactivity parameters, especially with hydrogen in
the mixture were all/most of the simulators fair poorly. Would your
proposed solution help this? and if you modify an existing or use a
new EOS, do we have to start from scratch with interactivity
parameters? By the way i've been looking for way to estimate
interactivity parameters as most of the ones i have access to are
proprietary and can not be used as open source, as far as i am aware.

[Hazem]

Hi folks,

This is Hazem, the person who came up with the idea of reviving Sim42.

First of all, I would like to congratulate Daniel for accomplishing so much
and in a short period of time. Sometimes, I feel that some of the posts on
this group and designed to discourage him because he is so close to
succeeding.

Keep up the good work Danial, you are almost done.

Commercial simulators are expensive (please do not argue with me) they are
expensive for major corporations, small businesses, as well as individual
consultants. Furthermore, they have not offered anything new since 1998.
Actually, Hysys's Pinch utility is less useful now than it was during the
days of Hysim. Instead of adding things to Hysys, they are beginning to
take things out so they can sell you more add-ons.

The presence of an open source simulator capable of handling the major unit
operations will be sufficient for a lot of consultants and even many small
companies. Both entities will benefit a lot from an open source simulator.

However, the most likely effect is that the big commercial simulators will
feel the threat and lower their prices AND start offering more packages in
the same simulator instead of selling additional add-ons. Someday, I would
like to see a simulator with pinch technology, heat exchanger sizing, good
column sizing, line sizing, drum sizing and even costing.

Regards
Hazem

-----Original Message-----
From: op...@googlegroups.com [mailto:op...@googlegroups.com] On Behalf Of
aikidoka
Sent: Friday, October 10, 2008 3:15 PM
To: Open source Process Simulator
Subject: Re: Some general comments and questions

[Mark Anders]

I disagree somewhat with a few of these comments. My own view is that you
keep the simulator simple and functional and let the free tools from other
vendors do what they do best. No need to build in column sizing when you
can just export data and use the correct tool from the various column
internals vendors to do that. Indeed that's the way it should be done in
the real world for a variety of provenance reasons. I'm not sure I agree
that a good open source program will help to improve existing commercial
packages. If the purchase price drops a lot it wont be viable to spend
money on developing new features. Its development may virtually cease, why
spend huge amounts of money to develop a mature product when the price is
dropping, this is not good business sense and software development in the
real world is hugely expensive.

The simulator industry is a mature industry and there isn't much money in it
anymore.

Overbloated apps? not the way to go in my opinion, a number of smaller OS
projects seems more viable to me. These apps may be suitable for small
consultants. I think it would take a long time for them to be accepted in
industry as a whole. There are still many people in the industry that have
strong biases against some existing commercial simulators and a free
simulator will likely be regarded as a curiosity by many.

Again this is my view and trying to be realistic rather than optimistic or
pessimistic.

--------------------------------------------------
From: "Hazem" <Hazem_...@hotmail.com>
Sent: Saturday, October 11, 2008 2:05 AM
To: <op...@googlegroups.com>
Subject: RE: Some general comments and questions

[Step]

On Oct 10, 11:14 pm, aikidoka <manders...@hotmail.com> wrote:
> I would like to understand this a little more. Write now im not sure
> how open source helps this particular problem and exactly what these
> problems are that are referred to. My usage is mostly around
> Hydrocarbon/Oil pseudocomponents. The biggest flaw i am aware off
> centers around interactivity parameters, especially with hydrogen in
> the mixture were all/most of the simulators fair poorly. Would your
> proposed solution help this?

It's hard to answer. Accounting for association in EOS can help to
model complex mixtures where, for example, hydrogen bonds can from,
i.e. ether or alcohol
mixtures. It can also describe chemical reactions, where few molecules
associate (react) and form bigger molecule. So, if the presence of
hydrogen in oil promotes
appearance of associating complexes, it should help. But I can't
answer now how it is related to interactivity parameters.

[Step]

On Oct 10, 11:14 pm, aikidoka <manders...@hotmail.com> wrote:

> I would like to understand this a little more. Write now im not sure
> how open source helps this particular problem and exactly what these
> problems are that are referred to. My usage is mostly around
> Hydrocarbon/Oil pseudocomponents. The biggest flaw i am aware off
> centers around interactivity parameters, especially with hydrogen in
> the mixture were all/most of the simulators fair poorly. Would your
> proposed solution help this?

[chris_dk]

On Oct 11, 3:05 am, "Hazem" <Hazem_Had...@hotmail.com> wrote:
> However, the most likely effect is that the big commercial simulators will
> feel the threat and lower their prices AND start offering more packages in
> the same simulator instead of selling additional add-ons.  Someday, I would
> like to see a simulator with pinch technology, heat exchanger sizing, good
> column sizing, line sizing, drum sizing and even costing.

Hazem, I think it is best to focus on code quality, robustness,
usefulness instead of going head-to-head with the commercial
offerings.

I think Daniel has done a great job. Now we have a free software
simulator with a modern UI and lots of features. What we need now is
lots of user testing and some sort of community building so the
project keeps going strong.

The cross platform story is kind of bleak right now but that's a side
effect of .NET. Hopefully Mono will fix their VB.NET bugs.

[Daniel]

Hazem and Christoffer, thank you very much for your words.

IMHO when we are done with the rigorous column and heat exchanger
codes, we'll have all we need in terms of unit operations, and then we
can start to think about specific user needs like optimization,
process economics, specific property packages, etc. Sure we can't
forget about bug fixing... I always try to fix the ones that I find
during my tests ASAP, but I can't detect them all, and this is a point
where I really need help from the users.

Hazem, in the next version I'll include utilities to size Pressure
Safety Valves and Flash Drums (two/three-phase).

Regards,
Daniel

[Lynn McGuire]

Hi Daniel,

Are you building a two phase, two and a half phase or three phase
rigorous column ? What algorithm are you using - the same for all
four principal modes of a column: absorber, reboiled absorber,
stripper and fractionator ?

Sincerely,
Lynn McGuire

[Daniel]

Hi Lynn,

I haven't done anything yet in terms of code for the rigorous column,
but I'll use Russell's method which I think is two-phase only. I don't
know if it can be adapted to work with three-phase mixtures but if you
know anything, let me know please.

Regards,
Daniel

[Hazem Haddad]

Daniel,
 
If you did not start on distillation yet, may I suggest that you take a look at what is called the 'bubble point method' by Wang and Henke (attached).  It is also well described in Perry's chemical engineers handbook (these pages are also attached).
 
It will give you an idea about what is involved in rigorous distillation.
 
There is also myth about this method as many people claim that it does not work for wide boiling systems.  IT IS NOT TRUE.  It works, it just takes it a lot longer. 
 
There is also a misunderstanding with the inside out algorithm.  It is an approach, not a full algorithm and can be applied to any method such as the bubble point method.
 
No matter what algorithm you are using, the idea behind the inside out approach is to converge the problem using K-values that are temperature dependent but not composition dependent.  After convergence (this inside loop), update the k values using the compositions at each tray and get new k-values and iterate again (that's the outside loop).  See Russell's paper (attached).
 
Sources on this group who wish to remain anonymous pointed out that it also helps to "normalize" the problem;  Sum up all the feeds and divide each feed and side draw by this total. After convergence, multiply everything by the sum of the feeds again.
 
By the way, other anonymous sources favor the relaxation method.
 
Best of luck
Hazem
 
 
 

> Date: Mon, 13 Oct 2008 10:22:13 -0700

> Subject: Re: Some general comments and questions

> From: dani...@gmail.com
> To: op...@googlegroups.com

[Daniel]

Humm... I had a read about these methods in Kister's book. Thanks for
the articles.

I was thinking about the user input interface to the rigorous column.
The property grid in DWSIM seems insufficient for the amount of
information required. Do you have any suggestions?

Daniel

On 13 out, 17:42, Hazem Haddad <hazem_had...@hotmail.com> wrote:
> Daniel, If you did not start on distillation yet, may I suggest that you take a look at what is called the 'bubble point method' by Wang and Henke (attached).  It is also well described in Perry's chemical engineers handbook (these pages are also attached). It will give you an idea about what is involved in rigorous distillation. There is also myth about this method as many people claim that it does not work for wide boiling systems.  IT IS NOT TRUE.  It works, it just takes it a lot longer.  There is also a misunderstanding with the inside out algorithm.  It is an approach, not a full algorithm and can be applied to any method such as the bubble point method. No matter what algorithm you are using, the idea behind the inside out approach is to converge the problem using K-values that are temperature dependent but not composition dependent.  After convergence (this inside loop), update the k values using the compositions at each tray and get new k-values and iterate again (that's the outside loop).  See Russell's paper (attached).
>
> Sources on this group who wish to remain anonymous pointed out that it also helps to "normalize" the problem;  Sum up all the feeds and divide each feed and side draw by this total. After convergence, multiply everything by the sum of the feeds again.
>
> By the way, other anonymous sources favor the relaxation method.
>
> Best of luck

> Hazem   > Date: Mon, 13 Oct 2008 10:22:13 -0700> Subject: Re: Some general comments and questions> From: daniel...@gmail.com> To: op...@googlegroups.com> > > Hi Lynn,> > I haven't done anything yet in terms of code for the rigorous column,> but I'll use Russell's method which I think is two-phase only. I don't> know if it can be adapted to work with three-phase mixtures but if you> know anything, let me know please.> > Regards,> Daniel> > > > On 13 out, 12:01, Lynn McGuire <l...@winsim.com> wrote:> > Hi Daniel,> >> > Are you building a two phase, two and a half phase or three phase> > rigorous column ?  What algorithm are you using - the same for all> > four principal modes of a column: absorber, reboiled absorber,> > stripper and fractionator ?> >> > Sincerely,> > Lynn McGuire> >> > Daniel wrote:> > > Hazem and Christoffer, thank you very much for your words.> >> > > IMHO when we are done with the rigorous column and heat exchanger> > > codes, we'll have all we need in terms of unit operations, and then we> > > can start to think about specific user needs like optimization,> > > process economics, specific property packages, etc. Sure we can't> > > forget about bug fixing... I always try to fix the ones that I find> > > during my tests ASAP, but I can't detect them all, and this is a point> > > where I really need help from the users.> >> > > Hazem, in the next version I'll include utilities to size Pressure> > > Safety Valves and Flash Drums (two/three-phase).> >> > > Regards,> > > Daniel> >> > > On 12 out, 14:26, chris_dk <sorensen.christof...@gmail.com> wrote:> >> > >> On Oct 11, 3:05 am, 'Hazem' <Hazem_Had...@hotmail.com> wrote:> >> > >>> However, the most likely effect is that the big commercial simulators will> > >>> feel the threat and lower their prices AND start offering more packages in> > >>> the same simulator instead of selling additional add-ons.  Someday, I would> > >>> like to see a simulator with pinch technology, heat exchanger sizing, good> > >>> column sizing, line sizing, drum sizing and even costing.> >> > >> Hazem, I think it is best to focus on code quality, robustness,> > >> usefulness instead of going head-to-head with the commercial> > >> offerings.> >> > >> I think Daniel has done a great job. Now we have a free software> > >> simulator with a modern UI and lots of features. What we need now is> > >> lots of user testing and some sort of community building so the> > >> project keeps going strong.> >> > >> The cross platform story is kind of bleak right now but that's a side> > >> effect of .NET. Hopefully Mono will fix their VB.NET bugs.> >> >> _________________________________________________________________
> Get more out of the Web. Learn 10 hidden secrets of Windows Live.http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog...
>
>  1966_S_Wang_Tridiagonal Matrix for Distillation.PDF
> 2042KExibirDownload
>
>  Perrys 6th Edition 13-41.PDF
> 1981KExibirDownload
>
>  1983_S_Russell_A Flexible and reliable method solves single-tower and crude-distillation column problems.PDF
> 1555KExibirDownload

[mande...@hotmail.com]

Daniel,

Personally I really like the Property Grid in .Net, I think using this
feature is the single biggest time saver in the .Net framework and it gives
the user interface a unique look and feel that distinguishes DWSIM from
existing simulators. In fact I liked it so much its now the basis of my
code and it has saved huge amounts of time compared to the old multiple
levels of dialog way of inputting data and has enabled me to re-write an old
interface very quickly.

I can see what your saying about the amount of information you have to enter
but my view is that if you write the classes/collections/properties in a
well organized way the property grid should still be a nice way to enter and
view the data.

Least ways that's the way I am going to tackle it. If I get anything
working in C# ill send you the code, you can always decompile it into VB if
you want. Anyway you'll probably get it working before me.

Cheers

--------------------------------------------------
From: "Daniel" <dani...@gmail.com>
Sent: Monday, October 13, 2008 11:12 PM
To: "Open source Process Simulator" <op...@googlegroups.com>

[mande...@hotmail.com]

Forgot to mention that if you keep the number of trays/components small its
quite easy to set up the equations in a spreadsheet (there is a limit on
matrix size in excel) and check that its working before coding it up. That
way you can see what's going on easier.

--------------------------------------------------
From: "Daniel" <dani...@gmail.com>
Sent: Monday, October 13, 2008 11:12 PM
To: "Open source Process Simulator" <op...@googlegroups.com>

[Daniel]

Mark,

I also like the property grid very much... it facilitates everything.
But I'm thinking on how is going to be the interface for the user to
input stage information, specified variables, etc. I think it is
doable if I make a few custom editors with datagrids or listviews.

Anyway if you wish to know more about the property grid used in DWSIM,
check this page: http://www.codeproject.com/KB/vb/PropertyGridEx.aspx

Regards,
Daniel

On 14 out, 04:10, <manders...@hotmail.com> wrote:
> Daniel,
>
> Personally I really like the Property Grid in .Net, I think using this
> feature is the single biggest time saver in the .Net framework and it gives
> the user interface a unique look and feel that distinguishes DWSIM from
> existing simulators.  In fact I liked it so much its now the basis of my
> code and it has saved huge amounts of time compared to the old multiple
> levels of dialog way of inputting data and has enabled me to re-write an old
> interface very quickly.
>
> I can see what your saying about the amount of information you have to enter
> but my view is that if you write the classes/collections/properties in a
> well organized way the property grid should still be a nice way to enter and
> view the data.
>
> Least ways that's the way I am going to tackle it.  If I get anything
> working in C# ill send you the code, you can always decompile it into VB  if
> you want.  Anyway you'll probably get it working before me.
>
> Cheers
>
> --------------------------------------------------

> From: "Daniel" <daniel...@gmail.com>

[Samuel Cartaxo]

In my opinion, a combination of property grid and dialogs fired as custom editors may suit better the needs. Sometimes, a dialog provides a wider and much more organized view.

regards.

Samuel

2008/10/14 Daniel <dani...@gmail.com>

[chris_dk]

On Oct 14, 1:52 pm, Daniel <daniel...@gmail.com> wrote:
> Mark,
>
> I also like the property grid very much... it facilitates everything.
> But I'm thinking on how is going to be the interface for the user to
> input stage information, specified variables, etc. I think it is
> doable if I make a few custom editors with datagrids or listviews.
>
> Anyway if you wish to know more about the property grid used in DWSIM,
> check this page:http://www.codeproject.com/KB/vb/PropertyGridEx.aspx

Daniel, I would advise against dialogs because they are modal.

Modeless interfaces are generally better in that the user is free to
browse round the interface and not be locked into a dialog.

It is quite annoying to be in a dialog and you want to gather
information from somewhere else - like what was the number of trays in
that other column and have to dismiss the dialog to pursue that
information.

Anyway, I can recommend a good book on usability: About Face by Alan
Cooper

http://www.amazon.co.uk/About-Face-Essentials-Interaction-Design/dp/0470084111/ref=sr_1_1?ie=UTF8&s=books&qid=1224619561&sr=8-1

I have read About Face 2.0, pretty intriguing ideas, like eliminating
the file open menu entrys and implementing rollback etc into the app.

/Chris

[Daniel]

I agree with you Chris, but I was thinking about creating custom
editors to be used as drop-down editors. If I make such modal
interfaces for the column, DWSIM will end up looking like HYSYS, and I
want to avoid where possible that kind of interface...

I could make the utilities' windows dockable, what you think? In the
case of the simulation settings window, in my opinion it's better to
leave it modal.

About the book, it seems very interesting...

Regards,
Daniel

On 21 out, 16:08, chris_dk <sorensen.christof...@gmail.com> wrote:
> On Oct 14, 1:52 pm, Daniel <daniel...@gmail.com> wrote:
>
> > Mark,
>
> > I also like the property grid very much... it facilitates everything.
> > But I'm thinking on how is going to be the interface for the user to
> > input stage information, specified variables, etc. I think it is
> > doable if I make a few custom editors with datagrids or listviews.
>
> > Anyway if you wish to know more about the property grid used in DWSIM,
> > check this page:http://www.codeproject.com/KB/vb/PropertyGridEx.aspx
>
> Daniel, I would advise against dialogs because they are modal.
>
> Modeless interfaces are generally better in that the user is free to
> browse round the interface and not be locked into a dialog.
>
> It is quite annoying to be in a dialog and you want to gather
> information from somewhere else - like what was the number of trays in
> that other column and have to dismiss the dialog to pursue that
> information.
>
> Anyway, I can recommend a good book on usability: About Face by Alan
> Cooper
>

> http://www.amazon.co.uk/About-Face-Essentials-Interaction-Design/dp/0...

[chris_dk]

Creating custom editors is the way forward I think.

When you talk about the utilities windows, what do you mean?

Regarding simulation settings, I don't think it is that big a deal
because you are not spending so much time in the dialog anyway.

I think your overall design is very good.

Regarding HYSYS and Aspen, I think their UIs are pretty bad,
especially Aspen which is pretty unintuitive and convoluted.

/Chris

[aikidoka]

Does anyone have a copy of the Naphthali-Sandholm paper? I used to
have it but cant seem to find it anymore.

[Hazem Haddad]

here you go.

> Date: Wed, 22 Oct 2008 13:39:39 -0700

> Subject: Re: Some general comments and questions

> From: mande...@hotmail.com
> To: op...@googlegroups.com

[mande...@hotmail.com]

Thanks Hazem,

 

That's useful also but i was looking for the original 1971 publication by Naphthali-Sandholm, ill give this one a read through also though, thanks.

[Rahul Anantharaman]

Here it is.

Rahul

[Hazem Haddad]

oops.  SOrry, I attached the wrong file.  But Rahul came through :)
Thanks Rahul.
regards
Hazem

---

> </HTML<BR

[mande...@hotmail.com]

Thanks Hazem and Rahul!

 

That will help me a lot, I've still got some old C# code I wrote years ago but without the original paper I was struggling to make any sense of it.  Hope I can make some progress now!

 

Cheers

[Hazem Haddad]

Best of luck.
Please remember, the Inside Out is an "approach" and not an algorithm and can be applied to virtually any agorithm including N-S.

</HTML<BR

[mande...@hotmail.com]

Thanks,

 

I'm trying to re-create this method and others in excel, so I can easily do comparisons and try alternatives, i've got the Wange-Henke working and soon hopefully have the Tomich and Naphthali/sandholm methods working properly then I can play around with the Russell method and alternatives.

 

The thermo in the spreadsheet is very simplified and i need to add more components for realism (there is however a limitation on matrix sizes) but at least i can tell if its working or not and how many iterations they are each taking.

[Roberto Guillen Pinto]

Hi,

 

I don't know how much and what data you require for your routine. However, I thought you might find usuful this Excel spreadsheet I've attached with a physical properties database of about 100 components that I used for a flash calculation based on SRK.

 

Look at spreadsheet 'Base de Datos SRK', there you'll find component name, and second component name for the SRK BIP kij, critical temperature, critical pressure, accentric factor and molecular weight.

 

regards,

 

Roberto.

[Daniel]

Chris, I was talking about the utilities forms (critical point, phase
envelope, etc.), they are modal but I can make them dockable. Don't
know if it is of very use, but...

In the meantime, I`ll see if I can put icons for the unit ops in a
listview and enable drag and drop for adding them in the pfd...

Daniel