Engineering with Computers (1999) 15: 198–210 1999 Springer-Verlag London Limited

WBCSim: A Prototype Problem Solving Environment for Wood-BasedComposites Simulations

A. Goel1, C. Phanouriou1, F. A. Kamke2, C. J. Ribbens1, C. A. Shaffer1 andL. T. Watson3

1Department of Computer Science;2Department of Wood Science and Forest Products;3Departments of Computer Science andMathematics, Virginia Polytechnic Institute and State University, Blacksburg, VA, USA

Abstract. This paper describes a computing environmentnamed WBCSim that is intended to increase the productivityof wood scientists conducting research on wood-based com-posite materials. WBCSim integrates Fortran 77-based simul-ation codes with a graphical front end, an optimization tool,and a visualization tool. WBCSim serves as a prototype forthe design, construction and evaluation of larger scale prob-lem solving (computing) environments. Several differentwood-based composite material simulations are supported. Adetailed description of the prototype’s software architectureand a typical scenario of use are presented. The systemconverts output from the simulations to the Virtual RealityModeling Language (VRML) for visualizing simulationresults.

Keywords. Computer model; Problem solvingenvironment; Visualization; Wood-based compositematerials

1. Introduction

Scientists and engineers in many application domainscommonly use modeling and simulation codesdeveloped in-house that have poor documentation anda poor user interface. Typically, only the developersof a code can make effective use of it, and thesecodes are not typically integrated with tools for vis-ualizing the results. Further, the code is often tied toa particular computing environment. This situationreduces the productivity of many research groups.This paper describes a computing environment namedWBCSim that is intended to increase the productivityof wood scientists conducting research on Wood-Based Composite (WBC) materials. WBCSim inte-

Correspondence and offprint requests to: Dr L. T. Watson,Department of Computer Science, Virginia Tech, Blacksburg, VA24061, USA. Email: ltwKcs.vt.edu

grates Fortran 77-based simulation codes with agraphical, Web-based user interface, an optimizationtool and a visualization tool.

The objective of WBCSim is twofold: (1) toincrease the productivity of our WBC research groupby improving their software environment; and (2)to design and evaluate a specific prototype ProblemSolving (computing) Environment (PSE) as a steptowards understanding how integrated PSEs shouldbe created. The philosophy of such computingenvironments, a detailed description of the softwarearchitecture of our prototype, and several differentwood-based composite material simulations are dis-cussed.

A problem solving environment is a system thatprovides a complete, usable and integrated set ofhigh level facilities for solving problems from aprescribed domain [1,2]. PSEs allow users to defineand modify problems, choose solution strategies,interact with and manage appropriate hardware andsoftware resources, visualize and analyze results,and record and coordinate extended problem solvingtasks. In complex problem domains, a PSE mayprovide intelligent and expert assistance in selectingsolution strategies, e.g. algorithms, software compo-nents, hardware resources, data, etc. Perhaps mostsignificantly, users communicate with a PSE in thelanguage of the problem, not in the language of aparticular operating system, programming languageor network protocol. Expert knowledge of the under-lying hardware or software is not required. Experi-ence in dealing with large-scale engineering designand analysis problems has indicated the critical needfor PSEs with four distinguishing characteristics: (1)facilitate the integration of diverse codes; (2) supporthuman collaboration; (3) support the transparent useof distributed resources; and (4) provide advisorysupport to the user.

199Problem Solving Environment for Wood-Based Composites Simulations

WBCSim is a prototype PSE for making legacyprograms, which solve scientific problems in thewood-based composites domain, widely accessible.WBCSim currently provides Internet access to com-mand-line driven simulations developed by theWood-Based Composites Program at Virginia Poly-technic Institute and State University. WBCSimleverages the accessibility of the Web to make thesimulations with legacy code available to scientistsand engineers away from their laboratories. Thesimulation codes used as test cases are written inFortran 77 and have limited user interaction. All thedata communication is done with specially formattedfiles, which makes the codes difficult to use.WBCSim hides all this behind a server, and allowsusers to graphically supply the input data, remotelyexecute the simulation, and view the results in bothtextual and graphical formats.

The remainder of this paper is organized as fol-lows. Section 2 reviews some related work in thefield of PSEs. Section 3 gives a detailed descriptionof the three simulation models supported byWBCSim. Section 4 explains the WBCSim userinterface. The various software architecture layersof WBCSim and the interaction between them isdescribed in Section 5. To help prospectiveWBCSim programmers locate files on the WBCSimserver, Section 6 explains the file structure ofWBCSim. Section 7 describes how WBCSim istypically used. Finally, Section 8 describes the vis-ualization phase of the simulations.

2. Related Work

In the past, problem-specific PSEs have beendeveloped for a wide variety of application domains.Recently, increasing attention has been given tobroader issues, such as (1) developing a model orarchitecture for PSEs, (2) leveraging the Web, (3)supporting distributed, collaborative problem solv-ing, and (4) providing software infrastructure(‘middleware’) to make PSE-building easier.

One problem domain where PSEs are common isthe numerical solution of Partial Differential Equa-tions (PDEs). An early example is ELLPACK [3],a portable Fortran 77 system for solving two- andthree-dimensional elliptic PDEs. Its strengths includea high-level language which allows users to defineproblems and solution strategies in a natural way(with little coding), and a relatively open architecturewhich allows expert users to contribute new problemsolving modules. ELLPACK’s descendents includeInteractive ELLPACK [4], which adds a graphical

user interface and allows greater user interaction,and Parallel ELLPACK (PELLPACK) [5], whichincludes a more sophisticated and portable userinterface, incorporates a wider array of solvers, andcan take advantage of multiprocessing. PELLPACKalso includes an expert or ‘recommender’ componentnamed PYTHIA [6,7]. Another system which pro-vides a high level, problem-oriented environmentfor PDE-solving is SciNapse [8], a code-generationsystem that transforms high-level descriptions ofPDE problems into customized C or Fortran code,in an effort to eliminate the need for programmingby hand. Other PSEs in the PDE problem domaininclude DEQSOL [9], PDEase2D [10], and PDE-SOL [11].

PSEs are being built for a number of other scien-tific domains as well. For example, Johnson et al.[12] describe SCIRun, a PSE that allows users tointeractively compose, execute and control a large-scale computer simulation by visually ‘steering’ adataflow network model. Bramley et al. [13,14] havedeveloped Linear System Analyzer, a component-based PSE, for manipulating and solving large-scalesparse linear systems of equations. Dabdub et al.[15] have built a PSE for modeling air pollutionin urban areas. The WISE environment [16] letsresearchers link models of ecosystems from vari-ous subdisciplines.

An important goal of PSE researchers is to definea generic architecture for PSEs, and to developmiddleware (typically object-oriented) to facilitatethe construction and tailoring of problem-specificPSEs [1]. This emphasis, along with work in Web-based, distributed and collaborative PSEs, charac-terizes much of the current research in PSEs. Forexample, Catlin et al. [17] describe PDELab, amultilayered, object-oriented framework for creatinghigh-level PSEs. PDELab supports PDESpec, a PDEspecification language that allows users to specify aPDE problem in terms of PDE objects and therelationships and interactions between them. ParallelApplication WorkSpace (PAWS) [18] is a CORBA-based, object-oriented server for connecting parallelprograms and objects. Other researchers investigat-ing object-oriented frameworks for PSE-buildinginclude Gannon et al. [14], Balay et al. [19] andLong and Van Straalen [20].

With the rise of the Web, PSEs are now beginningto support distributed problem-solving and collabor-ation. Regli [21] describes Internet-enabled com-puter-aided design systems for engineering appli-cations. Net PELLPACK [22], PELLPACK’s Web-based counterpart, lets users solve PDE problemsvia Java applets. Other Web-based PSEs include

200 A. Goel et al.

NetSolve [23] and NEOS [24]. Current PSE-relatedresearch projects that emphasize distributed collabor-ation include LabSpace [25], the Intelligent Syn-thesis Environment (ISE) [26], Habanero [27],Tango [28], Symphony [29], and Sieve [30].

3. Simulation Models

WBCSim contains three simulation models of inter-est to scientists studying wood-based compositematerials manufacturing. Each of these models isdescribed briefly below.

3.1. Rotary Dryer Simulation (RDS)

The rotary dryer simulation model [31,32] wasdeveloped as a tool to assist in the design of dryingsystems for wood particles, as used in the manufac-ture of particleboard and strandboard products. Therotary dryer is used in about 90% of these processes.It consists of a large, horizontally oriented, rotatingdrum (typically 3–5 m in diameter and 20–30m inlength). The wet wood particles are mixed directlywith hot combustion gases at the inlet. The gas flowprovides the thermal energy for drying, as well asthe medium for pneumatic transport of the particlesthrough the length of the drum. Interior liftingflanges serve to agitate and produce a cascade ofparticles through the hot gases. This process uses aco-current flow.

The RDS model consists of a series of materialand energy balance equations, which are defined foreach cascade of wood particles. A cascade cyclebegins when a particle drops off a lifting flange andfalls to the bottom of the drum. This is followedby travel along the periphery of the drum, when theparticle is caught by a lifting flange. The cascadeends when the particle attains its maximum angleof repose and tumbles off of the lifting flange. Theheat and mass flows between cascade cycles, andthe distance of travel along the length of the drumfor each cycle, are determined by algebraic equa-tions. The user must supply the inlet conditions ofthe hot gases and wet wood particles, as well asthe physical dimensions of the drum and liftingflanges, flow rates and thermal loss factor for thedryer. The RDS model predicts the moisture contentand temperature of the wood particles for eachcascade in the drum, and predicts the gas phasecomposition and temperature at each cascade.

3.2. Radio-Frequency Pressing (RFP)

The radio-frequency pressing model [33] wasdeveloped to simulate the consolidation of woodveneer into a laminated composite, where the energyneeded for cure of the adhesive is supplied by ahigh-frequency electric field. Radio-frequencypressing is commonly used for thick composites andfor laminated composites that are nonplanar. Woodis a dielectric material, where the presence of water(a common constituent of wood) and polar adhesivemolecules assist in the absorption of the electricfield energy. The model may be used to help designalternative pressing schedules.

The RFP model consists of a collection of nonlin-ear PDEs that describe the heat and mass transferwithin the veneer layers. The primary variables aretemperature and moisture content. The moisture con-tent is further divided into three phases: boundwater, liquid water and water vapor. These waterphases must satisfy a criterion of local thermo-dynamic equilibrium as represented by a nonlinearalgebraic equation. The model is one-dimensional,with a fixed resistance to heat and mass flux at theboundary. The results of the model include the time-dependent temperature and moisture content profilesin the veneer layers. A time- and temperature-depen-dent equation also predicts the extent of adhesivecure. The user must supply the initial density, moist-ure content and temperature of the veneer, as wellas veneer thickness and the electric field strength.

3.3. Composite Material Analysis (CMA)

The composite material analysis model wasdeveloped to assess the strength properties of lami-nated fiber reinforced materials, such as plywood.The model can perform two tasks. First, the normaland shear stresses together with the strains andcurvatures induced by a user-defined deformed shapein the material can be calculated. Second, it cancalculate the stresses and strains caused by thecombination of different loading conditions such astension, moment, torque or shear. The calculationsare based on the Composite Lamination MatrixTheory (CLMT) and the Hoffmann failure criteria.The model predicts the tensile strength, bendingstrength and shear strength of the compositematerial. The strength calculations are performediteratively. The load level is increased by a specificincrement until all the layers in the composite fail.The load at the point of failure of each lamina, andthe induced stresses and strains in the laminate,are recorded.

201Problem Solving Environment for Wood-Based Composites Simulations

This simulation was designed to allow easy speci-fication of the type of material, thickness and orien-tation of the fibers at each layer of the composite.The mechanical and failure properties of differentmaterials are predefined. The detailed calculationsat each step of the iteration process are stored astext files during the solution phase. The resultingstresses and the failure load of each layer are dis-played in a three-dimensional model of the lami-nated composite.

4. WBCSim User Interface

The WBCSim user interface is composed of Javaapplets. Figure 1 shows the applet that takes inputfor the RDS simulation. The interface consists of aset of text boxes where the user can enter valuesfor various input parameters. The ‘Store Problem’button is used to store the current set of inputvalues, which can be retrieved later using the‘Retrieve Problem’ button. Some simulation para-meters are not accessible by the user, but maybe viewed by clicking on ‘Simulation Constants’.Clicking on ‘Run Simulation’ executes the Fortrancode with the input values supplied by the userthrough the applet, and produces output data in textand graphical forms. For example, Fig. 2 shows anoutput graph for the temperature and moisture con-tent at various distances from the dryer inlet.

The input screen for the RFP simulation is similarto the RDS input screen, as shown in Fig. 3. Theuser can enter values for the parameters throughtext boxes, and the results are produced in both text

Fig. 1. Input screen for RDS simulation.

Fig. 2. Output graph for RDS simulation.

Fig. 3. Input screen for RFP simulation.

and graphical forms. For example, Fig. 4 shows anoutput temperature graph as a function of positionthrough the thickness of the laminated compositeand time during processing. The graphic is a fixed-frame three-dimensional plot generated by Mathema-tica.

Figure 5 shows the input screen for the CMAsimulation. Each row of input data represents a layerof the wood composite. The user can add layers tothe composite by clicking on the leftmost checkboxfor that layer. Currently, a composite can have atmost ten layers. For each layer, the user can selectfrom a menu of materials, including several woodspecies and synthetic materials. The material proper-ties are predefined. Thickness and fiber orientationmay be specified for each layer. The user can enter

202 A. Goel et al.

Fig. 4. Output graph for RFP simulation.

Fig. 5. Input screen for CMA simulation.

203Problem Solving Environment for Wood-Based Composites Simulations

values for various forces acting on the compositeby referring to the image displayed within the applet.Clicking on ‘Run Simulation’ executes the Fortrancode. An example of the output produced is shownin Fig. 6.

5. Software Architecture

The software architecture for WBCSim uses a three-tier model. The tiers correspond to (1) the legacysimulations and various visualization and optimiz-ation tools, perhaps running on remote computers,(2) the user interface, and (3) the middleware thatcoordinates requests from the user to the legacysimulations and tools, and the resulting output.These three tiers are referred to as the developerlayer, the client layer, and the server layer, respect-ively, as shown in Fig. 7.

WBCSim supports legacy programs written in anyprogramming language. The only restriction is thatthe program must take input parameters from thecommand-line, one or more input files, or the stan-dard input stream. In particular, WBCSim supportsthe three Fortran 77 simulation codes described inSection 3.

Fig. 6. Example output for the CMA simulation.

5.1. Developer Layer

The developer layer consists primarily of the legacyprograms on which WBCSim is based. The serverlayer expects a program in the developer layer tocommunicate its data (input and output) in a certainformat. Thus, legacy programs are ‘wrapped’ withcustom scripts. The scripts are written in Perl, andeach legacy program must have its own wrapperscript. The script receives input parameters from theserver, and converts those parameters as appropriatefor that legacy program. The legacy program isexecuted with these parameters fed to its standardinput stream. The program’s input may direct it toload appropriate input files. When the legacy pro-gram terminates, the wrapper script packages theprogram’s output to create an HTML page, andpasses the URL of this page to the server.

The developer layer also includes tools to helpdevelopers get more from their simulations. InWBCSim this concept is implemented by integratingthe legacy programs with an optimization tool andvarious visualization tools.

The optimization tool provided with WBCSim isthe Design Optimization Tool (DOT) [34]. DOTallows the user to provide ranges, as opposed tofixed values, for the input parameters, and get asolution that either maximizes or minimizes a given

204 A. Goel et al.

Fig. 7. WBCSim architecture overview.

output value. DOT is a sophisticated engineeringoptimization subroutine incorporated into WBCSim.

WBCSim examples use two visualization tools:Mathematica [35] and VRML [36]. Mathematica isused to generate static three-dimensional graphs ofthe simulation output. The output is also translatedto VRML. With a VRML viewer, the resultinggraphs can be viewed from various directions in thethree-dimensional viewspace. In principle, devel-opers can add custom filters to convert a program’soutput to a useful form for any viewer of theirchoice.

The simulations generate text output files contain-ing raw data. The script that wraps the RFP simul-ation executes Mathematica to generate GIF files,and the VRML translator to generate VRML files.The HTML page generated for the results of thesimulation includes links to these files.

5.2. Client Layer

The client layer is responsible for the user interface.It also handles communication with the server layer.This is the only layer that is visible to end-users,and typically will be the only layer running on theuser’s local machine.

The client layer consists of the Java appletsdescribed in the previous section. After the userenters all the necessary parameters to controlexecution of the simulation, the client communicatesthese parameters along with a request to execute

the corresponding program to the server layer. Theserver layer returns the URL for the HTML pagegenerated from the simulation’s output. The clientlayer directs this page to the user’s HTML browser.

The client layer also contains viewers for thevarious visualization tools found in the developerlayer. WBCSim requires a VRML 2.0 viewer forthe RFP model, a VRML 1.0 viewer for the CMAmodel, and a 3D visualization Java applet. The useris responsible for installing a VRML viewer on thelocal machine, but the 3D visualization applet isautomatically downloaded from the HTTP server.

5.3. Server Layer

The server layer is the core of WBCSim as asystem distinct from its legacy code simulationsand associated data viewers. The server layer isresponsible for managing execution of the simula-tions and for communicating with the user interfacecontained in the client layer. The main part of theserver layer is the Javamatic server [37]. The Javam-atic server is written in the Java programming langu-age. The Javamatic server can direct execution ofmultiple simulations and accept multiple requestsfrom clients concurrently. The results from the simu-lations are communicated to the clients using anHTTP server.

For security reasons, Java applets that have beendownloaded from a network are not allowed to read,write or execute files on the client’s (local) file

205Problem Solving Environment for Wood-Based Composites Simulations

system. Since WBCSim takes input data from usersvia Java applets, this means that such applets mustforward requests to execute the legacy applicationthrough the WBCSim server for processing. Theserver processes these requests and returns theresults of the transaction to the client.

WBCSim uses the JavaSocketclass to communi-cate between the client and the server. Each time auser issues a command through a Java applet (e.g.he/she clicks on the ‘Run Simulation’ button), anew client request is sent to the Javamatic server.The Javamatic server then goes through the follow-ing steps:

1. The main thread of the server creates a newthread to service the request and then continuesto listen for new requests.

2. This new thread then receives the request fromthe client.

3. If the request is to execute a simulation, theserver then validates the identifier in the requestusing a dictionary file. The dictionary file con-tains a list of known application identifiers alongwith the path for the executable file for each. Ifthe validation fails, the server responds with anerror message and closes the connection.

4. If the validation succeeds, the server thenreceives the arguments for the simulation andreturns a unique URL. This URL points to theHTML file that will contain the results afterthe execution.

5. The server creates a new process and takes con-trol of the input, output and error streams. How-ever, only the error stream is used to providefeedback to the client. The Java Virtual Machinebuffers the output stream and the output file(s)are available only after the process terminates.They are not used by WBCSim for real-timefeedback.

6. The server then executes the application in thenew process. While the process is executing, thecurrent thread sends to the client any informationcoming from the error stream.

7. The client can request termination of theexecution of the simulation, or query the statusof the server.

8. When the simulation terminates, the server closesits socket to the client and stops the two threads.

9. The client then contacts the HTTP server (whichruns on the same machine as the Javamaticserver), and gets the content of the HTML pagegenerated for the simulation’s output.

6. Directory Structure of WBCSim

WBCSim simulations can be accessed fromhttp://wbc.forprod.vt.edu/pse/. All source and datafiles required for running WBC simulations areplaced in the WBCSim home directory. The direc-tory structure of WBCSim is shown in Fig. 8.

A brief description of the contents of each direc-tory in WBCSim is as follows:

1. admin/ : contains files required for maintainingthe server, i.e. starting the server, setting environ-ment variables prior to starting the server, main-taining a log of client transactions, and theWBCSim dictionary of recognized commands.

2. classes/ : contains the Java bytecode forWBCSim.

3. data/archive/ : contains a log of old simul-ation results that a user may have stored. Thelog files are stored under a separate subdirectoryfor each user.

4. data/input/ : contains the simulation inputfiles generated by a user while performing asimulation. These files are temporary and maybe deleted.

5. data/output/ : contains the simulation outputfiles generated by a user while performing asimulation. All the results have unique namesand are stored here temporarily until they arepermanently archived. These files may be deleted.

6. images/ : contains images that are displayedon the WBCSim Web pages. Images generatedby simulations are not stored here.

7. scripts/ : contains Perl scripts for WBCSim.8. src/fortran/ : contains Fortran code that

runs the simulations.9. src/java/ : contains Java source code for

WBCSim.

Fig. 8. Directory structure of WBCSim.

206 A. Goel et al.

7. Simulation Scenario

WBCSim incorporates the legacy Fortran 77 pro-grams that implement its models without any modi-fications to the code. This has the advantage that ifthe programmer decides to make changes in thelegacy program, such as bug fixes, recompilationwith new libraries or newer compilers, orimplementing a different algorithm, the new programcan be installed in WBCSim without additionalwork. Figure 9 shows how this is possible.

Consider the RFP simulation. A Perl script (RFPSim Wrapper) acts as a proxy between the Javamaticserver and the simulation. This script is responsiblefor converting data from the Javamatic server to aformat the RFP simulation can recognize.

In a typical scenario, the server will execute theRFP Sim Wrapper and give it all the input para-meters from the command line plus an additionalargument. The input parameters come directly fromthe client, and they are a sequence of strings derivedfrom the user’s selection. The Javamatic server treatsall parameters as strings, regardless of whether theyare Boolean, numeric or alphanumeric. Theadditional argument is a filename, which is access-ible from the HTTP server. The RFP Sim Wrapperdoes not return the results to the Javamatic server,but outputs them in HTML format to that file. TheJavamatic server then returns to the client the URLpointing to that file.

When executed, the RFP Sim Wrapper packagesall the input parameters into a file and executes theRFP simulation. The parameters are recognized byposition, thus all parameters must be present andhave a value, even if they are not visible on theinterface or the user did not provide a value. Theclient has a list of default values for all the para-meters that are not visible on the interface, and soit fills the blanks before sending the parameters.

The RFP simulation has its own text-based user

Fig. 9. Legacy Fortran 77 simulation code wrappers.

interface and requires input from the standard inputstream (e.g. keyboard). The RFP Sim Wrapper takescontrol of the standard input stream of the RFPsimulation and generates the appropriate keystrokesto read the input file and generate the results. Itdoes this by generating a new file with all theappropriate commands, and redirecting that file atthe command-line when it executes the simulation.This is a temporary file and is deleted when thesimulation completes execution.

While the simulation executes, RFP Sim Wrappertakes control of the standard output stream of thesimulation and listens for specific string patterns.These string patterns indicate major milestones inthe execution of the simulation (i.e. successful com-pletion of a simulation step or the computationof an intermediate value). RFP Sim Wrapper thengenerates a message and outputs it to the standarderror stream. The Javamatic server captures thatmessage and propagates it to the client. Eventually,the message gets to the user. The standard errorstream is used, instead of the standard output stream,because Java buffers the standard output stream andmakes it available only after the process terminates.In contrast, the contents of the standard error streamare sent continuously to the parent of this process.Arbitrary network delays can cause a group of mess-ages to be delivered simultaneously, even thoughthey were generated at different times. The clientalways displays the latest message and discards anyold messages.

When the simulation terminates, the wrapper takesthe results and creates a file, in HTML format, withthe filename given by the server. This file containsa list of links that point to the results in variousformats. The RFP Sim Wrapper then runs Mathema-tica to read the results, which are in textual format,and generates a 3D Plot, which is a Mathematicainternal data structure. RFP Sim Wrapper then callsthe appropriate Mathematica function to output the3D Plot to a file in encapsulated postscript format.It also calls the VRML translator to generate aVRML wireframe representation of the results. RFPSim Wrapper executes a series of filters to convertthe results to GIF images. RFP Sim Wrapper alsocreates text and HTML-table versions of the results.All these different views are stored in individualfiles on the server. An archive tool manages thefiles from different simulation runs.

A benefit of using the simulation code in a PSEenvironment is that other software tools, such asthe DOT optimizer, can be used to provide morefunctionality to the end-user. The user can providea range instead of a fixed value for any of the input

207Problem Solving Environment for Wood-Based Composites Simulations

parameters, and specify which component in theoutput to maximize or minimize. RFP Opt Wrapper,a Perl script, receives the input parameters from theserver plus the variables to optimize and a filename.The wrapper then packages all the input parametersin a file and executes DOT Wrapper, which is aFortran 90 program. RFP Opt Wrapper gives DOTWrapper the filename that contains the data, plusthe name of the program to call every time theoptimizer asks for an evaluation of the objectivefunction. RFP/DOT Wrapper executes the RFPsimulation once and returns the objective functionvalue. When the optimizer finishes, DOT Wrapperreturns the optimal parameter values and objectivefunction value to RFP Opt Wrapper. RFP Opt Wrap-per then executes the RFP simulation one more timeand packages the results in the same format that RFPSim Wrapper uses. The advantage is that neither thesimulation code nor the optimization code needs tobe changed. To add a new optimizer with a differentoptimization algorithm, the only thing that needs tobe done is to modify the wrapper script DOT Wrap-per. The simulation code and RFP/DOT Wrapperremain the same.

8. Visualization

VRML was chosen as the primary viewing environ-ment for simulation output. Our approach is toconvert output generated by Fortran into a VRMLdescription so that the output of the simulations canbe visualized interactively. A custom-built translatorprovides greater control over the description of 3Dmodels that third-party translators cannot provide.VRML was chosen for the following reasons:

1. VRML is a recognized standard for visualizing3D worlds.

2. VRML viewers are available for a wide varietyof platforms, and most of them are easy to use.

3. VRML syntax is simple, and VRML code canbe easily generated by programs [38].

VRML models were generated for the radio-frequency pressing model and the composite materialanalysis model.

I Radio-frequency pressing model: the output datagenerated by RFP is a matrix of numbers whereeach number represents the value of a dependentvariable with respect to two independent vari-ables. Since this is a two-dimensional datamatrix, it is conveniently modeled as a VRMLElevationGrid , as shown in Fig. 10. The

dependent variable here is ‘Pressure’ (y axis),which is now represented by variations in theheight of the elevation grid, and the independentvariables are ‘Position’ (x axis) and ‘Time’ (zaxis). Each element in the matrix becomes acolored point on the grid, and the color issmoothly varied between the grid points.WBCSim also provides a variant of this model,where elements in the matrix are representedby squares rather than points, and a differentcolor is assigned to each square, resulting in acheckered elevation grid.

To ensure that the top and bottom views ofthe elevation grid are able to indicate the trueheight of the grid points, each grid point iscolored based on its height, with blue rep-resenting the lowest point on the grid and redthe highest. All other grid points are coloredby linearly interpolating between blue and redcolor values.

I Composite material analysis model: in this simul-ation, the output contains information about theforces being applied on various layers of acomposite when one or more of the layers faildue to an applied load. The composites aretested for strength based on their material pro-perty, thickness of layers and orientation of thefibers in each layer. Material properties may beselected from a menu of various wood species.Five testing methods have been implemented:analysis, design, tensile strength, bendingstrength and shear strength. In the analysismethod, the program calculates the deformedshape of a multi-layered composite laminate(e.g. plywood) caused by user-defined loads andmoments. In the design method, the programcalculates the applicable loads and momentswhich cause a user-defined deformation of themulti-layered composite. The other threemethods calculate the magnitude of the load(tensile, bending or shear) which causes themulti-layered composite laminate to fail. In theanalysis and design methods, one or more layersmay or may not fail, whereas in the other threemethods, the simulation continues until all thelayers fail. It is the job of the VRML translatorto decide which layers have failed by lookingat the Fortran-generated output files. Each timea layer fails, a new VRML model is generatedcontaining information about the forces on eachlayer at that instant. Failed layers are displayedin red (gray in the figure), whereas active layersare displayed in black, as shown in Fig. 11.

208 A. Goel et al.

Fig. 10. Pressure graph showing the variation of pressure with increasing distance from the laminate surface and with time (thereceding axis).

Fig. 11. Wireframe model of a composite showing failed layers(gray) and active layers (black), and the orientation of fibers ineach layer. In this figure, the second layer has failed. Thehorizontal protrusions are proportional in length to the magnitudeof forces being applied to the layers at the time of failure. Thedirection of the protrusions is unimportant.

9. Conclusion

By providing a Web-based graphical interface tocommand-line Fortran applications, WBCSim pro-vides the following benefits:

1. It enables a wider class of users to access thesetools away from their workplaces.

2. Since these simulations take input via Javaapplets, scientists and engineers working from avariety of platforms are able to access them.

3. All processing is done on the server-end, sousers of WBCSim need not worry about softwareinstallation issues at the client – anybody witha Java-enabled Web browser and an Internetconnection can perform these simulations.

4. Output from the simulations is visualized graphi-cally as compared to the earlier method of read-ing text files generated by Fortran. This has theadvantage that the user does not need to knowwhat subprograms are being invoked, and whatdata conversions are being done to satisfy arequest. In other words, the user can concentrateon the intellectual aspects of the problem solution[39], leaving data manipulation, management andpresentation to WBCSim.

In short, WBCSim provides an integrated set ofhigh-level facilities for solving problems in thewood-based composites domain. It allows users todefine, record and modify problems, and to visualizeand analyze simulation results, which is the veryessence of a PSE.

The original motivation for creating WBCSimwas the more obvious effects of improved usabilityprovided by the graphical user interface and Web-based access. These effects in themselves would beenough to make WBCSim a success for the researchgroup that depends upon these WBC models. How-ever, there are more significant effects of WBCSimon the group’s productivity, which were not soclearly predictable in advance. These effects arerelated to the synergistic nature of combining themodels, an optimizer tool and a visualization tool.The resulting integrated package immediately led togreater use of the simulation models by theresearchers. Not only did they use the models more,

209Problem Solving Environment for Wood-Based Composites Simulations

but they used them to examine the design space innew ways. This is borne out by the fact that theresearchers started to use parameter settings thatcaused the simulations to fail, i.e. they uncoverednew bugs in the simulation codes. Once these bugswere corrected, the researchers were able to continuemore extensive use of the models.

It is likely that this integration effect will arisein many application domains. In general, anincreased ability to integrate simulation, optimiz-ation, and analysis tools will allow researchers toget more out of their tools as they find new waysto make use of them.

Acknowledgements

This work was supported in part by a Virginia PolytechnicInstitute & State University ASPIRES grant, USDA Grant97-35504-4697, and NASA Grant NAG-2-1180.

References

1. Gallopoulos, E., Houstis, E., Rice, J. R. (1994) Com-puter as thinker/doer: problem-solving environmentsfor computational science. IEEE Computational Sciand Eng, 1, 11–23

2. Houstis, E., Gallopoulos, E., Bramley, R., Rice, J. R.(1997) Problem-solving environments for compu-tational science. IEEE Computational Sci and Eng, 4,18–21

3. Boisvert, R. F., Rice, J. R. (1985) Solving EllipticProblems Using Ellpack, New York, Springer-Verlag

4. Dyksen, W. R., Ribbens, C. J. (1987) InteractiveELLPACK: an interactive problem solving environ-ment for elliptic partial differential equations. ACMTrans Mathematical Softw 13, 113–132

5. Houstis, E. N., Rice, J. R., Weerawarana, S., Catlin,A. C., Papachiou, P., Wang, K. Y., Gaitatzes, M.(1998) PELLPACK: a problem solving environmentfor PDE-based applications on multicomputer plat-forms. ACM Trans Mathematical Softw, 24, 30–73

6. Joshi, A., Weerawarana, S., Ramakrishnan, N.,Houstis, E. N., Rice, J. R. (1996) Neuro-fuzzy supportfor problem-solving environments: a step toward auto-mated solution of PDEs. Special Joint Issue of IEEEComputer and IEEE Computational Sci and Eng, 3(1),44–56

7. Weerawarana, S., Houstis, E. N., Rice, J. R., Joshi,A. (1996) PYTHIA: a knowledge based system toselect scientific algorithms. ACM Trans MathematicalSoftw, 22, 447–468

8. Akers, R., Kant, E., Randall, C. J., Steinberg, S.,Young, R. L. (1997) SciNapse: a problem-solvingenvironment for partial differential equations. IEEEComputational Sci and Eng, 4(3), 32–42

9. Umetani, Y., Tsuji, M., Iwasawa, K., Hirayama, H.(1987) DEQSOL: A Numerical Simulation Languagefor Vector/Parallel Processors. In: Ford B., Chatelin

F. (eds), Problem Solving Environments for ScientificComputing, Amsterdam, Elsevier, 147–162

10. Weggel, C. F. (1997) Versatile 2-D analysis. IEEESpectrum, 34(8), 92–93

11. Schiesser, W. E. (1994) Computational Mathematicsin Engineering and Applied Science: ODEs, DAEs,and PDEs. Boca Raton, FL, CRC Press

12. Parker, S. G., Weinstein, D. M., Johnson, C. R. (1997)The SCIRun computational steering software system.In: Arge E., Bruaset A. M., Langtangen H. P. (eds),Modern Software Tools in Scientific Computing, NewYork, Birkhauser, 1–40

13. Bramley, R., Gannon, D., Stuckey, T., Villacis, J.,Akman, E., Balasubramanian, J., Breg, F., Diwan, S.,Govindaraju, M. (1998) The linear system analyzer.Technical Report TR-511, Computer Science Depart-ment, Indiana University

14. Gannon, D., Bramley, R., Stuckey, T., Villacis, J.,Balasubramanian, J., Akman, E., Breg, F., Diwan, S.,Govindaraju, M. (1998) Component architectures fordistributed scientific problem solving. IEEE Compu-tational Sci and Eng 5(2), 50–63

15. Dabdub, D., Manohar, R. (1997) Performance andportability of an air quality model. Parallel Comput,23(14), 2187–2200

16. Knox, R. G., Kalb, V. L., Levine, E. R; Kendig,D. J. (1997) A problem-solving workbench for inter-active simulation of ecosystems. IEEE ComputationalSci and Eng, 4(3), 52–60

17. Catlin, A. C., Chui, C., Crabill, C., Houstis, E. N.,Markus, S., Rice, J. R., Weerawana, S. (1994) PDE-Lab: an object-oriented framework for building prob-lem solving environments for PDE based applications.In: A. Vermeulen (ed), 2nd Object-Oriented NumericsConference, Rogue Wave Software, Corvallis, OR,79–92

18. Mniszewski, S. M., Beckman, P. H., Fasel, P. K.,Humphrey, W. F. (1998) Efficient coupling of parallelapplications using PAWS. Proc Seventh IEEE IntSymposium on High Performance Distributed Comput-ing (HPDC7), Chicago, IL

19. Balay, S., Gropp, B., Curfman McInnes, L., Smith,B. (1998) A microkernel design for component-basedparallel numerical software systems. Technical ReportANL/MCS-P727–0998, Argonne National Laboratory

20. Long, K., Van Straalen, B. (1998) PDESolve: anobject-oriented PDE analysis environment. Proc SIAMWorkshop on Object Oriented Methods for Inter-oper-able Scientific and Engineering Computing, Philadel-phia, PA

21. Regli, W. C. (1997) Internet-enabled computer-aideddesign. IEEE Internet Computing, 1(1), 39–50

22. Markus, S., Weerawarana, S., Houstis, E. N., Rice,J. R. (1997) Scientific computing via the Web: theNet Pellpack PSE server. IEEE Computational Sci andEng, 4(3), 43–51

23. Casanova, H., Dongarra, J. (1997) NetSolve: a networkserver for solving computational science problems. IntJ Supercomputer Applic and High Performance Com-put, 11, 212–223

24. Czyzyk, J., Owen, J. H., Wright, S. J. (1997) NEOS:optimization on the Internet. Technical Report OTC-97/04, Argonne National Laboratory

25. Disz T. L., Evard R., Henderson, M. W., Nickless,

210 A. Goel et al.

W., Olson, R., Papka, M. E., Stevens, R. (1995)Designing the future of collaborative science:Argonne’s Futures Laboratory. IEEE Parallel & Dis-tributed Technology, 3(2), 14–21

26. Goldin, D. S., Venneri, S. L., Noor, A. K. (1998)Beyond incremental change. IEEE Computer, 31(10),31–39

27. Chabert, A., Grossman, E., Jackson, L., Pietrovicz, S.(1997) NCSA Habanero: synchronous collaborativeframework and environment. Conference SupplementFifth Euro Conf on Computer-Supported CooperativeWork (ECSCW’97), Lancaster, UK, 7–8

28. Beca, L., Cheng, G., Fox, G. C., Jurga, T., Olszewski,K., Podgorny, M., Sokolowski, P., Walczak, K. (1997)Java enabling collaborative education, health care andcomputing. Concurrency, Practice and Experience 9,521–534

29. Shah, A. (1998) Symphony: A Java-based Compo-sition and Manipulation Framework for DistributedLegacy Resources. MS Thesis, Department of Com-puter Science, Virginia Polytechnic Institute and StateUniversity, Blacksburg, VA

30. Isenhour, P. L., Begole, J., Heagy, W. S., and Shaffer,C. A. (1997) Sieve: A Java-based collaborative vis-ualization environment. Late Breaking Hot TopicsProc. IEEE Visualization ’97, Phoenix, AZ, 13–16

31. Kamke, F. A., Wilson, J. B. (1985) Computer simul-ation of a rotary dryer: retention time. Am Instituteof Chemical Engineers J, 32(2), 263–268

32. Kamke, F. A., Wilson, J. B. (1985) Computer simul-ation of a rotary dryer: heat and mass transfer. AmInstitute of Chemical Engineers J, 32(2), 269–275

33. Resnik, J., Kamke, F. A. (1998) Modelling the cureof adhesive-wood bonds using high frequency energy.Final Report, U.S.-Slovene Joint Board on Scientificand Technological Cooperation. Project 95-AES10.University of Ljubljana, Ljubljana, Slovenia

34. Vanderplaats Research & Development, Inc. (1995)DOT Users Manual, Version 4.20 Colorado Springs,CO

35. Wolfram, S. (1996) The Mathematica Book, 3rd ed.,Cambridge, UK, Wolfram Media/Cambridge Univer-sity Press, 148–155

36. Ames, A. L., Nadeau, D. R., Moreland, J. L. (1996)VRML 2.0 Sourcebook, 2nd ed., Chichester, JohnWiley, 241–295

37. Phanouriou, C., Abrams, M. (1997) Transformingcommand-line driven systems to Web applications.Sixth Int World Wide Web Conf, Santa Clara, CA,1–3

38. Marti, J. (1997) Viewing IGES files through VRML.Proc Visualization’97, IEEE Press, Los Alamitos, CA,471–472

39. Ford, B., Iles, R. M. J. (1985) The What and Whyof Problem Solving Environments for Scientific Com-puting. In: Ford B, and Chatelin F. (eds), ProblemSolving Environments for Scientific Computing,Amsterdam, Elsevier, 3–18