Russell's "Inside-Out" method article / Updates on DWSIM

[Daniel]

Hello guys,

Does anyone have Russell's article on multicomponent distillation
modelling entitled "A flexible and reliable method solves single-tower
and crude distillation-column problems" (Chemical Engineering 90
(1983), pp. 53–59)? I've already bought Kister's "Distillation Design"
book that describes this method very well, but it would be good to
have the original article in hands.

Why do i need this? DWSIM is missing a few unit operations to simulate
heat exchangers and towers to be a "complete" process simulator.
Support for reactive systems are almost done, as i've already
implemented Conversion, CSTR and PFR reactors.

To let you informed about the DWSIM development progress, i've removed
the dependence of the two COM DLLs that were being used to do some
parameter fitting (pseudocomponents and hypotheticals) and some matrix
operations (true critical point calculation). I've added the methods
available in the ALGLIB project (www.alglib.net) - converted the C#
code to VB.NET - and now the simulator is 100% managed code. No need
to be an administrator to install and run it anymore.

After that i need to translate the documentation to english and add
some useful context-sensitive help system... then you may have a
complete open-source process simulator sooner than you think... hehehe

You can view some screenshots of the simulator with the latest
features added here -> http://dwsim.inforside.com.br.

Thanks in advance,
Daniel

[chris_dk]

On Jun 21, 3:33 pm, Daniel <daniel...@gmail.com> wrote:
> Hello guys,

> To let you informed about the DWSIM development progress, i've removed
> the dependence of the two COM DLLs that were being used to do some
> parameter fitting (pseudocomponents and hypotheticals) and some matrix
> operations (true critical point calculation). I've added the methods
> available in the ALGLIB project (www.alglib.net) - converted the C#
> code to VB.NET - and now the simulator is 100% managed code. No need
> to be an administrator to install and run it anymore.

Great news. This would make it possible to use on Linux as well if P/
Invoke is not used at all.

> After that i need to translate the documentation to english and add
> some useful context-sensitive help system... then you may have a
> complete open-source process simulator sooner than you think... hehehe

If its going to be open source, why not open it already? Also, have
you considered a license?

Best regards,

Christoffer

[Daniel]

Hi Dinu,

On 22 jun, 08:46, Dinu <din...@hotmail.com> wrote:
> You will have to buy  it: Russell,R.A., "A Flexible and Reliable
> Method Solves Single-Tower and Crude-Distillation Column Problems,"
> Chem. Eng., October 17, 1983, p.53.

Where do I buy this article?

> How long did it take to get here with DWSIM? I am curious because I
> also have done a similar effort in the past, with uncanny similarity,
> I had also posted the same query in a different forum asking for the
> Russell IO paper! I did go on to implement the column, but I had to
> buy he paper first.

About 2 years ago I had some equilibrium routines in Excel VBA and at
that time, i've started thinking about making my own simulator, but
didn´t have any knowledge about graphics programming and the internal
structure of a simulator. Then i've found these two articles:
"Development of a chemical process modeling environment based on CAPE-
OPEN interface standards and the Microsoft .NET framework" (Computers
& Chemical Engineering, Volume 30, Issue 2, 15 December 2005, Pages
191-201) and "Creating a Design Surface Using Windows Forms and GDI+
in Microsoft .NET" (by Duncan Mackenzie from Microsoft Developer
Network) - which was referenced in the first one. With these in hands,
i've started to develop DWSIM for real.

>
> What physical properties database do you have?
>

DWSIM uses data from the book "The Properties of Gases and Liquids",
the KDB (Korean Thermophysical Properties Data Bank) database and an
Excel worksheet which can be found here -> http://www.cheresources.com/software.shtml

> Did you design the GUI from scratch or is it off the counter graphical
> package?

I'm using a enhanced version of the design surface implemented in the
second article cited above as the PFD area of the simulator. The
source code was available for free, then i could modify it to suit the
specific needs of a process simulator. The rest of the interface is
being designed from scratch by myself. I have to tell you - it is
inspired mainly by the HYSYS GUI, because it's the only commercial
simulator that i have access. I've also looked at the COCO interface
but didn't find it very user-friendly.

[Daniel]

Chris:

On 22 jun, 09:07, chris_dk <sorensen.christof...@gmail.com> wrote:

> Great news. This would make it possible to use on Linux as well if P/
> Invoke is not used at all.

I think that i've made a mistake. Krypton Toolkit still uses some P/
Invoke to do some drawing work. But it can be removed, substituting
the Krypton Controls by the standard Windows Forms ones. DWSIM will be
uglier, but for a very good cause.. hehehehe

> If its going to be open source, why not open it already? Also, have
> you considered a license?

I still have to organize some code in order to make it publicily
available, so people can understand better how things are done
internally.
What kind of license are you talking about? DWSIM is already free,
but: 1 - To be honest, I do not pretend to make money directly with
it; 2 - I don't want DWSIM to be just another COCO, it will be way
more useful when it becomes open-source, so everyone will be able to
contribute with their ideas for a greater good.

Just need to do a more in-depth reading of the GPL license.

Regards,
Daniel

[chris_dk]

On Jun 22, 11:29 pm, Daniel <daniel...@gmail.com> wrote:
> Chris:
>
> On 22 jun, 09:07, chris_dk <sorensen.christof...@gmail.com> wrote:
>
> > Great news. This would make it possible to use on Linux as well if P/
> > Invoke is not used at all.
> I think that i've made a mistake. Krypton Toolkit still uses some P/
> Invoke to do some drawing work. But it can be removed, substituting
> the Krypton Controls by the standard Windows Forms ones. DWSIM will be
> uglier, but for a very good cause.. hehehehe

Hopefully you can achieve a good result in going back to pure Windows
Forms. When you release a new version without the Krypton binding I
will test it on Linux to see the result.

> > If its going to be open source, why not open it already? Also, have
> > you considered a license?
> I still have to organize some code in order to make it publicily
> available, so people can understand better how things are done
> internally.
> What kind of license are you talking about?

I was referring to the source code license such as the GPL.

> DWSIM is already free,
> but: 1 - To be honest, I do not pretend to make money directly with
> it; 2 - I don't want DWSIM to be just another COCO, it will be way
> more useful when it becomes open-source, so everyone will be able to
> contribute with their ideas for a greater good.
> Just need to do a more in-depth reading of the GPL license.

Great. Keep up the good work.

/Chris

[Daniel]

Thank you very much, Dinu.

Some days ago I've found an article entitled "Simulation of Multi-
component Multi-stage Separation Process--An Improved Algorithm and
Application" (http://scholar.ilib.cn/Abstract.aspx?A=hgyj200602019)
which is pretty similar... they basically took Russell's algorithm and
made a few modifications.

Thanks again,
Daniel

On 23 jun, 22:17, Dinu <din...@hotmail.com> wrote:
> Hi Daniel,
>
> Thanks for the reply. Sent you an email. Let me know how it goes.
>
> -Dinu

[celiro]

you should have received a mail with the papers of Boston & Britt (KB
model) and Russel (Inside-Out), hoping this will help your work,

Roberto

[jvb]

Daniel,

If you are interested in inside-out flashes, also have a look at
"Efficient flash calculations for chemical process design - extension
of the Boston-Britt Inside-out flash algorithm to extreme conditions
and new flash types", Vipul S. Parekh and Paul M. Mathias, Computers
Chem. Engng Vol. 22, No. 10, pp. 1371-1380, 1998.

To comment on some of the above,

- COCO is not open source because of the experiences with Sim42 (ask
the guy). No feedback whatsoever until the project was cancelled.
Sim42 lives on as VMGSim.

- Everybody can contribute to the greater good of the society with
COCO; I frequently ask people to do that. That is why it is using an
open standard for all the components to interact with each other (CAPE-
OPEN, see http://www.colan.org/)

Good luck on DWSim, best wishes,

Jasper.

[Daniel]

Hi Jasper, how are you?

I've had a read on this article you cited.

DWSIM was suffering from the feedback problem also, partly because
until version 1.3 it had only a Brazilian Portuguese GUI. I think that
because DWSIM already have a good interface, is programmed in VB,
which is a very popular language (as Chem. Engs. use Excel/Macros a
lot), things can be different. I hope to have some help, don't have
enough time to do all by myself all the time.

When I wrote about COCO in the previous message, i was trying to say
that if DWSIM was only "free", it would never have something to
differentiate itself from COCO. It still doesn't have a distillation
algorithm of any kind nor support for heat exchangers, which in my
opinion are some of the most essential unit ops in a simulator. COCO
already have these. If things remained that way, i was actually doing
a job that already is very well done.

So far i'm liking the results of making DWSIM an open-source software.
With the unvaluable help of chris_dk, we are making DWSIM run on linux
through Mono. The results are very promising.

Thanks Jasper and best wishes to you too.
Daniel

> OPEN, seehttp://www.colan.org/)

[jvb]

Hello Daniel,

I hope you are right. Myself, I am more aiming for contributions in
terms of CAPE-OPEN compliant models, that can be plugged in
immediately. This is a growing market, and also more and more
universities are getting involved. If you ever go in the direction of
making CAPE-OPEN models (thermo, unit operations, both sockets &
plugs), let me know, I'd be much interested.

You can get COCO to run under linux using WINE. Some people do. The
installer will give you some trouble, I hope these issues will be
addressed in WINE. Those that run in WINE usually install under
windows, and then copy the whole directory to WINE (and then register
the DLLs). There are currently more problems in Vista than in WINE,
but these will be addressed in the next release of COCO, and all
result from UAC interfering with writing configuration files.

As for separation columns, I rely on ChemSep, technically much more
capable than I ever will be able to provide (written by Ross Taylor
and Harry Kooijman, both experts in the field). And CAPE-OPEN
compliant. COCO is being used in environments where there is a demand
for more sophisticated models. In this case people use third party
(alas, not free) models, such as external thermo (various options
there) or for example the advanced heat exchangers from HTRI. As is,
COCO is being used more and more for chemical engineering courses.

I am not sure on the status of mono, but I thought that at this point
it is still limited to the 1.0 CLR? In any case, all interesting
developments.

Jasper.

[chris_dk]

On Jul 20, 4:13 pm, jvb <jaspervanba...@gmail.com> wrote:
> Hello Daniel,

> You can get COCO to run under linux using WINE. Some people do. The
> installer will give you some trouble, I hope these issues will be
> addressed in WINE. Those that run in WINE usually install under
> windows, and then copy the whole directory to WINE (and then register
> the DLLs). There are currently more problems in Vista than in WINE,
> but these will be addressed in the next release of COCO, and all
> result from UAC interfering with writing configuration files.

I tried getting it to run in wine but I couldn't register the COM
dlls.

> As for separation columns, I rely on ChemSep, technically much more
> capable than I ever will be able to provide (written by Ross Taylor
> and Harry Kooijman, both experts in the field). And CAPE-OPEN
> compliant. COCO is being used in environments where there is a demand
> for more sophisticated models. In this case people use third party
> (alas, not free) models, such as external thermo (various options
> there) or for example the advanced heat exchangers from HTRI. As is,
> COCO is being used more and more for chemical engineering courses.
> I am not sure on the status of mono, but I thought that at this point
> it is still limited to the 1.0 CLR? In any case, all interesting
> developments.

Mono is far beyond that point. 2.0 support has been there since 2005,
Windows.Forms is almost complete (I would say 99%) and they are now in
the process of completing their Silverlight implementation.

Regarding CAPE-OPEN I read trough the interface document and found it
so detailed that it almost describes how your simulator should be
designed.

What I like about the CAPE-OPEN initiative is that it gives you a way
of making money without giving your code away in an interoperable
manner.

/Chris

[celiro]

On Jul 21, 5:30 pm, chris_dk <sorensen.christof...@gmail.com> wrote:
>
>....
>...

> What I like about the CAPE-OPEN initiative is that it gives you a way
> of making money without giving your code away in an interoperable
> manner.
> /Chris

I presume it has been specified and designed for that pupose (a link
to commercial simulation software to encourage external developers to
add features), a different thing of open source projects,
Roberto

[jvb]

CAPE-OPEN is a project that is sponsored by large chemical companies
that have a need to plug their own process models into off-the-shelf
simulators. There is no point for companies to write a specific
solution for getting an in-house model to run in simulator A and then
another solution for simulator B, whereas using CAPE-OPEN you can
write your in-house model once and run it in a variety of simulators.
Also, companies have a need for cross-testing: use the models that
they run in simulator A directly in simulator B. So CAPE-OPEN design
is driven by end-user requirements.

Commercial software is the best way to make money without giving your
code away.

COCO is not commercial software; if its design consideration would
have been to make money, it would not be available for free. As
mentioned, everybody is welcome to contribute to COCO; just do not
expect to make money with it, as the cocosimulator.org site is a non-
commercial site.

CAPE-OPEN is also not commercial software, as it does not come with
software. It is an interface specification. As such, it is open and
freely available.

CAPE-OPEN sockets are now available in most main-stream process
simulators. This includes very different simulator designs. Which in
my view shows that the CAPE-OPEN design does not restrict your
simulator design. It just allows you to plug in 3rd party models in a
simulator independent fashion.

And indeed - COCO is not open source software; specifically in the
fact that the code is not publicly available.

Jasper.

[chris_dk]

On Jul 22, 9:16 am, jvb <jaspervanba...@gmail.com> wrote:
> CAPE-OPEN is a project that is sponsored by large chemical companies
> that have a need to plug their own process models into off-the-shelf
> simulators. There is no point for companies to write a specific
> solution for getting an in-house model to run in simulator A and then
> another solution for simulator B, whereas using CAPE-OPEN you can
> write your in-house model once and run it in a variety of simulators.
> Also, companies have a need for cross-testing: use the models that
> they run in simulator A directly in simulator B. So CAPE-OPEN design
> is driven by end-user requirements.

Jasper, do you know anything about upcoming major changes to CAPE-
OPEN?

As I understand If you have a crossplatform program you need to make a
CORBA wrapper and one for COM.

COM is not something that Microsoft intends to support in the future
as they are pushing heavily for .NET.

I could imagine solving this issue by using XML and web services. This
would mean you only would have to write your wrapper one time.

The OPC Foundation has gone this way and I imagine CAPE-OPEN could do
the same.

Chris

[chris_dk]

On Jul 22, 5:36 pm, chris_dk <sorensen.christof...@gmail.com> wrote:
> On Jul 22, 9:16 am, jvb <jaspervanba...@gmail.com> wrote:
>
> > CAPE-OPEN is a project that is sponsored by large chemical companies
> > that have a need to plug their own process models into off-the-shelf
> > simulators. There is no point for companies to write a specific
> > solution for getting an in-house model to run in simulator A and then
> > another solution for simulator B, whereas using CAPE-OPEN you can
> > write your in-house model once and run it in a variety of simulators.
> > Also, companies have a need for cross-testing: use the models that
> > they run in simulator A directly in simulator B. So CAPE-OPEN design
> > is driven by end-user requirements.
>
> Jasper, do you know anything about upcoming major changes to CAPE-
> OPEN?

I found a link to a document from CAPE-OPEN:

http://www.colan.org/News/Y06/Interoperability.pdf

Quote:

"A future version of CAPE-OPEN will consist of .NET-based assemblies,
written in C#. The
corresponding COM interface definitions will be exported from the .NET
assemblies. The
conversion step is done automatically using the type library exporter
utility (tlbexp.exe) that is part
of the Microsoft .NET SDK, This changes the main interface
specification work from COM IDL to a
.NET-based interface definition in C#."

I think this will be a big mistake. Hopefully CAPE-OPEN will
reconsider this and switch to a web services model.

/Chris

[jvb]

Chris,

There are no major new releases for the whole collection of CAPE-OPEN
standards on the direct planning. .NET operation is currently achieved
using COM interop. So the current definitions stand in CORBA and COM.
Having said that, there are next to no CORBA users at the moment
(there are some exceptions of major projects running in CORBA, using
distributed computing). CO-LaN offers CORBA to COM wrapping from their
web site. I have little experience with CORBA, from what I understand
the different components require running on the same ORB.

Web services may be something to consider, but will cause considerable
overhead, which especially on the thermo side is not desired. Nearly
all thermo implementations at this point are 32-bit inproc servers
(DLLs) simply from performance considerations. Even when bridging the
32 to 64 bit boundary (required when using 32-bit inproc servers in
combination with 64 bit apps) there is quite the marshalling overhead
(and this is just because thermo is not running in the application
space). Even when running at the same machine and using the loop-back,
web services do require running as a separate process. Imagine the
overhead when running over an actual TCP/IP connection. But yes, I do
see the advantages, especially when running distributed processes
(which btw COM/DCOM and CORBA both can accomplish as well).

If you feel you can make a contribution here, you can join the CO-LaN
organization. Associate membership is free-of-charge, and you can take
part in Special Interest Groups (SIGs), including the interoperability
group.

So yes, COM will eventually fade out, but I am not sure web services
will be the suitable alternative. CORBA (although few applications at
this point) will likely persist. I expect native .NET to emerge. It
would be good if Windows and linux (and others?) would move closer
together in terms of an object model which can run in-process.

Jasper.

[celiro]

Cape Open has many limits and I wouldn't certainly use that interface
should I have access to the code, it is (by far) more efficient to
provide a direct link optimizing the calling and data exchanging
process... this is one of the reasons why open source projects are so
important... however I understand there are commercial reasons to
support the CAPE interface, the most important being the possibility
to create applications with the capability to exchange data with the
most important commercial simulators... that's good for small
companies (which don't have time and resources to create a complete
graphical interface) but I wouldn't forget to mention that in open
source area there are codes (see for example Visio clones) which
could be useful... anyway I think that DWSim interface is a good
starting point, many thanks to Daniel for the code,
Roberto