Previous   Next   Contents

3. User Manual

3.1. Theoretical Background

Simulation is done by steps, thus modeling the evolution of technical system in physical time. For all components of an assembly, two-step time integration scheme is used to ensure more accurate solution with a numerical error of second order in time.

      The entire engine operation cycle is simulated on the basis of one- and zero-dimensional thermo- and gas-dynamical models.
      All these models are based on the model of gaseous working fluid. Its properties adopted here are properties of 2-component mixture. In case of engine simulation these 2 components should be: fresh air and pure burnt gases of specified fuel, with specified air-to-fuel ratio (AFR). Molar weights of these 2 components may differ, and their heat capacities can be approximated with polynomials.

      The core of modeling program is the set of models of components and connectors.
      Components used in this version are Atmosphere, Vessel, Duct, Cylinder and Crankcase. Component Duct represents a one-dimensional profiled pipe. One-dimensional unsteady conservation laws are used to describe motion of the gaseous mixture along the Duct:

1D cons. laws

      High-resolution shock-capturing finite-volume numerical method is used to solve these equations numerically for each computational cell on each time step within the duct. This conservative scheme provides low numerical dissipation and good convergence to accurate solution.
      Duct can account of wall friction on the basis of built-in usual relations for smooth and rough ducts, and also has a model to account for heat exchange. Instead of use built-in formulas, the user optionally can set its own (constant :-() coefficients to compute friction and heat exchange for each Duct.
      Other components are more or less complicated vessels, of which Cylinder is the most interesting. It uses some built-in empirical models to account for heat exchange (model of Woshni), combustion (model of Vibe) and a model of scavenging (perfect mixing or two-zone with empiricism).

      For the simulation of flows in pipelines the concept of local flow restriction is used. Local flow restriction (local restriction -- LR) is an abstraction that serves as a replacement to a real element of the piping -- location at which some sudden flow redistribution takes place and pure 1D formulation cannot be used to "close" the problem.
      All connectors (assembly elements used to interconnect components) use similar concept.
      The simplest possible type of LR is the one on which the flow takes place without splitting. This type of connector, named Restriction, is used to model this case. Only the next three types of models for such connector are imaginable:

      When using the above listed LR concept, we are facing certain simplification that, however, helps to describe real (dissipative!) flows still in 1D formulation. These models require some additional information to close the 1D flow problem -- they need some empirical data on the properties of actual flow on connector.
      What is follows is a short theory on empirical relations needed for and used by Restriction.

      Click here for more detailed description of underlying theory.

3.2. Quick Start

Let us explore the simulation technology using an extended example. We'll simulate two-stroke opposed piston engine with some tuned exhaust (exhaust pipe here has a closed end and a chink that connects it with the exhaust vessel).
      First you should run the GUI program. Do it either by clicking on the application icon (if it is already placed on the Desktop):

Icon

or by running bin\hpl1dw.exe (or hpl1dw.bat) via Explorer or some file manager. Main application window will appear:

prj-2-stroke-opposed

Fig. 1. Main program window with project 2-stroke-opposed loaded.

      If the project shown on Fig. 1 doesn't seem to be loaded, click on button on the toolbar or choose Project->Open menu item. The dialog box will appear:

open

Fig. 2. Dialog box for choosing the project to open.

      Choose 2-stroke-opposed and click OK. The project will be [hopefully] loaded and shown now; it must be ready to begin simulation of such an engine. But now it is right time to explore structure of engine assembly and the properties of its modules: components and connectors. The details of modules' internal data will be revealed in Modules Reference.
      Here we'll concentrate on which actions can be done on the project.

      Modules can be added to the assembly. By clicking on button on the toolbar or choosing Dialog->Components menu item we'll get a palette with available Components (see Fig. 3); similarly a Connectors palette (Fig. 4) can be invoked with or Dialogs->Connectors command of the main menu. Both palettes are used as a source for dragging new modules of both kinds onto the assembly field view.

components

Fig. 3. Components palette.

connectors

Fig. 4. Connectors palette.

      Modules can be moved within the assembly field. Right-click the module image with the mouse (or left-click it, holding the [Shift] key pressed) to make the module image movable. Drop the module onto the assembly field again, but please be informed that modules can not be put: (1) onto and too close to another module; (2) outside of the limiting rectangle; (3) underneath of either of palettes; (4) outside of the visible part of the assembly field view (if the user wishes to cancel dragging a module either within an assembly field or from one of "palettes", right-clicking the mouse can help).
      Modules can be copied/deleted. Use context menu that appears on right-clicking the module image. But don't abuse this feature -- the GUI lacks Undo/Redo operations; so now it is the only way to undo changes -- to reload the project from disk:-(!
      Links can be drawn between the modules. Click on the module within the sub-image of its some free port (a small rectangular area on image's side); Then click on free port of the module of the another kind. Immediately the link (a thin "wire") will appear. It can be deleted [now] only if we delete either of the 2 modules interlinked.

      Now we go to the actions we do with the loaded project. If we are sure that the changes we have made during the editing session are correct, we may save our project. Pressing button or choosing Project->Save menu command does this. If we are to initiate (fork) a new project from the current, we can Save it As.. (Project->Save as). The program will ask for the name of this new project -- that will be the name of project directory under .\prj\ (see. Fig. 5).

saveas

Fig. 5. Dialog that gets new project name while "Saving as..".

      An alternative for creation the new project is to point to another project to use it as prototype (creation of blank project is not supported now!). To create project this way, click on button or choose Project->New command of main menu. Then the user should choose the name of the prototype project and enter the unique name for a new project (Fig. 6):

create

Fig. 6. Dialog box to get name for the prototype and for the project to create.

      Running simulation is done by clicking run-button button or choosing Command->Run (or using [F9] keyboard shortcut). This will start solver program in its own console. Solver will read and process input data saved to disk (file prj\[project-name]\input). When the solver is started from the GUI auto-saving is forced. An alternative way to run solver is to run it from the command line. You may go to the package's "root" directory, e.g. C:\hpl1d and run command file hpl1ds.bat for execution. Or you can (when in the package's directory again) type in the command like:

      hpl1ds [-v] [-p] [-t] 2-stroke-opposed

      where -v (or --verbose), -p, ... etc. are command line switches (brackets: [..] denote that they are optional). Switches can be learned by running hpl1ds without arguments.
      For this particular case (shown on Fig. 7) the computed indicated parameters are being written by solver to console at each engine cycle. Solver (when invoked with -v option) produces verbose messages (mainly at start up, not seen here). It also reports the time elapsed -- since -t option presents. Elapsed time here (on Fig. 7) is for AMD Sempron 3200+ running at 1.94 GHz. Solver also prompts user for a keystroke to terminate solver's console after the successful simulation, when run with -p (or --prompt) option (in this example -- after 40 cycles of 2-stroke engine).

solver running

Fig. 7. Console window of the solver.

      Abnormal termination of running solver is done by clicking or Command->Terminate menu item (or by pressing [F10] key). Output data files will be corrupted (truncated) this way. The same result appears if one closes the solver's console window from Windows.

      General indications on number of time steps, etc., are adjusted via General dialog box for each project. In our case this dialog looks like on Fig. 8. This dialog appears on choosing Dialogs->General menu item, or on hitting [Shift+G] shortcut key combination, or by clicking on the assembly field.

general

Fig. 8. General dialog.

      Pressing button "Run simulation" will cause saving all unsaved project data and running the solver. There is only one file being written on disk while doing "Save" operation -- the file .\prj\[project-name]\input. In our case [project-name] is 2-stroke-opposed.
      Now it is time to start exploring this file. It consists of "sections". The first section is GENERAL; then comes small ASSEMBLY section, after it -- a large MODULES section, with 2 sub-sections for COMPONENTS and CONNECTORS, and after these, there are three sections with settings of output data streams: SCREEN, TRACK and INDICATOR.
      The following data (placed at the beginning of .\prj\2-stroke-opposed\input file) corresponds to data shown in "General" dialog box (see Fig. 8):

   # hpl1d.098 input file #######
   #
   # project: "2-stroke-opposed"
   #
   ##############################

   #=== section GENERAL

   numstep     = 57600  # number of steps
   deltaT      = 0      # step in time [sec]
   deltaPhi    = 0.25   # step in crank angle [deg.]
   flag_t_phi  = 2      # deltaT - 1; deltaPhi - 2 [-]
   rpm         = 6000   # engine speed [rpm]
   flag_prstep = 0      # print each flag_prstep-th step
   stroke      = 2      # 2 or 4-stroke engine

      Section GENERAL describes main features of every simulation. The example above shows that (flag_t_phi = 2) the stepping will be governed by step in [crank] angle, not by step in time. Its value is 1/4 or 0.25 of a degree (deltaPhi = 0.25). Value of time step will not be used in this case so it can be of any value (in particular, zero: deltaT = 0.).
      Angular stepping generally means that some cylinder is present in assembly, i. e. some piston engine is simulated. In this case the engine speed must be given -- here rpm = 6000 (rpm - revolutions per minute). Type of engine cycle is given by stroke = 2 (obvious). If the user wants to model exactly 40 engine cycles, solver must do modeling over numstep = 40×360×(stroke/2) / 0.25 = 57600 steps. Variable flag_prstep specifies if step numbers are to be printed out by solver; value flag_prstep = 0 makes solver not to print step count at all, flag_prstep = 100 -- that only every 100-th step should be reported (CPU load due to this output is diminished this way).

      Section ASSEMBLY stores only 2 pairs of coordinates for the limiting rectangle for actual workspace on assembly field (in pixels). This rectangle is used solely by the GUI, it can be virtually unlimited, and it affects also assembly window scrolling ranges. It, however, limits the area in which modules can be placed.

   #=== section ASSEMBLY

   rect_asm = 90,60,770,520 # ...limiting rectangle [pix.]

      Coordinates of this limiting rectangle can be re-set by "Assembly" dialog in GUI:

Assembly

Fig. 9. Assembly dialog.

      After ASSEMBLY section there is a large MODULES section in file .\prj\[project-name]\input. Modules are described in detail in Modules Reference. Here we'd draw the user's attention to setting parameters of output data streams (pre-processing) and visualizing and interpreting the simulation results (post-processing). Three "data channels" can be used to output results for engine simulation test case. SCREEN data channel (see SCREEN section in .\prj\2-stroke-opposed\input file) is written to file .\prj\[project-name]\screen by solver program. It has binary format (for compactness) and can be imaged by means of GUI and exported as text file, or saved as bitmap (BMP) file. Data stored in .\prj\screen is nothing but records of parameter values taken by virtual probes each placed within either component or connector. This set of probes and their properties can be edited easily using a dialog box that appears after choosing Dialog->Screen menu command (the same does a keyboard shortcut [Shift+S]).

Screen settings

Fig. 10. Dialog for editing SCREEN settings.

      As it is seen, up to 8 probes can be used in this version.
      For any probe placed within some module of Component kind (Atmosphere, Vessel, Duct, Cylinder or Crankcase), one of following parameters can be chosen for recording: pressure P [Pa], temperature T [K], velocity Ux [m/s] and composition Y [-]. The latter parameter is the usual Y for components: mass fraction of the 1st component of mixture on the probe. Velocity is set to zero for all Vessel-like components (i. e. all component types except Duct).
      Probes may also be paced at any Connector -- of type Restriction or Splitter. Since connectors are for evaluation of fluxes, one of following parameters can be recorded here: mass_flux G [kg/s], mass_flux1 G1 [kg/s] (mass flow rates (1) of the mixture and (2) of the 1st component of the mixture only, e. g., fresh air, so |mass_flux| ≥ |mass_flux1|) and also lift_area h [m or m2] -- which is useful mainly for the restrictions with variable lift (or some characteristic cross-sectional area) prescribed by h(t) or h(phi) tables.
      User must also prescribe starting and ending time steps and a number of time steps for each frame (SCREEN data may contain more than one frame -- a useful feature for comparing engine cycles etc.).
      Note that in order to output some parameter on "probe" placed within some Duct, the user must enter non-negative x-coordinate of the probe. This x-coordinate is measured along the duct from the Duct's [0]th port to its [1]st port. If, however, this x exceeds the Duct's length, the solver hpl1ds will output an "odd" value of 1.0e+20 for any parameter, thus indicating that the x-coordinate specified is wrong.
      After the simulation run is complete, clicking on button or choosing Command->Screen menu (or pressing [F7] key) starts a dialog box that "plays" the record read from .\prj\[project-name]\screen file (Fig. 11). Here we can see parameters curves corresponding to settings shown on Fig. 10, with 8 "probes" placed at given locations of engine's ducting, during its 40th cycle. Moment with piston at BDC is in the middle.

screen

Fig. 11. "Playing" the SCREEN record.

      This record (Screen) can be "scanned": user can read parameter value moving vertical scan bar along time axis using arrow keys, with [Shift] key helping to do big jumps and [Ctrl] key for very big jumps. Keys [PgUp] (or ['arrow-up']) and [PgDown] (or ['arrow-down']) serve to change the parameter curve to scan.

      Here is a list of commands to control Screen window, each one corresponds to the button on a toolbar (Fig. 11), from left to right:

   Open another screen [O],
   Save screen as.. [B],
   Save screen as text.. [T],
   Close this window [Q],
   Scan data [S],
   go to Next parameter [PgUp],
   go to Prev. parameter [PgDown],
   Move to left [[Ctrl+]'arrow left'],
   Move to right [[Ctrl+]'arrow right'],
   go to Previous frame [P] or ['arrow down'],
   go to Next frame [N or 'arrow up'],
   go to First frame [F or Home],
   go to Last frame [L or End],
   Take snapshot [H] and save it to BMP file.

Screen scanned

Fig. 12. "Scanning" the SCREEN record.

      The graph has a legend (see Fig. 11) showing parameter names and colors of curves. Right-licking some of 5×4 grid cells will either relocate this legend or hide it (or show it again). Note that clicking the region with horizontal labels at the bottom of the graph changes mode of output of these labels. By default, labels show time steps, but when changed, these labels show either modeled time (in seconds) or the basic crank angle. Crank angle is measured from 0 degrees at time = 0 and wraps around each 360o or 720o, depending on the engine type (2- or 4-stroke) given in GENERAL section of file .\prj\[project-name]\input (and in General dialog in GUI).
      Left- (as well as middle-)clicking the graph area changes the mode to scan mode and back. While entering the scan mode the horisontal position of appearing vertical scan bar is tetermined by the mouse pointer. Clicking at another point again moves this scan bar, which is rather convenient. Right-click on the graph area while in scan mode exits this mode.
      Mouse wheel allows easy changing parameter graphs when in scan mode (Fig. 12), or to change the graph frame (in case of multiframe Screen record) when not in scan mode (Fig. 11). Current frame number is shown at bottom right corner of the graph area.

      TRACK data channel (see TRACK section in e.g. .\prj\2-stroke-opposed\input file) is (optionally) being written to file .\prj\[project-name]\track by the solver. This [binary] file holds nothing but animation of parameters written each intervalth step along the sequence of chosen modules-components. The dialog box that sets this data channel is invoked by Dialog->Track menu command or using [Shift+T] shortcut.

track-set

Fig. 13. Dialog for editing TRACK settings.

      Clicking on track-button button or choosing Command->Track menu (or pressing [F8] key) starts a dialog box that "plays" the record read from .\prj\[project-name]\track file (Fig. 14). This animation can be rather impressive and helps to find out what happens in the tuned engine ducting.

Fig. 14. "Playing" the TRACK record.

      TRACK can also be "scanned" (see Fig. 15). Navigation while scanning here is similar to that of SCREEN "player" dialog. TRACK can be read from or written to a file on hard disk as well.

      Below is a list of commands that can control TRACK window, each one corresponds to the button on a toolbar (Fig. 14), from left to right: 

   Open another track [O],
   Save track as.. [B],
   Save track frame as text.. [T],
   Close this window [Q],
   Scan data [S],
   go to Next parameter [PgUp],
   go to Prev. parameter [PgDown],
   Move left [[Ctrl + ]'arrow left'],
   Move right [[Ctrl + ]'arrow right'],
   make updating Slower [L],
   make updating Faster [F],
   Rewind [W] record,
   Pause/Resume playback [P/R],
   Take snapshot [H] and save it to BMP file.

Track scanned

Fig. 15. "Scanning" the TRACK record.

      Some of the above listed commands are supported by mouse. Left- (or middle-) click on a graph area changes to scan mode, right-click changes back. When entering scan mode, vertical scan bar position is determined by position of the mouse pointer. Clicking by the left mouse button re-positions this scan bar, and a mouse wheel helps much to change between graphs (in scan mode).

      The next (and the last) channel of data output -- INDICATOR. It is being written by solver to standard output and thus to console. On Fig. 16. Indicator dialog box is shown. It is invoked from the main menu by the command Dialog->Indicator or using [Shift+I] shortcut.

Indicator settings

Fig. 16. Dialog for editing INDICATOR settings.

      As it can be seen from Fig. 16., the user can switch on/off certain indicated parameters. Parameters are being printed out for each cylinder separately. Now it will become much more clear what does each parameter of INDICATOR mean. We can take data sample from Fig. 7:

   ----- INDICATOR output for 40th engine cycle: -----
   N_i = 3.0114 kW
   H = 87.574 J
   L = 30.114 J
   eta_i = 0.3439
   m0_fresh = 0.030582 g
   G_cyl = 14.8524 kg/hour
   eta_V = 0.6098
   phi = 1.3490
   -----

      where eta_V is charging efficiency and phi is inverse value of trapping efficiency. Let us check these figures using some input data from files input and thermo:

   ----- file "thermo" -----
   lambda = 0.95  # Excess air factor
   lo = 14.7764  # Stoichiometric ratio
   Hu_m = 2727957 J/kg  # Mixture strength
   R_air = R_g1 = 288.23 J/(kg*K)  # Gas constant of air
   ----- file "input", GENERAL section -----
   rpm = 6000 rev/min  # Engine speed
   stroke = 2
   ----- file "input", data for cylinder[0] -----
   D = 32 mm  # Cylinder bore
   r = 13 mm (s = 2 × r = 26 mm)
   opposed_piston = 1  # An opposed-piston engine!)
   x_z = 0.98
   -----

      So:

   effective mass flow rate (after accounting for scavenging losses)
     G_cyl_eff = G_cyl / phi = 14.8524 / 1.3490 = 11.0099 kg/h.

   trapped mass of air (per one 2-stroke cycle):
     m0_fresh = (G_cyl_eff / 3600) / (rpm / (30 × stroke) = 3.0583e-05 kg = 0.0030583 g, right.

   atmospheric air density:
      rho_a = | as in atmosphere[11] | = p_a / (R_air * T_a)
          = 101325 / (288.23 × 293.15) = 1.19919 kg/m3.

   number of pistons per cylinder
     i = (opposed_piston + 1) = 2.

   displaced volume:
     V_h = i × M_PI × D × D × s / 4 = 2 × 3.1416 × 0.032 × 0.032 × 0.026 / 4 =
         = 0.00004182 m3.

   charging efficiency:
       eta_V = m0_fresh / (rho_a × Vh) = 3.0583e-5 / (1.19919 × 0.00004182) = 0.6098, right.

   masses of fuel and mixture per cycle:
     AFR = alpha × lo = 0.95 × 14.7764 = 14.0379 kg.air/kg.fuel
     m0_fuel = m0_fresh / AFR = 3.0583e-5 / 14.0379 = 2.1786e-6 kg.
     m0_m = m0_fresh + m0_fuel = 3.0583e-5 + 2.1786e-06 = 3.2762-5 kg.

   heat released in a single cycle:
     H = Hu_m × m0_m × x_z = 2727957 × 3.2762-5 × 0.98 = 87.574 J, right.

   indicated efficiency (mixture losses [if present] are NOT accounted for):
     eta_i = L / H = 30.114 / 87.574 = 0.3439, right.

   indicated power output:
     Ni = L × f = L × (rpm / (30 × stroke)) = L × (rpm / 60) = 30.114 × 6000 / 60 = 3011.4 W = 3.0114 kW, right.

   fuel consumption:
     G_fuel = m0_fuel × f = 2.1786e-6 × 100 = 0.00021786 kg/s = 0.784296 kg/h.

      In the paragraphs below, some more advanced topics are covered; Modules Reference deals with explanations of initial data sets (TODO: and their textual presentation in file input!), Program Interface describes how the whole package is organized and some settings, Tools Reference can be used as set of mini-manuals for Tools (programmed models that are outside of the solver) and Examples briefly describes a set of example projects in different areas, the projects that can be used as a robust starting points for the user's own simulation projects.

      Finally, it should be noted that either clicking on button, or choosing Help->Contents or pressing [F1] brings up a HTML browser with starting page of this HTML help system.
      And choosing Help->About gives you the following window, which also might be useful:

About...

Fig. 17. "About" window.

3.3. Modules Reference

      In this section the user can find more detailed information on the modeling capabilities of the package. To some extent, internals of modules -- components and connectors -- are revealed, and the meaning of the input data needed for simulation are explained. More detailed page on modules can be found here.

3.3.1. Components

Below all 5 types of Components are described very briefly. All of them use identical thermodynamics of the gaseous working fluid, represented by the properties of the mixture composed of 2 thermally ideal gases with variable heat capacities. Updating internal state of components is done by solving conservation laws numerically. Conservation of masses of 2 mixture constituents and internal energy of the mixture is ensured. For Duct (the only component with velocity defined), the momentum equation is also solved numerically. Fluxes of the conserved quantities (mass, momentum and energy) are taken from components' ports and then the components' states are updated. Numerical integration is done with uniformly 2nd order of accuracy in time.

3.3.1.1. Atmosphere

Component Atmosphere serves to set the constant state and composition of gas mixture in certain points of the assembly. It behaves as infinite volume of gaseous working fluid, e.g. atmospheric air (Y=1) or any mixture of air and the products of combustion (Y<1).

3.3.1.2. Vessel

Vessel component represents finite volume of perfectly mixed gaseous fluid. During the simulation, its variable state and composition of gas mixture is governed by the laws for open thermodynamic system. However, the heat exchange with walls is not modeled, i.e. Vessel (in this version) behaves as a finite volume adiabatic vessel.

3.3.1.3. Duct

Duct represents a channel or pipe in which one-dimensional unsteady motion of gas mixture is modeled in space and in time. It uses computational mesh of equally spaced finite volumes and solves the unsteady 1D gas dynamics conservation laws numerically. Two high resolution conservative numerical methods can be used, one (*regular*) which is perfect for high flow intensities/variations, another (*fast*) that runs much faster...

3.3.1.4. Cylinder

Cylinder component:

      represents the internal combustion engine's (ICE) cylinder -- the combustion chamber placed above the piston, or between 2 pistons (the last is for opposed-piston ICE). It accounts for combustion and heat release and also can simulate heat losses. Combustion law is based on the 2-parameter Vibe equation.

3.3.1.5. Crankcase

Crankcase component:

      represents variable volume of the chamber placed below the piston of ICE. It differs from Vessel component only in this respect. To evaluate its current capacity, it accounts for the current position of the piston of the specified Cylinder.

3.3.2. Connectors

Only 2 types of Connector modules are implemented in this version of the package.
      These 2 types are: Restriction that represents some connection between two 1D-gas-dynamical modules-components and Splitter (triple junction) that stands for connection point of three gas-dynamical components.
      Name "Restriction" reflects the fact that such a connection in general represents some flow restriction (for mass flow rate and also means the presence of hydraulic losses) and "Splitter" is named so because the flow on each triple junction is generally being split into (or maybe, merged from) 2 flows.

3.3.2.1. Restriction

Connector Restriction itself can be represented by 3 different sub-types of connectors. If the two components interlinked by a Restriction are both Ducts, the assembly generates a Diaphragm sub-type of Restriction. In case when only one of the adjacent components is Duct, a Valve sub-type of Restriction is generated (often used for real valves of a piping, including cylinder ports). Finally, if both such components are not Ducts, the sub-type of Restriction auto-generated for such case will be Window.

3.3.2.2. Splitter

There are 4 types of triple junctions imaginable, but in this version the package supports only 2 sub-types of Splitter connector. Namely, a Triple and a Chink sub-types of a Splitter. Triple represents a junction of three Ducts and Chink is for the case when there is one non-Duct component linked with two Ducts.

3.4. Program Interface

      The most valuable information in this paragraph is the graphical representation of data flow and invocation of different program components of the package. As the latter gets mature, the number of programs and links between its cpmponents increases. Here is the schematic view of basic interactions.

Diagram

Fig. 18. Scheme of program components and data flow.

      This is the real interface worth to be learned. Graphical user interface -- that goes below -- is pretty easy to learn and use.

      Menu Options contains commands that call dialog boxes that allow editing different settings. Currently there are only 2 groups of settings available under Options: Solver and Environment. Environment options (see Fig. 19) affect the assembly field: its background color and color of links drawn between modules, width of scroll bars and steps used in scrolling and the limiting rectangle re-sizing oprrations and finally the language of messages output by the GUI.

Environment options

Fig. 19. Dialog box for environment options.

      Solver options can be set up by the user, bearing in mind that solver is a standalone program and that (1) it can be run with different levels of priority and (2) it can get some command-line arguments.
      Priorities affect elapsed simulation times. On Windows 98, for example, the difference between 'high' and 'normal' priority levels measured can be [roughly] twofold. Level 'default' doesn't tell anything about the priority when the solver is run via CreateProcess().
      Command-line arguments control execution mode of the solver itself. Running solver from the command line w/o any arguments makes it only print out its usage with a short synopsis of arguments allowed. The last (fourth) command-line option is shown on Fig. 20 as disabled simply because this is not implemented yet. For now the solver cannot be 'managed' at all - it just runs through the given computational job, but this must be changed in the future: it is planned that the solver will support more interaction with the calling program, in particular, GUI will be able to catch its output channels and display them in 'real-time', the solver will be able to pause/resume, etc...

Solver options

Fig. 20. Dialog box for editing solver options.

3.5. Examples

      Let us go through the simulation technology by following examples. More activity with GUI will be shown here some day, including pre- and post-processing and usage Tools -- thermodynamic properties editor/pre-processor and Data - interface to "database" of data files. Detailed page on examples is here. Or you can go to each example using links below:

3.6. Directory Tree and Files

      Horsepower Lab 1D package is a set of utilities -- console programs which are relatively independent from the computing platform, and the GUI-based programs built directly with Win32 API (Application Program Interface) calls. C programming language is used for all program components. So, for this time, development can be done using very general tools for building Win32 API programs.
      Re-arranging the package for more cross-platform, user-friendly and distributed features is being considered now. These requirements are planned to be met in version 2.0.

3.6.1. Files and Directories under package's directory

The following table explains the purpose of each sub-directory found under package's (root) directory, e. g. "c:\hpl1d.098":

 bin\  binaries, program components: executable files and DLLs
 class\  files of Java byte-codes (*.class files for Screen and Track utilities)
 data\  data files with thermodynamics and characteristics files
 doc\  documentation: HTML and image files
 prj\  projects directory
 tmp\  directory for temporary files
 utils\  useful utilities

      Below are command (or batch) files placed in the package's root directory. These batch files are for running almost any program component and can also serve as examples of their usage.

 hpl1dw.bat  runs package's GUI
 hpl1ds.bat  runs solver for specified project
 thermo.bat  runs Thermo tool (thermo.exe + thermo.dll)
 data.bat  runs Data tool (data.exe + data.dll)
 porting.bat  runs Porting tool (porting.exe + porting.dll)
 massive.bat  runs Massive tool (massive.exe + massive.dll)
 optimum.bat  runs Optimum tool (optimum.exe + optimum.dll)
 screen.bat  starts Screen utility written in Java (Java RTE required!)
 track.bat  starts Track utility written in Java (Java RTE required!)
 hpl1dstub.bat  runs hpl1dstub.exe -- a solver replacement (for testing)

      And here are few text files:

 license.txt  text of the license agreement
 readme.txt  Windows (®) version of README file
 changes.txt  text file with changes logged
 todo.txt  file with planned changes
 bugs.txt  list of known bugs

3.6.2. Program components found in bin\

Under bin\ sub-directory the following binary files are placed (shown with path names relative to package's root):

 bin\hpl1dw.exe  graphical user interface (GUI)
 bin\hpl1ds.exe  solver executable (console program)
 bin\thermo.dll  dynamic link library (DLL) for tool Thermo
 bin\thermo.exe  console interface to Thermo DLL (simply a launcher)
 bin\data.dll  dynamic link library: tool Data
 bin\data.exe  console program: launcher of Data tool's DLL
 bin\porting.exe  console program: back-end of tool Porting
 bin\porting.dll  GUI to porting.exe
 bin\massive.exe  console program: back-end of tool Massive
 bin\massive.dll  GUI to massive.exe
 bin\optimum.exe  console program: back-end of tool Optimum
 bin\optimum.dll  GUI to optimum.exe
 bin\hpl1dstub.exe  can be used in place of solver to setup/test/debug massive/optimizing simulations

3.7. Tools Reference

      Menu item Tool is used to invoke tools or plug-ins, i.e. more or less independent instruments which can accompany the package to help do its job. These instruments are made typically in the form of dynamic link library (DLL) and (possibly) the console-mode executable (example pair is thermo.dll and thermo.exe) and placed into bin\ sub-directory of the package.
      It is assumed that in the future there will be the clean way to write additional "plug-ins" independently; these plug-ins will be be easily picked up by the GUI...
      Currently there are only 3 such tools: Thermo, Data and Porting.
      Click here for detailed page on Tools.

3.7.1. Thermo tool

Tool Thermo is used to edit thermodynamic properties of the working fluid. It is assumed now that the gas mixture consists of up to 2 thermally ideal "gases" which may not be calorically perfect. Both "gases" can be in turn composed by 6 fixed species: O2, N2, CO2, H2O, CO2 and H2. The second "gas" can be a mixture of the products of combustion of 1st gas and a given fuel.

3.7.2. Data tool

Tool Data can be used to extract some specific data file needed to prescribe certain characteristic of some module in assembly. These data files are stored under data\ sub-directory of the package using very simple rules so the user can add its own entries in that file system hierarchy.
      There are several predefined data file groups:
      diaphragm-simple describes stagnation pressure losses for compressible gas flow on a simple diaphragm;
      chink-simple is for unsteady response tables that describe reflections of waves from the simplest possible duct rupture (side hole, or chink);
      and so on...

3.7.3. Porting tool

Tool Porting is used to calculate area curve of a 2-stroke engine port (or row of N identical ports) against crank angle and also the value of area-angle (in [mm2 x deg.]) For this version, only circular or rectangular (with rounded corners) port shapes are supported.
      Two binary files: porting.dll and porting.exe comprise this tool. porting.exe is the console Win32 executable acting as a "back-end" and can be used separately as standalone program. porting.dll is a Windows 32-bit native GUI for it.

3.7.4. Massive tool

Tool Massive helps to automate extensive/massive simulations -- namely, when there is a need in simulations for set(s) of predefined values of single or multiple parameters (parametrized simulations).
      Two binary files: massive.dll and massive.exe comprise this tool.
      massive.exe is console Win32 executable serving as back-end. It can be used as a filter to process parametrized "template" data file (i. e. to convert input.txt to input), but most useful it is when used as launcher for package's solver in real massive simulation run. In this mode it runs solver on parametrized data, ensuring full look-over of parameter values and storing results in a single text file.
      massive.dll is a Windows 32-bit native GUI for massive.exe. GUI serves as an easy-to-use editor for the sets of parameters, helps to edit "template" data files and in turn it can run massive.exe in several modes.

3.7.5. Optimum tool

This tool facilitates and controls running multiple simulations for optimization, e. g. when some design parameters are to be chosen for maximum power output, etc.
      Optimum tool consists of 2 binary files as well: optimum.dll and optimum.exe. The latter is console program serving as a back-end. It can either run its GUI -- the optimum.dll -- or it can control optimization process and do some other primitive tasks.
      For this version, optimum.exe uses optimization algorithm based on method of deforming polyhedron (a flavor of gradient method). It engages massive.exe to filter input.txt (with variable names inserted as e. g. $L_ex) to convert it to convenient input data file as it is being done when using Massive tool.
      optimum.dll is the tool's GUI; it helps to edit and validate sets of parameters involved, and also some settings for the optimization method itself and to edit projects' "template" data files (input.txt). It also runs optimum.exe, that, in turn, runs the solver to evaluate "performance" of (now parametrized) assembly.

3.8. Glossary

      Link to the Glossary.
      And here are links to the terms definitions: air fuel ratio, assembly, bottom dead center, charging efficiency, coefficient of discharge, connectors, components, compression ratio, crank angle step, displaced volume, excess air factor, equivalence ratio, equivalent diameter, friction loss coefficient, internal combustion engine, links, local restriction, Mach number, ports, Reynolds number, scavenging, scavenging ratio, speed of sound, stoichiometric, top dead center, total pressure, total pressure loss coefficient, total pressure recovery factor, trapping efficiency.

Previous   Next   Contents