These days I was remembering that some users were asking, in the very beginning of the project, about scripting support, but somehow I just ignored it because I thought at the time that it was too hard for me.

But now I was digging around the net and found some interesting tutorials about integration of the MS ScriptControl which supports VBScript and JScript. Also, I learned that IronRuby and IronPython can run on the .NET Framework 2, and not only in the 4th version as I thought initially.

My interest in integrating IronPython just got bigger when I remembered that the guys at OPSIM Project like the Python language a lot. So I asked myself, why not?... and came up with this after some work:

In the script window you'll be able to control all aspects of the current simulation, including window properties and so on... in the example below a VBScript statement is used to add a new object to the flowsheet:

Since I don't know anything about Ruby, I just copied and pasted an example from the internet to see if it was working...

The above applies to Python as well...

I'll see if I can find a good syntax highlighter and add support for saving and loading code to/from files, undo, redo, etc, those kind of things expected in a good code editor. But the most important - scripting support - is already there.

This is a special release, since it includes a new language for DWSIM's Graphical User Interface (GUI) - German, translated from English by Rainer Göllnitz. Thanks, Rainer!

This release includes the interface for external plugin development (specific documentation to come later) and updates to rigorous column solvers (IO and SC).

Until now, the Inside-Out and Simultaneous Correction methods to solve distillation columns were not converging, not without a lot of "tweaks". So I decided to review and rewrite some parts of the code, which ended up in adding stability and real convergence. So this is the actual behavior of the solvers when used to simulate the column samples:

	IO	SC	BP	SR
extrdist	converges first tower only	converges first tower only	converges all towers	N/A
distcol16	converges even w/o initial estimates	converges w/o initial estimates (4 iterations)	converges	N/A
ngpu	doesn't converge the demethanizer	too slow, many components/trays	converges all towers	N/A
petroleum_dist	doesn't converge	too slow, many components/trays	converges	N/A

The Sum Rates method is just for absorbers and converges in all cases. The Bubble Point method also always converges distillation columns.

I identified the condenser as the main cause of non-convergence for the IO method, specially if it is a total one (the changes suggested by the newton update in the course of the iteration are just too high sometimes).

Simultaneous Correction, as every other Newton-Rhapson method, requires good initial estimates in order to converge, and it is very slow if you have many components and/or trays, because the Jacobian is being calculated numerically with the 4-point differencing scheme. I tried both methods (normal 2-point and 4-point) and saw a 50% decrease in the number of iterations when using the 4-point scheme. Maybe later I can include an option to select which scheme to use.

That's all for now. I'll let these solvers alone for a while, because they take just too much of my time and I'm starting to feel that's just not worth it... at least not to be developed by only one person with nobody reviewing the code. It just requires too much case and scenario testing, and that demands time that I don't have right now.

I just finished the Utilities Plugin system for DWSIM. What follows is a little Q&A to help clarify your minds:

Q) What is this plugin system?
A) It is nothing more than an interface definition for add-in classes in DWSIM. You can develop a class library in any .NET language which implements the interface, compile it as a .NET DLL and copy the generated file to the plugins folder. Next time you start DWSIM, it will detect the plugin and make it available as an utility in any simulation.

Q) What information from the simulation will be available to the plugin?
A) You will have the entire DWSIM Namespace available - since you're adding a reference to it - and also a reference to the active simulation and all its objects (streams, unit operations, settings, etc.). You will be able to, for example, instantiate new thermodynamic classes to do calculations, but nothing stops you from using your own class libraries, even if they are in separate assemblies (files).

Q) Ok, so what do I need to do to build a working plugin?
A) The basic steps to create a plugin for DWSIM are:
1 - Create a new .NET project in your IDE of choice (Visual Studio, SharpDevelop or MonoDevelop), in any .NET language;
2 - Add a reference to DWSIM.exe, and set the CopyLocal property to False (you don't have to copy the entire DWSIM application to create the plugin, just add the reference);
3 - Create a class that implements the Interface IUtilityPlugin located in the DWSIM.Interfaces Namespace;
4 - Implement the required methods;
5 - Compile your project as a .NET DLL;
6 - Copy the generated DLL to the plugins folder in the DWSIM application folder;
7 - Start DWSIM and create a new/open an existing simulation;
8 - Your plugin will be available in the "Plugins" menu item.

To test the system I created an example plugin which shows some information about itself and a list of GUIDs of the objects in the active simulation. It is really easy and all you will need is some guidance on how to use DWSIM methods and access flowsheet objects and their properties.

Download here.

If you have any suggestion for other video tutorials, please leave a message in the comments section.

/Daniel

Just minor fixes and a gift: The Lee-Kesler-Plöcker Property Package. Changelog:

- [NEW] Lee-Kesler-Plöcker Property Package
- [FIX] Fixed K-value calculation call in the Sum Rates method for solving Absorption Columns
- [FIX] Fixed IO Flash calculation in single phase region
- [FIX] Fixed Critical Point calculation with PR and SRK Equations of State
- [FIX] Fixed portions of GUI language that were not being set on the first run

Click here to go to the downloads page.

Regarding the new PP, I would like to count on your help to test it against other simulators.

I just tried a different approach to solve the single phase temperature problem with the IO flash and it seems to be faster and equally reliable as the nested loops one. I did some benchmarking and here are the results (numbers represent execution time in seconds):

	IO old	IO new	NL
cavett16	52.424	7.952	8.93
ngpu	N/D	42.124	22.94
extrdist	4.62	3.19	2.7
Single PH Flash	5.796	1.67	2.14

That's definitely an improvement, except when the IO flash is used to calculate bubble and dew points without proper initialization, which is the case when we solve columns with no initial temperature estimates.

I also finally found the error in the triple sum routine for critical point calculation. It was, in fact, an error in the equation on the paper (by Michelsen and Heidemann, "Calculation of Critical Points from Cubic Two-Constant Equations of State"). They wrote an "alpha" were it should be an "a". I found another paper with the correct expression, and now the calculated critical points seem to be consistent:

Pretty nice, eh?

The original IO algorithm is intended to work only in the VLE region, that is, it was not meant to use in single-phase scenarios. That's why you'll see DWSIM slowing down when calculating PH/PS flashes in the single-phase region with the IO algorithm.

I'm still trying to find a way to tune the parameters and make the algorithm at least as fast as the nested loop one but, for now, be advised. If you would like to test it, try to run the Cavett simulation with the IO method and check the compressor calculation time - it is very slow because it is only gas, and there is a PS flash and a PH one right after.

Also, the critical point calculation is not behaving as expected. The problem is in the "triple sum" calculation, because the stability curve is being calculated correctly. I'll try to find another paper with the formulation for the PR EOS and check against the one I used to make the code. This only affects the phase envelope and critical point utilities, but it is important for you to know that this is a known bug.

Build 3840 introduces the Gibbs Reactor and comes with important changes in the thermodynamics framework. Changelog:

- [NEW] Gibbs Reactor model (vapor phase only) with two solving methods: reaction extents and direct minimization
- [NEW] New global settings for Property Packages: Flash Algorithm and Calculate Bubble/Dew points
- [NEW] New approach for equilibrium calculation: Inside-Out by Boston and Britt
- [NEW] Added an option to adjust Rackett Parameters and Acentric Factors to match SG and NBP in Petroleum Characterization Utilities
- [NEW] New Quick Settings toolbar: Unit system and number formatting
- [NEW] New menu gives quick access to DWSIM Tools
- [NEW] Added the option to select stream component amounts as properties to show on PFD tables
- [CHG] Completely rewritten Equilibrium Reactor model
- [CHG] Updated ChemSep database loading code to support ChemSep 6.62
- [FIX] Fixed an exception when working with pump curves to calculate pump power
- [FIX] Fixed a bug in temperature calculation with the Steam Tables Property Package

Click here to go to the downloads section.

In the next days I'll add some content to the Wiki:

- A tutorial on how to use the Gibbs Reactor
- A source code guide telling where to find what
- Explanation of the new flash algorithm
- Explanation of the gibbs and equilibrium reactor modeling

That's all for now. Thanks for your support!

/Daniel

Component amounts in property tables: component amounts (mass/molar fraction/flow) will be available as selectable properties for display in flowsheet table and as selectable properties for adjusts, specifications and optimization.

Phase diagram with IO flash: fixed, now it is giving the same results as the default algorithm, but faster.

Bubble and Dew point calculations on streams: The user will be able to calculate bubble and dew points at stream conditions, and display the results in the property grid (if the stream is at liquid-vapor equiibrium).

The Inside-Out approach shows some difficulty in converging non-bubble points. From what I've found during my tests, this originates from the higher temperature variation on each iteration towards convergence, leading the equation of state to generate trivial solution K-values (all close to 1).

On the other hand, my new and improved algorithm is showing very good results:

DWSIM 1.7 is coming in a few days... just wait a little more time.

In DWSIM 1.7 you will have the option to choose between two flash algorithms or schemes - DWSIM Default (traditional Rachford-Rice for PT flash and nested loops for PH/PS flashes) and Inside-Out (from Boston and Britt). There will be a global setting which controls calculations done by all Property Packages OR you can define this setting in a per-Property Package basis. The default for each added property package is the global setting.

Source code changes are much more deeper. I removed all repeated code from property packages and now all equilibrium calculations are handled by the base class (PropertyPackageBaseClass) and flash methods in separate classes, grouped by scheme. The property packages will provide only the necessary K-value, Fugacity, Enthalpy and Entropy values for the equilibrium routines.

I just finished coding the IO Flash algorithm by Boston and Britt in DWSIM. And it is working! Convergence of my test problem was actually a bit slower than the current method but I guess that it is something related to my initial estimates...

Anyway, DWSIM 1.7 will contain this new flash code and also a new, more conservative Michelsen two-phase flash algorithm which is guaranteed to converge even on difficult cases like those near the critical point.

I can't wait to see the Phase Envelope utility without bubble points going towards infinity....

The Gibbs Reactor is done and the Equilibrium Reactor was completely rewritten. The first can be solved using equilibrium reaction information or not, just like in UNISIM/HYSYS. With the same mixture and reactions, these three methods should always give the same results, although through completely different calculation methods. The results were validated against UNISIM and book examples.

Also, there are some changes in the Petroleum utilities. In the Distillation Curve charac. utility you can now provide a single density or molar weight value which will be taken into account when calculating pseudocomponents.

On both utilities, you'll have the option to tune Acentric Factors and Rackett parameters to match NBPs and specific gravities, using the default Property Package (first on the list) or the Peng-Robinson EOS, if there isn't any. In the case of NBP fitting, you'll get a better phase behavior
agreement with experimental data.

The result is the calculated density matching the value provided while characterizing the sample, for the ZRa adjustment. If that still doesn't work, you can force an ideal mixing rule for the calculation of liquid density in the property package configuration window (because Rackett's method uses averaged properties - Tc, Pc, ZRa, Vc, etc. for the whole mixture by default). And THEN it should work.

I included a new "Tools" menu item which contains the component and reaction tools available only in the simulation configuration window until now.

Also updated is the ChemSep database loading code to reflect some changes they did in the PCDManager's output XML. DWSIM 1.7 will contain these and other minor changes/fixes and will be released as soon as I finish updating the documentation and some tutorials.

/Daniel

Calculation mode 1 is done. Here you have to inform which equilibrium reactions are occurring without worrying about the equilibrium constants.

The "N/A" component is actually Carbon Monoxide.

In this mode, the result is composed by reaction extents and component conversions, just like the Eq Reactor. Currently I'm using the Simplex method from the DotNumerics library to minimize the mixture Gibbs free energy, and it is working OK.