Using an appropriate physical property model is key to successfully modeling any unit operation. General purpose simulators like Aspen Plus, PRO II, etc. have dozens of physical property models to choose from. These can be divided into two classes: equation of state models (e.g. ideal gas, Redlich-Kwong-Soave) and activity coefficient models (e.g. UNIFAC, UNIQUAC, NRTL).

Acid gas scrubbing involves species that act as molecules in the vapor space but behave as dissociated ions in the aqueous phase. As far as I know, no equation of state model will properly represent that. All the simulators capable of modeling acid gas scrubbing do so with some type of activity coefficient model.

For systems where they are appropriate, equation of state properties will work with only the most basic information about the molecules in the mixture. They generally do not need information about the interactions between the specific molecules in the mixture.

For acid gas scrubbing systems and, in fact, any electrolyte system; the activity coefficient models need species-to-species interaction parameters. These need to be regressed against laboratory data (from data libraries such as DeChema). With the Aspen Plus simulator, the activity coefficient model of choice was eNRTL and there were various physical property packages that provided pre-regressed parameters for common systems. For example, one would model a Benfield system using the “HOTDEA” package of parameters.

One also needs to keep in mind that many acid gas scrubbing systems do not operate at equilibrium. In other words, there are mass-transfer limitations between the vapor phase and the liquid phase. A common example of that is nitric acid scrubbing.

We used to model nitric acid absorption columns with a column model called RATEFRAC which could represent non-equilibrium mass-transfer. That was several years ago and I imagine that other general purpose simulators now have a similar non-equilibrium tower models (and there have long been specialized simulators for representing non-equilibrium acid-gas systems).

The bauxite mine and it’s supporting town (definitely a “company” town) are accessible only by sea or by air. There are no road or rail links to the outside world. The town and plant are in the middle of an aboriginal reservation and the only people who live in the area are employees of the mine, a few government employees (like postal workers and teachers), and the aborigines.

There is an airport and regular air service although I understand that the runway runs right over the bauxite deposit and will eventually get dug up.

Having never been this far into the wilds before, I frequently made a bit of a fool of myself. When I got off the plane in Gove, my host (whom I’d never met) walked right up to me and said hello. When I asked how he had known it was me he laughed and said that he’d known all the other people getting off the plane.

And when I rented a car (rather surprisingly they have a Hertz franchise) the manager asked when I’d be leaving and I said the following Saturday morning. She told me that they weren’t open on Saturday but that I could just leave the key on the counter. I asked if she wasn’t afraid of someone stealing the car… And she laughed and said where would they go with it (Gove only has about 5 miles of paved road).

I was staying in a small (and only) hotel in Nhulunby which is, I gather, heavily subsidized by the bauxite plant. Perfectly comfortable except that they didn’t seem to have any cold water in the bathroom. At least I seemed to be getting hotwater out of all the taps. It turns out the “cold” water was stored in a cistern on the roof. And in Nhulunby it gets very hot on the roof… So no cold water.

On the two visits I made to Nhulunby I had to stay over a couple of weekends so I had a chance to “see the sights.” There are very nice, pristine sandy beaches but I was warned (severely) not to go swimming and not to even walk along the beaches at night… Why? One reason was the stinging jelly fish that infest the waters for about 6 months of the year and the other was because of the salt water crocodiles in the area that like to snatch meals off the beach at night.

They may have been pulling my leg but the plant personnel told me that a previous visitor (from their parent company in Switzerland no less) had not heeded the warnings and had been snatched off the beach one night and eaten. Certainly, I did see crocodile tracks on the beach when I went walking during daylight hours. (And they were impressively big)

The other weekend amusement was being taken to the Nhulunby Yacht Club (a cinderblock building overlooking the water) where we sat on the porch out front and defended our lunches from swarms of flies (It is where I got to perfect my “Aussie Salute”… a quick swipe of the hand across one’s face to discourage the flies!)

I was developing an overall ammonia plant model for a customer in Japan. About mid-way through the project my Japanese colleagues came to the US for a review meeting in which we tried to match the model results against plant operational data (temperatures, pressures, flow meter readings, chemical analyses).

Everything was matching up rather well… Except for the chemical analysis of the CO2 scrubber underflow. The plant’s analyses were consistently much lower in dissolved CO2 than what my model was calculating. We went round and round trying to figure out what might be wrong with the model physical properties, the control settings for the absorption and stripping columns, etc. We just couldn’t see anything wrong with the model. We could force it to match the plant’s underflow analysis but we then had much too much CO2 getting into the synthesis loop. So my colleagues called the plant back in Japan and asked if there was any way their analysis could be incorrect. They were told (rather vehemently) that there was no way that the analyses could be in error… That plant personnel had taken the underflow sample every shift for nearly twenty years and that the analysis was always the same.

That’s where the light began to dawn. My Japanese colleagues and I had naively assumed that the analysis was the output from some inline automatic analyzer. When I was told that plant personnel “took the sample” I began to suspect that this was a case of sampling error. The underflow from the Benfield unit would be rather hot and at some pressure. I asked my colleagues to call back and ask how the sample was taken and whether it was kept at the same pressure until it was analyzed.

While they checked back with the plant, I reran the model including an underflow sample stream that I flashed to atmospheric pressure. And the model’s predicted sample composition matched the plant analysis perfectly. And then my colleagues got off the phone and confirmed that the sample was taken by opening a valve and catching a stream of hot caustic in a bucket. So the problem was solved. When the pressurized caustic solution was dropped to atmospheric pressure a large part of the CO2 flashed off and that totally changed the sample composition. And the analysis was always the same because it was always flashed to the same state.

We also discussed the point that this sampling exercise was both dangerous to the operator and totally pointless. I later found out that the plant discontinued the practice as soon as my colleagues got back to Japan.

Model validation is a critical step that must be performed before a model can be safely used to study or improve a process. But validation is very much an art. Most large scale process models assume steady-state operation but no large process is every really at steady-state so trying to decide when you are “close enough” is a challenge. In addition, the operational data that you must validate against always has errors. In my experience over modeling dozens of plants, it works out about 50/50. In other words, if you have a significant discrepancy between the model and the plant data about half the time you’ve done something wrong in the model and about half the time the plant data is wrong. That ratio obviously depends on how careful you are in your initial model development and how well run the plant is.

CAPE-OPEN

My feeling is that the CAPE-OPEN initiative came about to address some key concerns of the “consumers” of process simulation software. These concerns were as follows:

• What happens to my considerable investment of time and effort in developing models of my plants and processes if the vendor of my commercial simulation software goes out of business?
• What happens if the vendor of my commercial simulation software decides to jack up the license fees higher than I can afford or think is reasonable?
• What happens if the vendor does not choose to add features to the simulator that I feel are necessary?
• What if the vendor does not provide adequate levels of customer support and/or the simulator is too buggy.
• What happens if my simulation vendor is merged with another vendor and my simulation software is no longer going to be supported or further developed?

All of these boil down to the issue of “vendor lock-in”. If you spend man-decades developing models of your plants and processes… And those models are important to your continuing operation and improvement of said plants and processes… And you are licensing your simulation software for some set period… Then your vendor has you over a barrel.

The vendor knows there is a large barrier to your switching to a competitor’s product… Your engineers would need to be retrained and every one of your models would have to be redeveloped from scratch for the competitor’s simulator. So the vendor’s sales department will tend to increase there prices at license renewal time to just short of the excruciating point that you will “bite the bullet” and switch.

My impression was that CAPE-OPEN was developed by the process industry consumers of simulation technology to try and reduce that barrier to switching simulators. The idea being to develop a standard way of representing a process, its chemical components, unit operations, and connectivity and requiring all the commercial simulator vendors to add interfaces to their software that would both generate and read process descriptions that obeyed the CAPE-OPEN format.

As an example of how this might work… Let’s say my company has built a model of a vinyl chloride plant using ASPEN PLUS but we are no longer happy with AspenTech… According to CAPE-OPEN, we should then be able to tell the ASPEN PLUS software to generate a complete, vendor-neutral, CAPE-OPEN representation of our VCM process.

We then license, say, PRO/II. According to CAPE-OPEN, we should be able to tell PRO/II to read the CAPE-OPEN representation of our VCM process. We then push a button,and “poof”, we run our first PRO/II simulation. Should only take a few minutes and now all we need to worry about is learning how to use the PRO/II interface.

Unfortunately, I doubt it is (or ever will be) that simple… For a variety of reasons:

• The CAPE-OPEN interfaces are being developed by the simulation vendors. It really isn’t in their interest to have it work and their support of the initiative will be grudging at best.
• You are getting out of the frying pan and into the fire. OK, say you can generate a vendor-neutral process description. Which vendor’s simulator are you going to read it in to? None of the simulation vendors are doing well financially; none seem to be well managed; none are serving their customers well.
• Getting a model of any complexity to work in any simulator is challenging and there will always be subtle or not-so-subtle differences in how each simulator represents and converges a given flowsheet or piece of equipment.

[Again, if anyone wants to email me their experiences as a user of CAPE-OPEN I would appreciate it.]

OPEN SOURCE

I don’t think the term OPEN SOURCE had even been coined back when CAPE-OPEN began but, in hindsight, I think pushing for the development of one or more OPEN SOURCE simulators would have been of much greater service to the process industries. These could have been (can be) developed from scratch or created by converting an existing commercial/closed-source simulator to be open source. We have seen examples of the latter in recent years in Sun’s “open sourcing” of Solaris and Java.

Please note that Open Source does not simply mean providing or using software for free. There are costs associated with using Open Source software… It is simply a different business model and there are quite a number of successful companies that are making money while writing or supporting open source software (e.g. IBM, RedHat, Sun, Novell, etc.)… And thousands of companies and government agencies happily using Open Source software such as the various flavors of Linux, Apache, MySQL, etc.

I see some huge potential advantages for the process industries if one or more open source process simulators were to be developed:

• Users would no longer at the mercy of the vendor’s salesmen and lawyers when it comes license renewal time… There would be no license in the old sense. What would be negotiated would be a service contract and if user was not been happy with the service they would be free to walk without losing access to the simulation software.
• The user would no longer be subject to the vendor’s development priorities. A vendor may (quite legitimately) feel that some requested capability is not widely applicable to the general customer base and therefore not worth developing. But, with an open source arrangement, the user(s) who need the capability could develop it themselves or comissions a third-party to develop it.
• And with open source simulators there would be a cottage industries of individuals and companies developing, implementing, and supporting the products.
• The user community is always in a position to judge the code quality and architecture of the simulator because a wide community of programmers, engineers, and consultants can see the code for themselves.

As far as I know there are no general purpose open source process simulators available or under development at this point. (If anyone knows of any, please email me and I will amend this section). Virtual Materials (a physical properties software outfit up in Calgary) made an effort at this with a simulator called Sim42 but, unfortunately, they did not get any response from the commercial user community and the effort was suspended. There is successful, actively used and developed, open source process-related software such as Cantera (for simulating reacting systems) but they all seem to be limited in scope and focus and I am aware of no general purpose simulators.

Back in the 1980’s after the first Middle East oil embargo and against the continuing backdrop of Middle East political unrest, the Australian Department of Primary Industries decided to study whether and how Australia’s abundant coal reserves might be used to produce synthetic liquid fuels (e.g. diesel, jet fuel, gasoline, etc.) in case imported oil became scarce or unavailable.

DPIE (never, we were told, to be pronounced “dopie” ;) ) commissioned Broken Hill Proprietary’s R&D arm to develop a pilot-scale coal liquefaction process and run experiments on the various coals available in Australia. My recollection is that they looked at coals from the Victoria, New South Wales, and Queensland.

For those unfamiliar with Australia, Broken Hill Proprietary (or BHP) is the 800 lb gorilla of the Australian economy. Not only is it a huge company but is also the primary player in terms of industrial R & D. In a US context, it is as if you combined IBM, GM, GE, and Microsoft into a single entity.

So BHP set up pilot plant facilities at their R&D campus in a suburb of Melbourne and began running tests on the various domestic coals. The actual liquefaction process was largely based on what had already been shown to work in the US and Europe.

I don’t remember the BHP process in any detail but, like all coal liquefaction processes, it involved processing pulverized coal with coal-derived liquids and hydrogen under high pressure and high temperature. This then produced two streams, an ash residue stream and a liquid roughly comparable to crude oil. It was this synthetic crude oil that was intended for additional processing to produce synthetic diesel, kerosene, and gasoline. A fraction would also be recycled back to liquefy additional coal.

Of course, the pilot plant process was intended to collect data on the process and the immediate synthetic crude product. It did not provide any directly useful information on the overall process economics.

So DPIE commissioned us (AspenTech) to develop a simulation of the complete process including coal pre-processing, coal hydroliquefaction (based on the BHP pilot-plant data), the synfuel refining section, and all the other support sections (e.g. hydrogen production).

The simulation was intended to represent an actual commercial-scale plant, its operating costs, and capital costs with a view to determining what the net cost of the final transport fuels would be in equivalent dollars per barrel. This would then give one idea of how high world oil prices would have to be for a coal-based synfuel plant to be competitive.

The other purpose of the modeling effort was to ensure that BHP was collecting enough consistent data to support such a study.

The process side simulation was challenging (this was a large model with a lot of distillation columns, reactors, and recycle streams) and the economic side required a lot of assumptions. For example, databases used to estimate capital equipment costs were US-based, no Australian capital equipment cost data was available.

It was a very interesting, challenging project and I enjoyed my stay in Australia (I was out there for a total of 6 months) and it was fun working with my colleagues at BHP.

The conclusion of the project was rather bemusing and, I suppose, shows how naive engineers are. One of the things we’d been asked for in the RFP was a comparison of the process economics for the different Aussie coals (Victoria, New South Wales, and Queensland). So our final report had a table comparing the results and we had text discussing this… Basically, the model showed that Queensland coal had the best economics and our conclusions said as much. But DPIE kept delaying approval of the report and, since our final payment was dependent on the report being accepted, we were getting a bit anxious. But no one was giving us any specifics on why the report was not being accepted.

Eventually, one of the BHP managers had to give us a little explanation of Australian politics… That Victoria was a much more populous state than Queensland and therefore had more MPs and more clout in the Federal bureaucracy than Queensland did… And that DPIE did not want to approve our report while it explicitly stated that the Queensland coal was a better choice than the Victoria coal. (Neither were they willing to tell us that directly.. ;) )

So we changed the text of the conclusions… The comparison tables still showed that the Queensland coal produced less expensive synthetic fuels but we didn’t explicitly mention that in the final conclusion. And… The revised report was accepted.

Now that world oil prices are up around $60 a barrel, I wonder if anyone in Australia is revisiting this area to see what the current synfuel economics look like.

My recollection was that my plane arrived in Johannesburg around dawn after an overnight flight from London so I was pretty exhausted and jet-lagged. I had to get a rental car and then drive for hours across the Veldte (on the wrong side of the road… South Africa is an ex-British colony). The scenery was pretty spectacular… Definitely “big sky” country although it was strikingly different from anything I have seen in the US or Australia.

Eventually I arrived at Secunda and that’s where things got surreal. I had been checked into Graceland Hotel Casino & Country Club (see photo). I drove up the sweeping drive surrounded on both sides by a treeless, windswept, and totally empty golf course to the hotel casino itself which was a fantastic thing like something out of a Disney theme park.

Under the entrance portico I was met by a tall, thin black man dressed up as Uncle Sam (all in red, white, and blue satin with a top hat, tail coat, and brightly colored suspenders… Braces if you are from the UK.).

Inside, the theme was 1800’s New Orleans and the Mississippi… The staff were dressed up like saloon keepers with straw boater hats and sleeve garters. The hotel was quite luxurious and new but it seemed very odd to find all this pseudo-Americana in the depths of Africa.

The next morning I drove out the SASOL plant and that also was more than a bit surreal. The synthetic fuel plant had been developed to circumvent the oil embargo imposed by the world community during the apartheid era and, inevitably, was a target for the anti-apartheid guerrillas. On the morning I drove out, a huge thunder storm was drifting in from the west, looming over the plant… And the plant was heavily fortified with armored watch towers. The overall impression that morning was like something out of a high-tech, industrial Lord of the Rings.

This visit took place a few years after the collapse of apartheid. Unfortunately, the end of apartheid has made South Africa, if anything, even more dangerous than when there was an ongoing civil war. All the South African engineers I worked with routinely carried guns when they drove to and from work… There were lockers at the gatehouse where you left you gun while at the plant. As a visitor and not being familiar with the local modus vivendi, I was pretty worried. Rather like a Japanese tourist who got parachuted into the South Bronx or Watts.

What I want to focus on here is the second fiber mat process. One cannot spin Boron Nitride fibers directly so the process involved spinning boron oxide glass fibers first and then nitriding the BO with ammonia to convert it to BN.

As I mentioned, the fiber mat we wanted to end up with looked a lot like fiberglass wall insulation so the BO glass spinning apparatus was modeled on a commercial fiberglass spinning system. This was comprised of an electrically heated metal tank that stored the molten boron oxide glass, a metering valve, a perforated spinning cup, and a torch system.

The molten boron oxide glass was metered into the spinning cup where it was thrown against the side by the centripetal force. It then extruded through the holes in the cup a formed a cloud of glass fibers surrounding the cup. The torch was positioned so that it melted through the fibers once they reached a certain radius from the center of the cup so that one would get a consistent fiber length in the mat.

In the commercial fiberglass system, the torch would have been supplied with either natural gas or propane. But boron oxide glass is very hygroscopic; in other words it soaks up moisture from the air. When exposed to humidity it ends up looking like sticky cotton candy. And, of course, a major combustion product of both natural gas and propane is H2O.

So what to do? We needed a torch fuel that didn’t produce water vapor as a product of combustion. I don’t think it was me that thought of it but somebody on the team came up with a very elegant solution. We used carbon monoxide as the fuel and that worked quite well. It burned hot enough to cut the fibers as needed and the only combustion product was CO2 so we didn’t end up with cotton candy. Neat, eh?

I worked for a couple of years on the CUPROSUL process. This process used copper sulfate to scrub H2S out of various gas streams (the principal application was scrubbing geothermal steam). In the original process concept, the sulfur contain in the H2S ended up as ammonium sulfate. It was originally hoped that the ammonium sulfate could be sold as fertilizer. Unfortunately, ammonium sulfate is not widely used as fertilizer in the developed world…

And even worse, the ammonium sulfate that resulted from using the process to scrub geothermal steam contained contaminants that were unacceptable in a fertilizer. This meant that there was no market for the ammonium sulfate and that one would probably have to pay for its disposal.

So, what to do? I had done a literature survey on the reactions used to regenerate the copper sulfate from the copper sulfide produced in the scrubber. From reading the articles it was evident that scrubbed sulfur was briefly present as elemental sulfur in the stirred tank regen reactors but that it was quickly oxidized to the sulfate given the rather severe temperature and oxygen levels.

It occurred to me that, if we could somehow protect the elemental sulfur from further oxidation, we might be able keep it in its elemental form rather than end up with the sulfate form. So I went looking for good sulfur solvents that were immiscible in water and were poor solvents for oxygen. It turns out there are quite a number (including olive oil) but I decided to run an experiment with a chlorinated hydrocarbon which we had in the lab and that seemed to have the desired solvent characteristics.

I took a quantity of the aqueous copper sulfide slurry produced by the scrubber and I oxidized it in an agitated beaker in the presence of the chlorinated solvent. The slurry eventually disappeared and I stopped the agitation; allowing the two solvents to separate. I then decanted the chlorinated solvent into a pan and left it to evaporate in a fume hood. The next morning the pan was dry and covered in sulfur crystals.

That was very satisfying but, of course, we still had to look at the economics of an elemental sulfur by-product. A first pass analysis showed that elemental sulfur by-product did look more promising than sulfate but that the impact would vary by region. The cost of sulfur varies quite widely around the world. Some areas have vast amounts of mineral sulfur that is cheap to mine. Other areas have widely used processes that produce elemental sulfur as a by-product.

So the process modification was not a complete homerun but it did offer the prospect of changing the by-product produced to suit the local market.

I have seen organizations jump the gun several times in my career. For one thing, it is never a good idea to move to the next scale if you do not understand the results you are getting at the current scale. I have seen an organization increase from pilot scale to commercial scale even though they were finding that their pilot scale experiments were not repeatable. Needless to say, they then demonstrated their lack of process understanding at the larger scale… At vastly greater expense.

Another example occurred back in the late 70’s when I worked in Polaroid’s department T-22. My role was to scale up processes that the photo and organometallic chemists developed in the lab:

One of chemists asked me to do a pilot-scale production run of a new “receiver layer” system that he had been working on. I asked him to describe how he created the system in the lab and he listed various steps, one of which was the addition of a ferric salt followed by what he called an “incubation period.”

That raised my eyebrows a bit since I didn’t recall that bit of jargon from my reaction kinetics classes and I asked him what he meant by “incubation period.” He was a bit sheepish about it but said that he was adding the ferric salt as a mild oxidizing agent and that it took several minutes before the oxidation that he was looking for was complete.

Since he was using an open beaker, I asked him if he was sure that the ferric was doing the oxidation and not oxygen from the ambient air. I suggested that the “incubation period” might simply be the time required for oxygen to transfer from the room air into the agitated beaker. He was a bit taken aback by the idea but felt that we should test it.

So we reran his laboratory experiment in a narrow mouth flask and sparged the mixture with nitrogen to exclude the room air. We found that we could leave the system indefinitely and that his oxidation would never occur. This confirmed that the ferric had no effect and that the ambient oxygen was the key to his reaction.

The point I am making is that we confirmed this by doing additional lab-scale work with quite small costs in terms of equipment, chemicals, and manpower. We would inevitably have figured out the ferric vs O2 issue at the pilot scale but it would have cost us thousands of dollars more and at least a couple of weeks of time. Once we realized the role of gaseous oxygen, I built a controlled-environment lab setup with a gas manifold that allowed us to meter in the oxygen from a gas cylinder. This allowed us to control the oxidation very precisely and was the approach we used when we finally did move to pilot-scale production.

While working for AspenTech, I modeled an ammonia plant for a customer in Japan. The customer gave me the process flow diagrams and the current operating parameters and I built that into a steady-state model.

A key section of the process is the syngas loop where a mixture of hydrogen, nitrogen, and ammonia is circulated through a reactor where the hydrogen and nitrogen react to produce more ammonia.

And a key piece of equipment in that loop is a large multi-stage turbo-compressor. I didn’t try to model the compressor rigorously (i.e. using performance curves), I simply varied the compressor stage efficiencies until I matched the temperatures, pressures, flows, etc. that I have been given by the customer. But I was surprised to find that I kept coming up with efficiencies that seemed much lower than I expected for a turbo-compressor.

During a meeting in Japan, I discussed the issue with the customer’s engineers. The two engineers that were my main contacts (they were younger and spoke English) agreed that the efficiencies I was calculating were too low and we started discussing what might be causing the discrepancy. But there was an older customer engineer present who had been around when the plant had been built twenty years earlier. Once he figured out what we were talking about (he didn’t speak English) he told us that the low efficiencies were probably correct.

So what was going on? The ammonia process has been around for quite a while and ammonia plants can be bought “off the shelf” from a number of licensors. Most of these plants are used to feed fertilizer plants and they are typically designed to produce (if memory serves) about 1100 tons per day of ammonia. But the plant I was modeling was not being used to feed a fertilizer plant; the ammonia was being used to supply other processes in a large integrated chemical complex. And the ammonia demand was significantly less than 1100 tons per day. And the volume of gas going through the turbo-compressor was much less than it was designed for. When we manually checked the compressor performance curves with the “as operated” flows, my model’s efficiencies suddenly looked reasonable.

It was then very easy to use my model to calculate the energy savings that would result from increasing the efficiency by, say, 15%. When the customer’s engineers priced out the cost of modifying the compressor to achieve this, the payback period was about 6 months. I was later informed that the necessary modifications were made at the next plant shutdown.

A satisfactory outcome but it is sobering to think how much money was wasted over the previous years of low efficiency operation.