[HomePage] [TitleIndex] [WordIndex] 

Process Module

Although dynsim is primarily a process control simulation tool, it is convenient to bundle some of the characteristics of whole process units into a class rather than have to construct these out of fundamental calculation and dynamics code for each simulation. This considerably speeds up the construction of a simulation containing process units such as a slurry tank, where slurry densities become important. Hence the existence of the dynsim.process module.

However, it is important not to go too far down this path. dynsim is implemented in pure Python to exploit the simplicity and convenience of the language, but also needs to maintain that convenience by having a quick turnaround in simulation executions (debug-edit-run cycle). So there are limitations on the level of complexity that can be conveniently handled. Consequently, it doesn't make sense to extend dynsim.process to include (for example) an arbitrary size multi-phase vector of mass-flows (e.g. population size distribution). Of course, users of dynsim are free to construct their own additional class modules for higher-fidelity process models specifically for process simulation.

The dynsim module contains a library of models of process elements aimed at two phase flow (mainly intended for slurry streams). It defines both a stream class (with useful methods for SG, %solids, etc.) and some process unit operations, most of which use streams (such as tank, thickener, hydrocyclone). All inventory units (e.g. tank) are coded to rigorously enforce a mass-balance, including possible overflows/spillage.

The stream object takes care of all routine calculations associated with the 2-phase flows (such as SG, %solids, etc.), including being able to do simple arithmetic (+,-,x,/) directly on the stream objects:     combined_stream = 1stStream + 2ndStream 

Some of the classes deal with stream inputs and outputs, including:

and some are just helper classes that handle scalar values (e.g. flows) conveniently:

It is important to check the class docstring to identify whether call arguments are streams or scalars.

2-phase "stream" features and limitations

The 2-phase flow components can be almost any material, including air, liquid, solids, bulk-solids. A stream is fundamentally treated as a pair of mass flows, each with a nominal SG (to allow calculation of stream %solids, SG, volumetric flow, etc.). In dynsim, the SGs are known as sgSolids and sgLiquid but this is only for convenience and these two can represent any two phase-SGs.

Setting the SGs

Conventions for Process Simulations

Process simulations tend to be larger and involve a variety of objects and variable types. To make these simulations easier to manage, some conventions on object naming and units are suggested here:

Units are assumed to be:

You will notice immediately that all the units are in metric, but generally in units which correspond to common use in the process industries.

There is some flexibility in using alternative units, as the classes are largely unitless and just assume metric. However, for time dependent classes a default time conversion factor of 60 is used (based on simulation time units of minutes) to convert between flows (m3/hr) and accumulating volumes (m3).

It is recommended that all internal variable and argument naming is standardised where possible by using lower case prefixes to define the object type, then an identifier starting with a capital letter. For process oriented models, some suggested prefixes are:

For example, a cyclone feed tank might be named "tCF" to be both descriptive and short enough to maintain readability of code. The underflow of the tank might be named "fCFUF". Obviously, this is all up to the user since dynsim imposes very few constraints on how it might be used. There are many alternative nomenclature conventions that can be used; the important advice is to pick one and stick to it.

Ideas/Hints

2015-05-14 10:33