The key enabler of the toolkit is the third generation of a software infrastructure called DOME (Distributed Object-based Modeling Environment). DOME is a Web-based, simulation modeling environment that supports emergent and integrated design processes. Employing DOME, the toolkit can advance toward its main goal by taking advantages of the following capabilities and characteristics of DOME:

• Accessibility through the Internet
• Multiple interfaces for end-users
• Computation-status feedback for end users
• Implementation of new models
• Wrapping of third-party models
• Deployment and permission settings
• Model integrations
• Computation with distributed resources
• Declarative model integrations and parameter mappings
• Solving mechanism
• Collaborative design
• Informed decision making with an optimization tool

Details of these capabilities and characteristics are provided in the following pages.

Accessibility through the Internet

DOME run browser

The run browser is part of the DOME application, which is available for any user to download and install on a local computer. However, DOME has another capability that further increases accessibility of the tool. Namely, DOME can be set up as an applet, a Java application that can be run in a Web browser. Consequently, any user with an Internet access can go to a Web site, such as this one, that has a DOME applet and use DOME without having to install the application on his machine.

Multiple interfaces for end-users

standard user interface

All models in DOME have a standard user interface that eliminates the need for a user to learn how to run a model every time a new model is used.

When an interface is opened, the parameters are automatically loaded with default values, originally set by the model's developer. In case of the models in the Alternative Energy Design Toolkit, the interfaces' parameters are pre-configured with typically practiced values. This way, any user may run the models without knowing all the input values, and can still get reasonable results.

Furthermore, the standard interface has a spreadsheet-like visualization that is familiar to most users. To run a model, a user can change values of the inputs, press the submit button, and see new values of the outputs. Other than the spreadsheet-like visualization, the standard interface also offers two more types of visualizations: graph and design system matrix (DSM). These two visualizations provide end users information of how parameters in a model are related to one another.

customized user interface

Besides a standard interface, a customized interface can also be created and linked to a model. Any model developer can create a customized interface, using Java Swing components, to provide more contents, including related pictures and comments, to the users. Thus, in addition to delivering an appearance that the developer wants, a customized interface can also help make the model easier to understand for the users. The figure on the left shows an example of a customized interface.

With the three standard visualizations and an option to create a customized interface offered in DOME, the models in the Alternative Energy Design Toolkit can be made easier to use and understand.

Computation-status feedback for end-users

computation-status feedback

DOME provides live feedback on status of computations. Live feedback can be particularly useful for a simulation that takes a long time to finish and involves a large number of parameters and models, which is often a case in a design associated with renewable energy technologies. During a computation, users can observe the status of a parameter's value from the color coding surrounding the number.

Green means that the value of the parameter is up-to-date, but may need to be rolled back if any subsequent computations fail. Yellow signifies that the value of the parameter is changed by the user as an input. The color turns into green once the user presses the submit button. Red means that the value of the parameter is incoherent with the inputs and will be updated later in the computation. Lastly, White means that the value is final. With the feedback mechanism, users of the Alternative Energy Design Toolkit can determine which values are reliable in real time, resulting in more transparent and comprehendible design process.

Implementation of new models

built-in programming mechanism

An implementation of a new model can also be done easily with DOME. As mentioned in the previous section, DOME has a built-in mechanism the supports most of mathematical operations, including iterations. When participants of the Alternative Energy Design Toolkit develop a new model, they can conveniently implement and test mathematical relations of the model within DOME, eliminating the need for third-party programming software.

Wrapping of third-party models

DOME wrapping model

DOME has a mechanism that allows developers to easily wrap models originally developed in any third-party softwares. The wrapping makes models utilizable in DOME context and can be done without any programming. For example, to wrap a model originally written as a MATLAB script, the developer only needs to create a new model in DOME, add parameters to the model, and specify references to the associated MATLAB variables.

While wrapping the model, the developer can make use of the dimension checking mechanism of DOME, by assigning a unit to each parameter. Consequently, the model can become more robust, since a dimensional check might not be support in the software where the model is originally created, such as MATLAB or Excel.

MATLAB script

The wrapping process can be done quickly, and after that the model can be deployed and ready to be use in the DOME context like any other models. This ability of DOME is critical for the Alternative Energy Design Toolkit, since the operation of the toolkit involves participations of experts from different fields, who are likely to have developed their models in many, different software. The ability to have all types of models easily wrapped and usable in the DOME context can make collaborations among the experts go smoothly.

Deployment and permission settings

setting of use permissions

Once developed and ready to be used, a model can be made available to users by getting deployed on a DOME server, in a similar fashion to a Web page being uploaded to a Web server. After deployed, the model is online and can be accessed via the Internet by anyone who has a proper permission. Different types of permissions can be set for a model by the developer during the deployment. In particular, the developer can decide to make the model accessible to only specific users or groups, or all guests. (Guest is a login mode that does not require a password. Anyone can login as a guest. However, a guest does not have his own private file space on the server like other regular users and, thus, cannot deploy any models.)

The access permission of the user is determined as he/she logs in and the run browser displays a list of models accordingly. In case of the Alternative Energy Design Toolkit, all models are set to be accessible to all guests.

Model integrations

resources and integration models

Users of the Alternative Energy Design Toolkit can easily create integrations of models in DOME. To start, a user needs to browse through DOME servers to locate resource models for the integration. When a model is located, the user then subscribes to that live resource model. The subscription only creates a reference to the resource model and stores information necessary for the integration. The actual resource model, however, is not copied or moved from the DOME server where it is originally deployed. This way, proprietary of the resource model is still preserved, while the capability of the model can be shared. After all resource models are subscribed, the user then makes links between parameters in the resources using an integration model.

mapping between parameters from two resource models

A link between two parameters, from any of the resource models, can be made in two forms: a direct mapping or a mathematical relation. A direct mapping makes the value of one parameter consistent with that of the other. For example, the user can specify that the value of incident irradiance on a PV array should always be consistent with the available solar irradiance. The mapped parameters are highlighted in the figure on the left.

graph visualization of the integration

On the other hand, a mathematical relation can also be specified so that the value of one parameter is always a function of the other. For instance, instead of creating a direct mapping above, the user can specify that the incident irradiance on a PV array is 85% of the available solar irradiance. The ability to specify a mathematical relation between parameters of integrated models is a unique mechanism of DOME that is rarely provided in any other modeling tools with a similar modular structure, such as Simulink. In addition, once models are integrated, a graph visualization of DOME can provide a visual validation of the connections within the overall integration. This is particularly useful for a large integration.

Computation with distributed resources

In the DOME context, resource models used in an integrated simulation can be distributed, that is, they are not required to be on the same computer or server. Regardless of where the resource models reside, all integrated simulations operate in the same way. In fact, for a large, integrated design simulation, a distribution of resource models on multiple servers may achieve a higher performance than a consolidation of all models on a single server. That is because, during a simulation, models are executed by their host servers, not by the computer from which the end user runs the simulation. Therefore, having many resource models of an integrated simulation consolidated on one server may overload the server and slow down the simulation.

More importantly, the capability to support distributed resource models helps facilitate incremental expansions of an integrated design. In other words, different users can continue contributing to an existing integrated design without having to worry about over-expanding the integrated simulation. This capability that DOME provides is essential for the Alternative Energy Design Toolkit because models contributions from various experts are highly encouraged. Some of the experts will prefer to keep their models on their own servers for a proprietary reason. With the toolkit's distributed capability, proprietary of the resource models are preserved, while the models can still serve as resources for the toolkit.

Declarative model integrations and parameter mappings

causality information of parameters in a mathematical relation

While building an integrated simulation in the DOME context, a user can make a connection between models in a declarative fashion, that is, without the user having to specify a direction of the information flow, or dependency, between the models. In fact, the only dependency that a user ever needs to specify is the causality of parameters within a mathematical relation, when each individual model, including an integration model, is being built. (See the figure on the left). Thereafter, as well as when the models are put together, the user never has to specify any other dependency information. Specifically, the direction of information flow between the models will be automatically determined by DOME during the simulation, based on the causality from the mathematical relations in the models.

For the example in an earlier subsection, the causality within each mathematical relation of all individual models is already defined when the models are developed. When they are put together, no dependency or direction of the information flow between the models need to be specified, and a connection is made declaratively. Such as, when the solar-irradiance-profile model is integrated with the PV-array model, the user only needs to declare that the irradiance parameters of both models are consistent, by mapping them together. The direction of the information flow between the two parameters, and effectively the two models, will be automatically determined when the simulation is executed. In this case, DOME will figure out from the models' causalities that the irradiance parameter of the PV model is an input, while the one of the profile model is an output. Therefore, the information will flow from the irradiance-profile model to the PV model. More examples of declarative model integrations will be given in the next subsection.

The declarative model integration can help prevent complexity of a design process, since the users only need to manage the information flow within each mathematical relation, which is the lowest and the easiest to handle level. The information flows at higher levels, such as between models or integrated systems, are automatically handled by DOME. Since designs associated with renewable energy technologies often require a number of integrations between models and systems, having to pre-configure a lot of information flows at different levels can be highly complicated and troublesome. With DOME as the key enabler, this problem is prevented from the toolkit.

Solving mechanism

DOME solves parametric relations of an integrated simulation using an emergent, or on-the-fly, approach. As discussed earlier, dependency information for all levels of connections, except within mathematical relations, of an integrated simulation is automatically determined by DOME during a simulation. However, such emergent solving of the dependency information is not achieved by any central system coordinator. Instead, DOME relies on the individual models as autonomous, local solvers. When the integrated simulation is executed, the model share causality information with the ones connected to them. The causality information shared among the models is only a portion sufficient to make the models solve their dependencies correctly and efficiently.

The benefits of the emergent solving mechanism are hard to appreciate, unless a detailed example is given. Thus, an example of an integrated simulation is provided here. This integrated simulation consists of models X, Y, and Z. Model X contains the following mathematical relations: c=a+b and e=c×d. Model Y contains g=f/2, j=h+i, k=g, and l=g-j. Lastly, model Z contains o=m+n. In building these models, the developer has to specify the causality of each mathematical relation, as shown in the figures below.

Causality information of model X.

Causality information of model Y.

Causality information of model Z.

The causalities defined on the previous page are all that the user has to specify in terms of dependency information. Based on the causalities of each model, DOME automatically determines the dependency information for the models as shown in the figures below.

Dependency information of models X.

Dependency information of models Y.

Dependency information of models Z.

Now the models are ready to be integrated. Suppose the user declaratively maps k to m, e to n, and a to l. DOME then determines, based on the dependency information above, that the information should flow from k to m, e to n, and l to a. Note that each model is still autonomous and unaware of the dependency information of the other models. Once the simulation starts, the models need to share the necessary dependency information with each other. The figures below show the information shared by the models.

Dependency information shared by models X.

Dependency information shared by models Y.

Dependency information shared by models Z.

combined dependency information

After the dependency information of the models are shared, DOME's emergent solving mechanism combine all the information (see the figure on the left) and notify the models of any necessary external dependency information they need to know. Finally, the models have all necessary information to solve themselves efficiently and correctly, as shown in the figures below.

Dependency information for model X to autonomously solve itself.

Dependency information for model Yto autonomously solve itself.

Dependency information for model Z to autonomously solve itself.

This example of integrated simulation demonstrates one of the most crucial benefit of the emergent solving mechanism. That is, the model Z now knows that its m and n parameters are correlated. Therefore, it should wait for the new values of both m and n before executing the o=m+n relation, instead of doing it twice. This benefit can be extremely useful for the Alternative Energy Design Toolkit as the relation might be a highly complicated computation that takes a long time to finish. It would be inefficient to execute that computation redundantly. Moreover, the emergent solving mechanism of DOME also makes a design process of an integrated system more flexible, since the user does not have to explicitly plan the order in which the mathematical relations should be executed.

Collaborative design

Besides a conventional, independent design, which a user work on individually, DOME also supports a live, collaborative design through a collaborative work space, called playspace. A playspace allows multiple users to simultaneously work together on the same models or integrated simulations of designs. One user would see results of any changes that the other users make on the design in the playspace. The users can also discuss with each other via a built-in chat tool.

Making use of this capability of DOME, the Alternative Energy Design Toolkit can provide the experts from different fields with another means to contribute their knowledge. That is, in addition to providing their models to the toolkit, the experts can use a playspace to input their opinion on a design, discuss problems, and try out different options together on a live design simulation.

Informed decision making with an optimization tool

DOME includes an optimization tool called Queuing Multi-Objective Optimiser (QMOO). QMOO is an evolutionary algorithm, which is ideal for multi-objective optimizations in energy systems because these systems are often non-linear, discontinuous, multimodal, and hard to resolve. QMOO is capable of converging to difficult-to-find optima and exploring the full extent of the problem's optimal regions. Test cases show that QMOO has performs better than earlier optimization methods.

trade-off curve

This optimization tool is highly useful for the Alternative Energy Design Toolkit for many reasons. The first reason is, it helps the users identify optimal design options much faster than using the conventional trail-and-error approach. Secondly, it has features tailored for the nature of energy system optimization problems. Lastly, it is developed for multi-objective problems, which are frequently faced in the designs associated with renewable energy technologies. For example, in a design of PV-diesel hybrid power system, the designer has to deal with, at least, two competing objectives: the system's cost and greenhouse gas emission. If the system relies heavily on PV panels, then the cost could be high, while the emission is low. On the other hand, if the system relies on diesel generators, then the cost could be lower, but the emission will likely be higher. With the design of this system modeled in DOME, the user can use the optimization tool to obtain a number of optimal options, plotted on a trade-off curve. After that, the user has a freedom to choose any of the option that suits the design's situation. With the optimization tool, users of the toolkit can make their design decision in an informed and effective fashion.