Steam drum boiler model

Yes, interesting.

Steam quality relates to liquid water carried away entrained in the steam as droplets.

I don't think so. I think riser wall refers to the tube wall that is the main heat exchange surface of the boiler, where water boils as it rises from the lowest point in the water circulation system (usually a lower distribution header below the drum) and reenters the drum near the drum water surface level. The risers contain a mixture of water and steam, so their surface temperature can be above the drum temperature. See:

I haven't seen this model, and it will take me quite a while to try to digest everything in this article.

It worries me that the model does not appear to contain (if I am understanding what I an seeing) a term for the make-up water temperature (or the difference between the drum temperature and the make-up temperature). This factor has a strong effect on boiler stability.

I looked quickly. Usually quality is used to express the proportion of saturated steam.

This is the first I have seen for a boiler.

I would use a model like that if I were designing boilers. I think mathematica should have picked a simpler example because no one is going to work their way through this example unless they have a need to design boilers. The example is poor because the different states are clearly explained. There must be more information for this example somewhere that we don't have access to. A simple example were a hot and cold water valve or pump controls the level and temperature in a tank would have been better.

I do modeling all the time. I was working on a modeling problem this weekend. I usually start simple and add to it as the need for better simulations arise and time permits. I have done hydraulic simulations where there are equations for the pump, accumulator, valve spool position, flow, the change in pressure in either side of the piston, force, acceleration, velocity and finally position. I can't use state space because the system is non-linear. All this is necessary and I still don't account for the pressure drops due to length of piping.

It is safer to use models to prove a system will not work. I have saved customers a lot of money by just doing this. I don't think it is safe to use a model to predict a model will work unless you are very sure of the model. If I do give the design the OK I usually can see exactly what is going to be the factor that restricts performance. Too many hydraulic designs fail because components were just thrown together and they expect the motion controller to correct for design deficiencies.

Peter Nachtwey

-- snip --

I would completely agree with that last sentence if you would just take out the word "hydraulic".

It's amazing how much money you can spend on a design project by not doing it right the first time around.

I think that Peter's reply touched on a lot of the points that I would make, but I want to put a different spin on it:

There is no one right way to model any given system, or part of a system. No mathematical model is ever 100% right, and the more accurate you make your model the more expensive it is to design and maintain, and the more accurate your model is (usually) the more difficult it is to analyze it or simulate it.

So you should never try to make a model that is 'good' in a global sense, you should only try to make a model that is accurate enough for your purposes. Get it too accurate and you're wasting time, don't get it accurate enough and you're wasting money (and time, and aggravation, and, and, and).

For example:

If you are doing preliminary design on your control system, you should model things accurately enough so that you know what sort of valves, actuators and whatnot you need to use; at this stage of the game your model only needs to be accurate enough to give you a fairly conservative estimate for the speed and accuracy of your actuators and sensors, and the sampling rate and complexity of your control rule (which will determine how fancy of a controller you need to specify).

If you're going to have a chance to work with the physical plant before the whole system is commissioned (or before your product goes into production, if you're building a production machine), and if the health of your plant and the people in it's vicinity doesn't depend on the controller, then you may be able to abandon your modeling effort at this point.

On the other hand, if your controller has to be right the very first time (such as with modern fighter jets, which can't be flown unaided by human beings), then your model may cost more to produce than one item of your plant.

Note, too, that your purposes may be completely different from the guy sitting next to you. You may have a model of a steam boiler that took you a man-year to develop, that will let you simulate not only normal, but all sorts of abnormal operating modes without leaving your desk, and that will let you do all the control system design in the world. Yet, if someone comes to you and asks how think the concrete needs to be under the supports for the boiler, your model may not be able to provide the first clue about how much the darn thing will weigh. So _you_ may have the Most Elaborate Model In The World, while the engineer next to you may have one, too, of the same thing, and the models may be _completely different_.

Tim Wescott wrote in news:VZudnRHx- u6zaYjVnZ2dnUVZ snipped-for-privacy@web-ster.com:

Have you ever looked at the FDA waterfall approach to medical device design? These days, its almost mandatory if one wishes to seek FDA approval. It's not such a bad exercise.

I have not. If it's a pure waterfall model then it'll work well if you're designing something that you already know how to build. This would be consistent with what I've been told about life-critical design for medical and flight software -- you get it working as an experimental prototype, archive your design onto difficult-to-access media, and do it again from scratch the 'right' way.

Most design efforts that I've been involved in are either "stumble around spending money and time while management plays head games", or are the 'spiral' model, where you do ever-descending 'mini-waterfalls' until you finally have a product. The former is generally good for whoever gets promoted before the fertilizer hits the fan*, the latter is good for getting a pretty darn good (but not entirely bug free) product to market in a reasonable amount of time.

• Did I mention that I'm no longer temperamentally suited to being an employee? It's a good thing I have skills as a consultant...

If x3 and x1 vary independently, there are only two possible reasons - (1) no boiling, and thus no steam, and (2) superheated drum contents, which implies non-equilibrium behaviour and *very* complex behaviour.

Steam quality as I know it is the percentage of vapour in the steam. I'm not sure how a thermodynamic model will derive this, it's a characteristic of the separation internals within the drum. Empirically, it drops off if the steam draw is very high.

The analysis focusses on sine wave response and stability. The real issue is not that, practical boilers can almost always be controlled tolerably while the load is high. The problems occur when load drops off, the poles shift closer to the imaginary axis and response gets more and more sluggish and oscillatory.

Tim Wescott wrote in news:apudnZc5EbQ6MYvVnZ2dnUVZ snipped-for-privacy@web-ster.com:

Worth a look