Transcription
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)CES*701 PROJECT PROPOSAL1. Virtual Material Laboratory Project. .2Background and Overview.2Original and current status.2Future work.32. CES*701 2009 course: project proposal. .43. References. .72009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 1 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)1. Virtual Material Laboratory ProjectThe Virtual Material Laboratory Project is a software library that, provided with a set of material models, and a set of virtualtests, applies a finite element algorithm to simulate the modelled materials behaviour in time (that is, the materials stress, strain,and deformation history) under the conditions imposed by the different virtual tests settings.Background and OverviewThe motivation for a material behaviour simulator derives from the fact that a single constitutive equation that relates the stressand strain tensors history can be used for a wide variety of materials: elastic, plastic, viscous, viscoelastic, viscoplastic, andelasto-viscoplastic materials [1]. This enables the development of a program family to simulate material behaviour, rather thanindividual programs to simulate the behaviour of each class of materials, which improves the reusability and reliability of thesoftware [2].The constitutive equation for a material model can be potentially complex, since the relationship between stress anddeformation can rely on multiple non-linear equations involving second order tensors. Therefore, developing the actual codethat models each material is a difficult and error prone task if designed manually on a case by case basis. However, a commonconstitutive equation provides the abstraction from which the code for each specific member of the family can be generated, ifadequate model manipulation techniques are applied. It is then only necessary to declare the specific member properties for thecode generation stage, task that can be accomplished with a (simple) domain specific language ([3], p.p 24-25).The Virtual Material Laboratory Project software library implements a compiler, which uses the Maple computer algebrasystem to perform symbolic computation and code generation, to transform a domain specific language description into anabstract material class [4]. The abstract material class thus generated can be compiled into the the software library, andtherefore be available to use with the simulation engine implemented therein.Original and current statusThe original codebase for the Virtual Material Laboratory Project software library was intended as a ‘proof of concept’software, and is in part the reason for which it was developed as a software library: to allow embedding into differentapplications.The codebase compiles into two different executable programs: MatGen, which takes the material model description expressedin a simple domain specific language, and uses Maple algebra system to generate the code for the corresponding material modelclass; and MatCalc, the simulation engine that implements a finite element method technique to simulate the modelled materialsbehaviour in time, subject to virtual tests described in scripts coded in the Ruby programming language1.Each of the executables MatGen and MatCalc from the original codebase provide a graphical user interface. However, theseuser interfaces -particularly that of the simulation engine, MatCalc- are neither user friendly nor flexible enough to enable theuser to tap the full capabilities of the underlying library. Additionally, the scripts for building the original codebase addressedonly MacOS and Linux platforms, and Maple and Ruby dependencies were ‘hardcoded’ into the build scripts, even when theseare based on GNU ‘autoconf’ toolset.Currently, the graphical user interface for MatCalc has been significantly enhanced, providing a flexible and intuitive front-endto the library for setting up simulations, better graphical and text-based feedback tools for examining simulation runs, and fileinput/output capabilities to save/retrieve simulation parameters and data. These improvements enable the user to quicklyexperiment with material model parameters and virtual tests. A command-line interface has also been developed, with the aimof performing ‘batch’ simulations. The code refactoring stages pursued a clear separation of concerns, with the result that bothgraphical and command-line interfaces share the underlying library and auxiliary modules, so that the input/output files fromeither interface are compatible with each other, and the simulation engine is the same for both. The building process for thesoftware product has been largely automated, and has also been extended to Solaris and OpenSolaris platforms. The codebasedocumentation, originally inexistent, is currently in development, targeted at the Doxygen automated documentation generator.1The purpose of using Ruby scripts is to allow for a quick definition of new virtual tests without the need to recompile the software, since the scripts arerun by the Ruby engine (which, therefore, is a dependency for building the Virtual Material Laboratory software library).2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 2 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)Future workHaving reached a minimal ‘usability’ grade, future work on the Virtual Material Laboratory Project software library will pursuethe following objectives to leverage it to ‘industrial’ or ‘production’ grade: Perform further improvements in the building stages, such as enabling the choice of building only the command-lineinterface for the libraries, selecting alternatives to the graphical user interface or underlying matrix and vector operations(see below) and fully automating the dependencies check2. Provide an alternative to the simple graph display currently implemented into MatCalc, by embedding the graphical outputof more sophisticated and efficient available plotting utilities (such as Gnuplot3, PgPlot4, or PlPlot5) into MatCalc’sgraphical user interface. Refactor the codebase to enable the choice of using the BLAS libraries6 in lieu of the currently implemented classes formatrix/vector operations Refactor the codebase to improve the memory usage/management during the simulation stages Review the codebase for spotting opportunities of parallelization of the code, either for symmetric multiprocessorarchitectures and/or clusters, using OpenMP7 or MPI8 constructs respectively. Define a set of regression tests, targeted solely at the command-line interface recently provided, given that the separation ofconcerns recently applied to modularize the codebase ensures that the computational core is the same regardless of theinterface selected by the user.Future enhancements to the software library: Development of a model fitting algorithm that would take data from a physical material test, and from the simulation resultsfor the corresponding material model and virtual test, and return the material model parameters fitted accordingly to theexperimental data.Future research: Use of automatic differentiation techniques to substitute the symbolic computation of the required derivatives for theabstract material classes formulations (and the automated code generation that follows) and comparison of the numericaland symbolic/generative approaches2The Maple algebra system, on which the MatGen executable depends, still requires the user to modify the configuration step manually prior to building.MatCalc executable build is fully ro.caltech.edu/ ex.htm2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 3 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)2. CES*701 2009 course: project proposalOf the aforementioned improvements, enhancements, and research objectives proposed as future work for the Virtual MaterialLaboratory Project software library, the current priority -and therefore the proposal for CES*701 2009 course project- is that ofthe pretended enhancements :Development of a model fitting algorithm that would take data from a physical material test (a real worldmaterial test) and data from a simulation for the corresponding material model and virtual test, and return thematerial model parameters fitted as per the real world experimental data.An example of material model implemented by the current MatCalc version is given by the following expression, where σdenotes the material stress, denotes the material strain, and λ and η are the material model parameters. ̇ 2 ̇Eq. 1: Example materialmodelThe material model parameters, as well as the virtual test parameters, can be specified by the user in the corresponding fields ofthe graphical user front end to the simulator, a screenshot of which is displayed in Fig. 1:Fig. 1: MatCalc’s GUI screenshot, showing: (left pane, upper) the selected virtual test (‘Experiment’), material model (‘Yield Function’), testspecimen dimensions, algorithm type and time step/span; (left pane, lower) the virtual test and material model parameters for the currentsimulation; (right pane, upper) the resulting simulation data table; (right pane, lower) the resulting graphic σ ( ).2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 4 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)The desired model fitting module would seek to adjust the material model parameters (λ and η for the example given by Eq. 1)by comparing the simulation results produced with ‘approximate’ values (initial guesses) for those parameters, with the dataproduced by a real world material test. For that purpose, an appropriate ‘cost’ function of the material model parameters has tobe provided, so that minimizing this objective function returns an ‘optimal’ set of values for the parameters. A naïve objectivefunction can be the traditional ‘least squares’ fit, which for the material model example given by Eq. 1 would be:min f p p n jvirtualj2 realj , p , 1Eq. 2: ‘Naïve’ objective function for the material model of Eq. 1To avoid that the optimization method adjusts the parameters λ and η taking into account particularities of either the simulationrun or real material test data (i.e. artifacts of the simulation and/or real world experiment runs, but not of the underlyingphysical model/reality) the objective function can be extended to include several pairs of simulations/tests:min f p p m runsndata i1 jvirtualij2 real ,ji p , 1Eq. 3: Objective function for the material model of Eq. 1Given the current state of the Virtual Material Laboratory Project software library, the model fitting algorithm to be developedcannot access the simulation internal workings, but only the simulation results that are provided in a text file like the onevisualized in the text editor screenshot in Fig. 2:Fig. 2: MatCalc simulation parameters and data file.2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 5 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)This ‘black box’ situation impedes the use of any method that requires the use of e.g. derivatives of the objective/cost functionto be minimized, so a workaround is to use a pattern search method to fit the experimental data to the simulation results.One popular pattern search method is the Hooke and Jeeves algorithm (1975). A detailed description of the method, alongsidean application example, can be found in [5], pp. 180-185. As described therein, given an objective function the pattern searchalgorithm proposed by Hooke and Jeeves:“.establishes a search direction by setting a series of position vectors br, called base points, which tend tofollow a principal axis (of the objective function). Each move involves an extrapolation of any success achievedby moving from the previous base point to the current one, followed by an exploration of the surface around theextrapolated point to provide corrections for local conditions. The algorithm thus employs a double strategy andthe rth iteration comprises:(i) a pattern move from base point br-1 to a new trial centre cr(ii) a local exploration around the trial centre cr as a result of which a new basepoint br is establishedThese position vectors may be defined asbr [(b1)r, . , (bn)r]Tcr [(c1)r, . , (cn)r]Tin which(bi)r the value of the ith variable at the rth basepoint(ci)r the value of the ith variable at the rth trial centre.” ([5], pp. 180-181).In the aforementioned description, the vectors br and cr are simply appropriate names for the parameter vector p (λ,η) at therth iteration of the algorithm, that only describe the stage of the strategy within the iteration step. This implies that for eachiteration of the Hooke and Jeeves method, several simulations have to be run in order to evaluate the objective function f givenby Eq. 3, and after each iteration, the updated parameter values in br have to be provided as initial values for the step r 1.The command-line based interface to the simulation engine enables an approach as the one described above, provided theHooke and Jeeves ‘driver’ program is capable of generating suitable input files for each run of MatCalc, updating the materialmodel parameter values as returned by the last iteration of the method. This ‘driver’ program also needs to parse the filesproduced by MatCalc to read the simulation data and feed it into the Hooke and Jeeves module proper.From the above considerations, the model fitting enhancement to the current MatCalc implementation would have toaccomplish the following goals: implement the pattern searching algorithm proposed by Hooke and Jeeves be capable of running MatCalc in ‘batch’ mode, providing it with the necessary input file for the simulation run be capable of parsing the output file generated by MatCalc to read in the simulation data be capable of parsing the real-world test data file to read in the ‘true’ data evaluate the objective function given the real-world data and simulation data run the pattern searching algorithm stepwise be capable of generating a valid MatCalc file with the updated material model parameters to continue the pattern search be capable of publishing the pattern search results when these are achieved.Issues to be addressed as the development is carried out include: the modular decomposition/assignment of the aforementioned tasks the choice of programming language for coding the pattern search algorithm and ‘driver’ modules, as well as that for othereventual auxiliary modules (some of which might be simple shell scripts e.g. for calling the simulation engine withappropriate inputs, collecting the simulation outputs, feeding the latter to the pattern searching algorithm module, andcollecting and displaying the outputs of the model fitting run).2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 6 / 7
CES*701: Foundations of Modern Scientific ProgrammingCES*701 Project Proposal (final version)3. References[1] “Commonality Analysis for a Familyof Material Models”; S. Smith, J. McCutchan, J. Carette; Computing and SoftwareDepartment, McMaster University. May 6, 2009.[2] “Program Families in Scientific Computing”; S. Smith, J. McCutchan, F. Cao; Computing and Software Department,McMaster University.[3] “Model Manipulation as Part of a Better Development Process for Scientific Computing Code”; J. Carette, S. Smith, J.McCutchan, C. Anand, A. Korobkine; SQRL Report 48, McMaster University. December 2007.[4] “A generative approach to a virtual material testing laboratory”; J. McCutchan; M.Sc. Thesis; McMaster University.September 2007.[5] “Civil Engineering Systems Analysis and Design”; A. Smith, E. Hinton, R. Lewis; (c) 1983 John Wiley and Sons Ltd. ISBN0-471-90060-5.2009/11/18Gonzalo Sánchez sancheg@mcmaster.ca 0802077p. 7 / 7
CES*701: Foundations of Modern Scientific Programming CES*701 Project Proposal (final version) This 'black box' situation impedes the use of any method that requires the use of e.g. derivatives of the objective/cost function to be minimized, so a workaround is to use a pattern search method to fit the experimental data to the simulation results. One popular pattern search method is the .
