Current status of Sim42

[ChemE]

Raul Cota (one of Sim42's creators)  was kind enough to give me an update on the status of Sim42. The following information is excerpted from an email conversation:

Can you tell me what the current status of Sim42 is?

The Sim42 Foundation is no longer active, due primarily to lack of activity from the community.
The web site was moved to http://www.virtualmaterials.com/sim42 and it now contains the last exe version of the simulator 2.0.0.0 . The original website got several hack attacks and was disabled.

At this point, the sim42 website that is being kept by virtual materials is basically a repository of the project up until version 2.0.0.0.

The latest and greatest is version 2.0.0.0 and I just put a zip file containing the source code in the Download-Source Code area of version 2.0.0.0

The source code in the redtree CVS should be the same.[/i]

Is VMG going to continue supporting it?

Merely for hosting, not open source development anymore 

Why wasn't it hosted on sourceforge.net?

No reason in particular. At the beginning we all thought this was going to be pretty big so we (and by we I mean Craig/RedTree) provided all the hosting tools. When Craig left is when it made sense to move to sourceforge but I never did.

Will the current version of the VMG physical property package (SeaPkg50323.exe) still allow Sim42 to access Ideal and RK without a license key?

Yes, virtual materials (VMG) provides the property package ideal and rk without a license. VMG also provies the full property package or VMGSim at no cost for educational purposes.

Is there a simple open source physical property package template that people can use as a starting point for their physical properties implementation? (another question that comes up from time to time).

Not really. I thought noboady was ever going to ask ! 

[bendel_boy]

Does Raul Cota (or anyone else) have any idea why Sim42 did not take off? Why did Craig leave the development team? It does not bode well for the idea of an Open Source flowsheeting package if the examples of which we know - ASCEND IV and Sim42 - both end up moribund, available but unsupported and with no further development.

For myself, I commented elsewhere that Sim42 used Python, with which I was not familiar. A Fortran-based computational engine would have made it easier for me to feel like examining the source code in more detail. Another issue is time - with marriage & children my free time has greatly reduced; I know your vision has companies paying for developers to work on the product during 'office hours', which would make it far more feasible. Somehow I don't think companies are reading this, or thinking along these lines. As paper_eng wrote in a different thread, company support for in-house software has gradually closed down and been transferred to commercial programs. However, I don't think that that necessarily prevents Open Source from taking off - what it indicates is that the companies preferred to pay a share of the development costs. So an Open Source initiative would probably require another AspenTech-style consortium, but with safeguards to prevent the code being closed & spun-off into a commercial offering.

Also, I know that keyword-defined data files was the way we grew up using process simulators, but the GUI world has rather spiled me. I maintain a wastewater simulation package, and I remember its days as a VAX product, then moved to DOS, where I always felt it fragile to use because of the need to keep looking up commands, and that the pain factor of learning was too great. With SimSci's PROCESS simulator I had the same feelings. Once we had a GUI interface ease of use greatly increased, because the interface took care of ensuring that all data was correct, and correctly assembled. So, as an aside, for uptake of the Open Source product I feel that a GUI is needed - the SIMBA 'GUI' was still unusable without knowing what keywords to type.

Thanks for getting Sim42 Version 2 made available. I have downloaded it, and referred it to a friend who does AIChemE training on process flowsheeting - he has always used demo versions of the commercial products, but is considering ASCEND IV and now maybe Sim42, at least for a mention in the course.

[paper_eng]

I have to agree that the current status of sim42 does not bode well for the future of open source process simulation.   

Give the Virtual Materials people credit for giving it a good try, though.  Via sim42, they gave away the solver and a number of unit operations, which is about half of what you need for a full blown simulator.   It still needed a GUI, which most people expect these days, and it still needed an open source thermo package.   Since VM's bread and butter is the thermo package, one could hardly expect them to give much of that away as open source.   As far as the GUI goes, they didn't bother to take the time to write their own (from scratch) GUI for the commercial version of their simulator (VMGSim).  Instead, they used Visio for the graphical front end, and Excel for data handling.    There is probably a lesson there, in terms of cost effective programming.

I expect that there are lots of folks who would line up to download a free process simulator.   It seems there are a lot fewer who are willing to contribute in the form of time (participation).    We already know how few people can afford to pay someone else for the development effort.   

As an aside, I find it kind of interesting that AspenTech dominates the chemical process simulation business, appears to charge significant license fees for their software, and yet struggles to turn a profit.  From the perspective of an outsider, it certainly doesn't look like a very attractive business.   I'm not sure what that means for the prospects of an open source effort.

[bendel_boy]

Where did you find the information on AspenTech's problems with profitability? How is SimSci doing? I know that AspenTech seems to have bought up several smaller competing packages - SpeedUp, HySys and various UK Solids Processing Club programs, for example. It gave the impression that AspenTech was doing well.

As I've said several times, my area now is wastewater rather than chemical processes. SimSci did try once to buy a CH2M-Hill package and sell it into the wastewater/industrial efluent market, but whatever sales it did it never passed Version 1.0, and is no longer on their software list. The wastewater sector regards the chemical process sector as profitable!

As regards a GUI, we looked at Visio and were put off by the licensing. From memory, there was an opportunity to buy Visio with a licence that would make it an embedded offering inside (say) Visual Basic, with no run-time licence (c. 1995) - but when we next looked (c. 1999) that was no longer available, so that Visio would have to be paid for for each copy made available. A bit of a killer for a free open-source version!

We have our own GUI, tweaked with each new project development, written in Visual Basic. It wasn't that difficult for the programmer (not me!) to write, and at that time we had a development team of three on the user inrefcae side, one on the engineering side (me), and a development period of under 6 months - including documentation. We took maybe another 3-6 months to shake out the worst GUI bugs, a time replicated the next time we had a major change in the GUI. The shake-out time is less a function of bug-fixing and more one of bug-finding - at release there are no known bugs, but as others use it so different usage patterns find these bugs.

[ChemE]

Aspen Technology is traded under the symbol AZPN so its financial stats are public knowledge. If you go to a financial site like finance.yahoo.com you can find out more.

My understanding is that AspenTech hasn't shown a profit since 1999. There is an interesting investment analysis of AspenTech's history at jimpinto.com

It is harder to figure out how a competitor like ScimSci is doing because their financial information gets bundled into those of the much larger Invensys parent organization. But I get the general impression that none of the "mainstream" simulation organizations are doing well financially. One assumes that if Hyprotech was a goldmine for AEA they would not have sold it to AspenTech.

[paper_eng]

I've heard that the majority of Aspen's business comes from the major oil and petrochemical companies.   That may be part of the problem.  Excepting the recent past, I believe that profit margins in the refining business are typically pretty slim. (I guess it's the oil producers that really rake in the $'s).   If your primary customers are used to running on thin margins, they may be pretty stingy when it comes to buying software, services, etc.

Thanks to Bendel_Boy for the story about developing your own GUI.  Three people on interface design vs one on the engineering side: That says a lot about where the programming effort lies in modern software.

[bendel_boy]

Since the code has been written we would now regard the effort of adding a new treatment process as something along the following lines:

* Research the available data, and prepare a suitable correlation: 2 - 4 days
        - usually the models are already available in the literature, and we are reconciling
          the alternatives to something we will be happy to dcument and defend
* Turn the model into Fortran code - 1 - 2 days
* PDE-based systems can take weeks to fine tune, because of the need to reconcile
         speed, stability, and accuracy. Because other treatment processes may be discontinuous
         the Gear-style solvers for handling stiff ODEs frequently do not perform that well.
* Handling event-based processes - for example, sequencing reactors - also
         increases the coding time, as frequently the events switch the physical
         description of the tank - for example, from well-mixed (model as a CSTR) to
         stratified (model as a series of CSTRs), partially emptied (moving interface)
         and back to well-mixed (interface location, mixing of CSTRs back into the
         single CSTR approach).
* Add to the user interface - 3 - 5 days
* Debug - 2 - 5 days
* Document - 1 - 2 days

The engineering side benefits from the depth of published literature. When we started this product, we also had the benefit of the engineering side having existed as a VAX, then DOS, program - 1 - 2 developers - while the GUI had to be written from scratch. Now, the GUI benefits from existing, but because of when it was written (Visual Basic 3.0) its structure does not make use of object-oriented features. For a different product we have an OO-based GUI (still Fortran maths) and there adding a new process to the GUI is of the same, or less, effort than the Fortran.

My experience has been that OO greatly simplifies the user interface, as it is handy to treat all screen icons as specialised instances of two objects - either process (the model) or stream (the connector), and have the compiler handle the relevant mapping. I simplified the user interface to the point where as much as possible is driven by a table-based dialogue database, so that all the specialisation is handled at the Fortran code level.

At the Fortran level I have implicitly all the code returning values of type equation, which my ODE solver handles for dynamic solutions, and my nonlinear equation (NLE) solver for steady-state. The wealth of high-quality ODE and NLE solvers in Fortran is invaluable. OO doesn't seem as useful at this level, a comment mirrored in the C++ edition of 'Numerical recipes' and in my own experiments with looking at C++ for process modelling. This is especially the case when reusing the Fortran libraries, since the OO code is either going to maintain pointers into the large Fortran vectors, or to have to call a routine adding their own state variables into a Fortran vector for the ODE/NLE solver. Either way, avoiding OO at this level seems easier - possibly because in my code arrangement there is a single CASE statement that switches between process models, while at the user interface level, the OO-version has a single CASE statement to create models, and the non-OO version has 20+ CASE statements, for each possible user interface interaction.

[bendel_boy]

In my area, mainstream software has affected pricing. We found that people expected to pay Microsoft Office prices for their simulation software, say $500. But because it would be an important part of their engineering output, they also wanted sales visits - usually 2-3 while they made their decision and brought in new people - and then a few months loan for evaluation, perhaps a few tweaks to better handle their needs (at our expense). Finally, they usually buy one copy. We, like most others in our field, sell for $1,000 - $5,000. So wastewater sector profit margins are probably a lot smaller than chemical sector!

Ten years ago the norm was renting, with $33,000 upfront and maybe $5,000 annual licence. With the switch from UNIX to PC the norm changed to purchase, for $15,000, and optional annual support, for $2,500 - which most people took out.

Then some university-based software arrived, when the pricing really dropped - $1,000/year rental or $5,000 for purchase with two years support.

Although people don't want to pay much money, they still seem to feel the need to buy their software - another barrier to a classical Open Source offering. Possibly because they want to have an identified support route. I know that Open Source does not preclude this, but it doesn't seem to have a high profile, and I noted that the OpenFOAM web site appears to be commenting about the lack of uptake of support contracts, without which OpenFOAM will not be developed by the original team.

[ChemE]

I started in the simulation biz back in the late 80's. At that point, none of the commercial simulators had a GUI. I recall getting rather badly trashed when I suggested that a GUI was going to become necessary to be competitive.

Within a year, customer pressure became great enough that a GUI project was kicked off. Unfortunately both customers and management had unrealistic expectations on how expensive and difficult it would be to create a GUI for a simulator.

• Customers took the attitude that... "Hey, I am paying thousands of dollars a year for this simulator so it is reasonable for me to expect a GUI comparable in quality to the GUI's I have been accustomed to on my PC or Mac. After all, I am only paying a few hundred dollars for my OS and, say, MS Office." Nobody seemed to recognize that a few hundred dollars per user multiplied times millions of users was going to fund a lot more development than a few thousand dollars per user times a few hundred users. Or that a commercial process simulator is actually a lot more complicated than a spreadsheet.
• The management of the commercial simulation outfits took the attitude that... "Hey, we're hotshot software developers who've developed these hugely complicated simulators. Whipping up a decent GUI should be no problem."

Compounding this was the state of the OS GUI's in the late 80's. The Macintosh was easily the best but Apple was overcharging for the hardware and the Motorola chipset was anemic compared to its Intel competition. MS Windows was a piece of junk stuck ontop of MS DOS but ran on relatively cheap hardware. And the VAX and UNIX minicomputers were expensive, did not offer anything in the way of office productivity software,  depended on XWindows for any sort of GUI, and there was a general migration from centralized minicomputers/terminals to PC desktops.

So most of the commercial simulators ended up developing GUI's based on proprietary graphics technology. And the effort to develop a decent simulator GUI took years longer and cost millions of dollars more than expected.

And all this was exacerbated by an unwillingness or inability on the part of the customers to recognize the true value of simulators and an inability on the part of the simulation companies to convince them of same. There were a few companies that were willing to pay more for their licenses because they viewed it as an investment in the future development of the simulator... But they frequently found that the investment in development they had been promised never happened or was postponed for years. After that customer relations degenerated into a pissing match.

I have worked on both offline and online simulation projects and I have been struck by the difference in the perceived value to the customer. An offline model of large, complicated plant can take a man-year to develop. It can be very valuable when designing a new plant or upgrading an existing plant. One can argue that it may save millions of dollars by allowing engineers to avoid mistakes and study alternatives easily, and find process improvements. But those savings are very hard to quantify.

But an offline model, once developed, is used intensively for a few months and then may sit on the shelf (or hard drive) for years without being used.

Online, closed-loop models on the other hand, when used for process optimization seem to be much easier to justify. They are in use continually and everyone seems to find it easier to see their value because of that. At any given moment it may only be producing a few tens or maybe hundreds of dollars in savings but it does this 24/7 and those savings are quantifiable.

The offline model may have saved you millions of dollars but, since no one builds plants without using a simulator these days, the savings are not obvious.

--ChemE

[paper_eng]

Thanks to Cheme and Bendel_boy for some very interesting insight into the simulation business.   

The comments about the short-duration utility of off-line models fits with my limited experience.   Given that many segments of the chemical industry are now mature commodity businesses, I think there are a lot fewer projects involving new processes and plants than there used to be.   As growth moderates in those industry segments, there would also be fewer expansion projects.   That undoubtedly translates into weaker demand for engineering design software, and engineering services.

One thing appears true: software development is hard (time consuming, labor intensive) and that means expensive.  So it will be a tough business to be in if you don't have a large customer base, or an obvious and irreplaceable value to offer to customers.    If people aren't willing to pay (either to buy software, or to obtain support services for an open souce package), then they will likely end up disappointed with what is available...

[bendel_boy]

It's about to attempt a rebirth.

Anyone interested in offering to help?

See the e-mails below.

=================================


 From:      simulators-request@lists.redtree.com [simulators-request@lists.redtree.com]    
 Sent:      Wed 3/1/2006 11:17 PM
 To:               simulators@lists.redtree.com
 Subject:     Simulators Digest, Vol 18, Issue 3

Today's Topics:

   1. Reviving Sim42 (Hazem)
   2. RE: Reviving Sim42 (Mark.O'Rosky@EmersonProcess.com)


----------------------------------------------------------------------

Message: 1
Date: Wed, 1 Mar 2006 16:12:39 -0600
From: "Hazem" <Hazem_Haddad@hotmail.com>
Subject: [Sim42] Reviving Sim42

Ladies and Gentlemen,

I am not familiar with the circumstances that led to the formation of the SIM42 foundation nor the circumstances that led to dissolving it.  If there are no sensitivities, I would appreciate some background.

I am wondering if any of you is interested in reviving the Sim42 project under the .NET environment.  Visual Basic .NET is relatively easy and the ability to integrate Visio into it does not seem complicated either.  This will enable us to have a good user interface; something which Aspen Plus and Pro/II still lack.

Before any one of you gets suspicious, I would like to inform you that I am the owner of Engineering Services & Software (www.EngineeringSoftware.biz <http://www.engineeringsoftware.biz/> ) however, as you can see from the software currently on my website, my intention is not to compete with a company that sells a simulator but rather to write software that supplements one.  In the future, I would like to offer a free simulator and I am hoping some of you can help.

We will not be starting from scratch, we already have SIM42 and I already have the following:

The pure component database in "The Properties of Gases and Liquids", Reid, Prausnitz and Poling, 4th edition.

All low level subroutines & functions to calculate low level properties such as pure component vapor pressures.

Soave, Peng Robinson, and Lee Kessler Plocker equations of state.

Medium level subroutines for dew point and bubble point pressures and temperatures, isothermal flash, adiabatic flash (for valves) and isentropic flash for expanders, compressors & pumps.  There are cases for which they simply will not converge, but I am working on that and some need better ways to estimate initial guesses but for now, they are OK.

A distillation routine which uses the bubble point method.  I copied more routines from books but they diverge more often than they converge.  I noticed that Sim42 has Richards Russell's inside-out algorithm but I have to learn Python to be able to convert it to Visual Basic .NET

What do I need:

A graphical interface. (the forms needed for unit operations input are also already developed)

A better distillation algorithm.

Routines for or help with free water calculations.

Help with transport properties (Viscosity, thermal conductivity, etc)

Help with petroleum fractions (converting an essay into pseudo components).

I can probably put a prototype together in a few months to encourage you all to join me.

If you are interested or would like to discuss this further, please let me know.

Regards

Hazem Haddad

------------------------------

Message: 2
Date: Wed, 1 Mar 2006 17:16:42 -0600
From: <Mark.O'Rosky@EmersonProcess.com>
Subject: RE: [Sim42] Reviving Sim42

Hazem,

I am interested in helping. Let me know when you get your projects list up and running.  I have expertise in many differing areas and recently been playing with Berkeley Madonna stuff.

As you can see we build simulation for operator training and at last count we have worked with 11 different simulation packages.  I am
learning VB.net

Sincerely,

Mark O'Rosky P.E.

Operator Training Solutions
Emerson Process Management
12301 Research Boulevard-Building III,
Austin, TX. 78759 USA
Ư (512) 832-3658
Ư (512) 832-3232

Email: Mark.O'Rosky@EmersonProcess.com
<blocked::mailto:Darrell.Tank@EmersonProcess.com>

Check out our website: http://www.emersonprocess.com/education/ots.asp

[jdpipe]

A note for the record on this topic:

The ASCEND project is not 'moribund' as stated above, and is currently under active development as of 2008.
We have a website http://ascend.cheme.cmu.edu/
and a wiki http://ascendwiki.cheme.cmu.edu/
and a sourceforge page hosting our code releases http://sourceforge.net/projects/ascend-sim

Hoping that anyone interested in participating in open-source equation-based modelling software will come and join us!

Cheers
JP