Mathematical model building service

The steps for writing the service have been described above. This section will describe how the end user used the services. A web-based interface is provided for the user to enter those parameters described above to be able to build a model. When a user selects the domain, the mathematical model building process is the next action that is expected. Alternatively, if the model is a complex one and is available, then it can be uploaded. This service consists of two subcomponents namely the quantitative (QT) and qualitative (QL) model services. The QT optimisation service provides the interface for the building of mathematical models and then linking the math model to the NSGA-II optimisation code. The concept assumes that the designer does not know how to perform optimisation or how to choose the best optimisation model that suits his or her problem. However, the designer knows what is expected of the design to produce an acceptable product. The QTservice guides the designer through a series of prompts for the model to be built based on the designer’s responses. This grid service mathematical model builder is one contribution to conventional computational grid services which concentrate on improving computational power to speed-up the optimisation process with the assumption that the model has been built somewhere as a resource, waiting to be invoked.

The first step towards building the model is the invocation of the Globus DelegationService portType. This is important because the problem domain that the

designer may choose may not reside on the local grid node in use at the design location. The resources and expertise of the domain may be geographically far apart and the constraints, data and model may also be at different grid nodes. The DelegationService (DS) can be used to fetch resources from any side through the Globus single sign-on proxy capability and reliable file transfer (RFT) protocol. The next step is the prompt for the designer to supply problem domain. The problem domains are the three case studies described earlier as shown in Figure 7.1. An optimisation schema based on the Web Services Description Language (WSDL) is used to describe the data needed for MODO service as shown in Figure 7.4. This is the schema that displays information about the optimisation data (resource) published by a provider. It shows the date and time the resource is published. It also tracks the date and time a user uses an instance of the resource and the network information of the node that the resource is being accessed.

<MODOServiceProvider>

<optimisationInformation> <optimisationData>

< put optimisation data here> </optimisationData>

<optimisationDateAndTime> < date and time of retrieval> </optimisationDateAndTime> <optimisationSourceURL>

<URL where optimisation data is retrieved> </optimisationSourceURL>

</optimisationInformation> </MODOServiceProvider>

Figure 7.4: Optimisation data schema

As the problem domain is specified by the designer, the Globus

NotificationConsumerFactoryService (NCFS) is invoked. NCFS notifies the most likely expert grid nodes to get ready for request from a consumer (requestor). The criteria definition for what to optimise is supplied by the design engineer. The

mathematical model building process is divided into explicit and implicit categories as discussed below.

7.5.2.1 Explicit math model building

Explicit models are mathematical models that are not too complex to build as explained during the design. These are simple mathematical formulations and constraints. The second and third case studies are based on explicit models. For explicit model generation, there are 4 generic fields namely variables, left operators (this can be (, +, -, /, etc) right operators (this can be (, +, -, /etc) and output variable/assignment. Figure 7.5 shows the explicit interface implementation.

Figure 7.5: Explicit model building interface

The steps that were explained in the design will again be briefly described for clarity. A user will enter variable and/or left/right operators and submit it continuously until all input variables are complete for an equation/inequality. The last action to generate an equation in a model is to enter the output variable together with the equality sign (=) and submit. This will create an equation. This process is repeated again for the next equation until all equations/inequalities in the model are exhausted. When the model consisting of the objective functions and constraints are built, the display action displays the complete model for confirmation by the design expert. If the

expert is satisfied with the model, he or she can use the append functionality to link the model to the problemdef.c file of the NSGA-II. The NSGA-II optimisation functionality invokes the NSGA-II Input Parameter Optimisation Service so that the design parameters can be entered for the optimisation to be run. Various components of the model can be supplied by different experts from distributed geographical locations. For example the objective functions can be supplied by a different expert and the constraints by another expert. This is common with MODO applications in which multidisciplinary experts are involved in the model building process. This scenario will be demonstrated in the next chapter during validation of the prototype using the case studies mentioned.

In the design description, there are interfaces for entering the criteria (outputs), parameters (inputs), constraints and constants. These 4 fields described in Figure 7.4 are used to create instances that get the variables, criteria, constants and constraints. The input parameters are obtained using the NSGA-II input parameter optimisation service. The criteria are then linked to the input parameters and finally to the optimisation service.

7.5.2.2 Implicit math model

Complex and difficult mathematical models are tedious to build and are referred to as implicit models. These models usually require variables or equations that are dependent upon other variables and equations. Because of this, the mathematical model building process used to obtain explicit models above cannot be used. Instead the model is loaded from a file onto the NSGA-II model definition file. Figure 7.4 is the implicit mathematical model interface.

The first case study is an implicit model. The model is uploaded by using the upload model functionality and can be displayed on the browser using the display model functionality that is described in the case of explicit model. After this, the model is treated the same way as explicit model by linking it to the problemdef.c file of the NSGA-II. The next service allows parameter entry so that NSGA-II can use the parameters to run the optimisation. These interfaces are customised to suit MODO approach running NSGA-II on grid environment. The importance of building models is that multidisciplinary experts interact and the interactions result into decision

making on the components of the model which represent physical phenomenon of the problem involved (Sobieszczanski-Sobieski and Haftka, 1997).

Figure 7.6: Implicit math model interface