Graph-based algorithms and data-driven documents for formulation and visualization of large MDO systems
- 339 Downloads
A new system is presented that enables the visualization of large multidisciplinary design optimization (MDO) problems and their solution strategy. It was developed within the scope of the European project AGILE. In AGILE, collaborative MDO is performed in large, heterogeneous teams of experts by solving MDO problems using a collection of design and analysis tools. This paper focuses on the visualizations required to support the formulation phase of an MDO project. The Knowledge and graph-based AGILE Design for Multidisciplinary Optimization System (KADMOS), an open-source MDO support system developed by Delft University of Technology, uses graph-based analysis to formulate an MDO problem and its solution strategy, based on the disciplinary analyses available in a repository. The results of KADMOS are stored in the standardized format CMDOWS (Common MDO Workflow Schema), which comprises the entire information on an MDO system. Although, based on Extensible Markup Language, the readability of the CMDOWS file is quite poor also for MDO experts, especially for large MDO systems involving thousands of variables. Providing visualization capabilities to thoroughly inspect the outcome of the different MDO formulation steps becomes a key factor to enable the specification of large MDO systems in a heterogeneous team. Therefore, VISTOMS (VISualization TOol for MDO Systems), a dynamic visualization package, was developed by RWTH Aachen University to enable the visualization and inspection of the different MDO system specification steps, thereby removing one of the main hurdles for using MDO as a development process. The developed visualization capabilities are demonstrated by means of an aerostructural wing design optimization project.
KeywordsMDO Visualization KADMOS CMDOWS VISTOMS
Aircraft Third-Generation MDO for Innovative Collaboration of Heterogeneous Teams of Experts
Multidisciplinary design analysis and optimization
Common parametric aircraft configuration schema
MDAO data graph
Common MDO workflow schema
MDAO process graph
Cascading style sheets
Remote component environment
Repository connectivity graph
Design of experiments
Reconfigurability in MDO problem synthesis
Functional dependency table
Scalable vector graphics
Fundamental problem graph
VISualization TOol for MDO Systems
Hypertext markup language
Extended design structure matrix
Extensible markup language
Knowledge and graph-based AGILE design for multidisciplinary optimization system
Past research indicates that MDO can offer huge benefits in complex product design. Boeing Phantom Works’ scientists [6, 30] estimate that MDO can offer 8–10% gains for innovative aircraft design and even 40–50% gains for designing radically new and undeveloped concepts . Despite the high potential gains, MDO is not as widely used as one would expect. Both technical  and non-technical barriers are hampering its full exploitation, as discussed below in this section [4, 27, 28].
One of the most critical technical barriers for MDO comes from the large (and continuously increasing) size of typical MDO problems. In the words of Pate et al. , the formulation of these problems has become increasingly complex as the number of analysis tools and design variables included in typical studies has grown. In this context, the problem of determining a feasible data flow between tools to produce a specified set of system-level outputs is combinatorially challenging. Especially, when complex and high-fidelity tools need to be included, the cost and time requirements to integrate the MDO system can easily approach the cost and time requirements of creating any of the discipline analyses themselves.
It is our conviction that the cost and time requirements for the integration of tools in a large and complex MDO system could be reduced by enabling the designer to analyze, visualize, and inspect the MDO system down to the smallest detail during the integration effort. Any system integrator is aware of the value of such analysis and visualization, but, in practice, the manual generation and update of this sort of documentation is too cumbersome. For example, if visualizations of the tool repository or MDO solution strategy are created, they are usually a collection of spreadsheets and text documents, which have to be updated manually and are hard to keep consistent. On top of that, such manually created overviews are not (fully) machine-readable and thereby cannot be used for any further automated analysis, integration, or manipulation of the MDO system. Therefore, the analysis, visualization, and inspection of MDO systems should be automated and based on machine-readable files or documents.
This is one of the main goals of the EU project AGILE,3 where the developments described in this paper are taking place. The process for the generation of the necessary visualizations to support the MDO formulation phase is based on the outcome of KADMOS, the Knowledge- and graph-based AGILE Design for Multidisciplinary Optimization System developed at DUT.4 KADMOS takes care of the automatic integration of the various design and analysis tools in the MDO system and supports the formulation of the MDO problem at hand and its solution strategy. KADMOS’ functionalities are briefly explained in Sect. 2.2, while detailed information can be found in another publication . As illustrated in Fig. 1, KADMOS stores the output of the MDO formulation process by means of a standardized XML format, called CMDOWS (Common MDO Workflow Schema), which is discussed in Sect. 2.1. The creation of the visualizations is done by coupling the CMDOWS files to a custom-built visualization package developed at RWTH Aachen University. This system, called VISTOMS (Visualization Tool for MDO Systems), is the main subject of this paper and its functionalities are described in detail in Sect. 2.3. The produced visualizations are presented in Sect. 3, based on a real MDO system for wing optimization, created within the AGILE project.
CMDOWS is an open-source,5 XML-based workflow schema that was developed at DUT to enable the exchange of the formulated MDO system between MDO framework applications, as visualized in Fig. 4. Other publications have already addressed the deployment of a formalized schema as an exchange format for MDO applications [14, 15, 16]. However, for the purpose of the AGILE project, it was necessary to use something that is feasible for collaborative MDO projects and connecting a wider range of MDO applications. Therefore, CMDOWS was created within the project as a new schema, as described in a publication by Van Gent et al. . The different stages of the MDO system in the formulation phase can all be stored in the CMDOWS format. Each stage in Fig. 1 (from left to right) enriches the CMDOWS file to go from a repository of design tools to a full description of the optimization strategy. KADMOS is able to provide the graph-based representation for each stage (see next section) and can store these in a CMDOWS file; however, visualizing the outcome of these stages is not properly handled by KADMOS. In addition, the CMDOWS files, although based on XML, do not offer a practical means to the user for inspecting the generated MDO system formulation. Therefore, the work presented here was focused on the link between the visualization package VISTOMS and CMDOWS. Within that link, the efficient graph-based algorithms of KADMOS were used for data processing purposes.
Creation of the CMDOWS files to be used as input for the approach in Fig. 3
Graph-based data processing of the CMDOWS files to convert the XML representation into the JSON format required for VISTOMS
2.2.1 KADMOS as MDO system formulator
The ability of KADMOS to support the specification of the MDO system is discussed in detail in earlier work . A mapping between the three stages of the formulation phase in Fig. 1 and the associated KADMOS graphs is shown in Fig. 5. Four different graph types are associated with the three formulation phases.
The MDO problem is represented in KADMOS with the fundamental problem graph (FPG), see Fig. 5 (middle). The FPG is a subset of the RCG in terms of nodes and edges. In addition, its nodes are also enriched with attributes required to specify the MDO problem at hand, such as design variables, objective, and constraints.
Finally, the neutral representation of the MDO solution strategy is stored in two separate graph constructs: the MDAO process graph (MPG) and the MDAO data graph (MDG), where the first contains the process execution flow of the various MDO system components, and the second specifies the specific data exchanged between those components. These graphs are created automatically by KADMOS based on the FPG and stored in the same CMDOWS file, thereby using all the elements of the schema.
2.2.2 KADMOS as data processor
The system formulation capabilities of KADMOS cover all stages of the formulation phase given in Fig. 1, and can store the CMDOWS file for each stage, although these capabilities could be taken over by other platforms, as well. Especially, the creation of the tool repository is a relatively easy task that can be performed with other applications. For example, in AGILE, the business process platform KE Chain6  also contains a module to create a tool repository and export it as a CMDOWS file. However, even if other platforms create the CMDOWS file, KADMOS is still required as a data processor to provide the right data format for VISTOMS.
This data processing is required to provide VISTOMS with files that are directly interpretable; hence, no cumbersome analysis of the data is required before visualizing it. In other words, the KADMOS graphs do contain all the information that is required to visualize it, but some of the information is stored implicitly. To improve responsiveness of the visualization package, this information is transferred explicitly to the JSON files read by VISTOMS. An example of this would be the input and output variables of a single tool. This information is stored in the graph, but, to determine this information for a single tool, one has to loop over all the incoming and outgoing connections of the tool. Instead, the input and output variables per tool are stored explicitly in the JSON files, so that VISTOMS does not have to perform the loop when the information is requested. Similarly, if the variables follow a central data schema, then the hierarchy of the variables (which is lost in the graph representation) is reestablished based on the variable names and stored in a nested dictionary in the JSON files.
The KADMOS data processing step provides VISTOMS with easily accessible information about the MDO system to be visualized. The processing, which takes in the order of seconds (depending on the size of the system), prevents a lot of waiting time when using the dynamic visualizations. Downside of the JSON files with directly useable information is that some information is stored multiple times in slightly different ways, thereby increasing the size of the collection of JSON files with respect to the original CMDOWS file. However, this decrease in storage efficiency is well worth the associated performance increase when using the dynamic visualizations.
The combination of KADMOS itself and the visualizations developed in the course of this research provide the MDO integrator with a powerful set of tools to support creation, inspection, debugging, and modification of large and complex MDO problem formulations. The presented visualizations are obtained using the open-source library D3.js . In the following sections, D3.js as well as significant state-of-the-art visualization techniques are currently used in MDO will be introduced. Subsequently, the newly developed visualization techniques embedded in VISTOMS will be presented. Their ultimate goal is to enhance the understanding of complex MDO systems, which is necessary for effective MDO problem formulation, documentation, and knowledge sharing.
2.3.1 D3.js library
2.3.2 State-of-the-art visualization techniques in MDO
In Fig. 6, each of the non-blank off-diagonal elements (x’s and numbers) represents a data dependence between the competences, which are arranged on the diagonal. Both DSM and N2 chart thereby enable the representation of the data exchanged among the various competences by showing the data dependence in a system (see bottom right graph in Fig. 5). However, these visualizations are not effective in formalizing the execution order of the tools and the triggering of the various loops including any required iterations by convergers or optimizers. However, with increasing number and complexity of analysis tools, the choice of competence execution order becomes more important and more complex, as well. Wagner and Palambros developed the so-called functional dependence table (FDT) to account for constraints and objectives in an MDO problem formulation . The drawback of the FDT is that information about inter-dependencies between competences and functions is partially lost, and therefore, a competence execution order cannot be indicated. A combination between DSM and FDT called Reconfigurability in MDO Problem Synthesis (REMS) was introduced by Alexandrov and Lewis enabling indication of couplings between competences as well as constraints and objectives . Nevertheless, the execution order of the competences is not available within the representation of REMS.
The XDSM provides a visualization that captures the full description of an MDO problem, combining the advantages of DSM and FDT. In general, an XDSM can be read as a square adjacency matrix, where the competences are arranged on the diagonal and the columns and lines indicate competence inputs and outputs, respectively. The competences are connected via data pipelines (gray lines) indicating data transfer. Feed-forward connections are shown on the right and feedback connections on the left side of the diagonal. The so-called edges (rhomboids on the off-diagonal) indicate a connection between two competences (also referred to as couplings), i.e., the information that is processed from one competence to the other. The so-called process lines (thin black lines) in combination with the numbers in the diagonal blocks indicate the order of the workflow execution (MDAO process graph, c.f., Fig. 5).
Although the XDSM offers the means for a detailed and comprehensive description of an MDO system, its readability quickly degrades when the number of competences and their coupling increases, at least in its static document-based version.
The HTML-based rendering approach of the presented visualization package enables the use of effective standard representations, such as the XDSM, while offering the dynamic scaling and displaying options necessary to guarantee readability and inspectability also for MDO systems of extremely large size. Examples are discussed in the next section.
2.3.3 Visualization techniques for CMDOWS files
Egde Bundling View;
Note that VISTOMS provides solely a visual representation of an MDO system, in which no actual competences can be executed. Rather, the automated creation of executable workflows from the MDO architecture is a task, which is performed in simulation workflow platforms by parsing a CMDOWS file .
In the following sections, the three above-mentioned visualizations will be described in detail with respect to their capability to enhance the insight into MDO systems. The interested reader can directly access and experience a number of example visualizations via the open-access CMDOWS browser interface.7 On the browser interface, a number of pre-generated CMDOWS files are available for demo purposes. Note that the VISTOMS visualizations can also be created for any MDO system using the open-source KADMOS package.
The latter can, for instance, be helpful, when multiple competences modify the same variable. This so-called collision can potentially cause problems such as inconsistencies in the MDO system and, therefore, needs to be at least recognized by an MDO integrator. Note that the tree layout shown in Fig. 10 is not fully expanded to the last leaf nodes, the node sharedCoupling is collapsed, while it is indicated in the brackets that there are six leaf nodes contained here. This feature gives the user an idea on how many variables are contained in the layout, even when the tree is not fully expanded, and, therefore, keeps the layout clear, which is especially required for large data sets.
Each of the nodes in the tree layout can be further examined via right click. In the example given in Fig. 9, the selected node of interest is variable z2. Several options for examination exist, such as indication of general information about a node (name, type, dimension, or its current value), as can be seen in Fig. 9, overlay frame 2. Another option is to display the occurrence/usage of a node in the MDO system. This means that it can be highlighted, wherein the MDO system a node is processed from one competence to another by highlighting the respective edges (see Fig. 9, overlay frame 3). This option provides valuable information when setting up a problem solution, because the MDO integrator can easily examine how the competences are connected to each other and which of the processed variables are of most interest due to their occurrence in the system. Thus, an overview on whether the competences are connected correctly, or at least as expected, is given. Furthermore, it is possible to download the tree layout as an XML file (including current values of leaf nodes) to, for example, manually adjust the data set or to simply extract the data from the visualization. These dynamic, interactive inspection possibilities are the major advantage of the presented visualization package and make it a convenient debugging tool for MDO systems of arbitrary size and complexity.
The above described techniques, developed in the course of this research, are quite similar for all three of the visualizations (XDSM, Edge Bundling View, and Sankey Diagram). Thereby, recurring visualization elements are established, which facilitates the usability of the functions.
Each of the blue lines indicates a general dependence between two elements. The focus can be set on any element by hovering over it with the cursor (c.f. element D1 in Fig. 11). The red lines indicate input flow to the element and the green lines indicate output flow from the element. Further detailed inspections can be carried out via right click on the connecting lines or on the elements, similar to what has been described for the XDSM in the previous section.
In contrast to the XDSM view, the Edge Bundling view only provides data information, i.e., the interconnections of the competences and the data processed between them, whereas the workflow process information cannot be displayed. On the other hand, it visualizes the connections among the competences more intuitively.
Sankey Diagram The Sankey Diagram was first introduced by Henry Riall Sankey in 1896 for the visualization of energy flows in steam engines [24, 25]. A variation of the conventional layout is the bi-directional Sankey Diagram, which was used in a D3.js-based package by Atkinson in 2015 . While the conventional layout only considers one flow direction, the bi-directional layout is able to account for feed-forward and feedback information flow between the elements at the same time. The Sankey Diagram used in the presented research is based on the developments by Atkinson. An example of the visualization for the Sellar problem RCG is shown in Fig. 12.
Within the scope of the AGILE project, the visualization package presented in Sect. 2.3 has already been intensively used and tested by multiple AGILE project partners for various MDO problems. The developed capabilities have proven to effectively assist the MDO integrator in the problem formulation process . In this section, the results of the visualization enhancements will be presented with regard to a tool repository containing a collection of DUT aircraft design tools.9 This use case concerns the aerostructural optimization of an aircraft wing. The starting point of this case is a tool repository containing over 28,000 variables and over 37,000 data connections based on 29 function nodes. More details on this case study can be found in .
The other input edge (12 inp.) in the top of EMWET is provided by the so-called Coordinator, which represents the outer world and operates as the main control function of the MDO system (see Fig. 13, overlay frame 3). This means that every variable passed from the Coordinator to a competence is not provided by any other competence in the MDO system. For aircraft-specific information, such as the geometry or mass data, this should normally be avoided, because, in that case, the user would have to specify the values manually. In the presented MDO system, however, it can be seen that only tool-specific information, i.e. the tool settings of EMWET, are processed here. For an MDO integrator, this leads to the conclusion that EMWET receives all the required input data by the competences available in the tool repository. If this was not the case, the integrator would have to provide the missing information himself, or include an additional competence that can provide it.
Figure 14 shows the XDSM view of an MDO solution strategy for the DUT wing design. The presented MDO architecture is a DOE with an internal Jacobi converger for the wing design use case. Compared with the XDSM for the RCG from Fig. 13, it can be seen that the amount of competences and data connections is narrowed down significantly for the specific use case. The coloring of the competences indicates their role in the MDO architecture (c.f. Fig. 5). The additional competences DOE and Converger have been integrated automatically by KADMOS. They are characteristic functions of this particular MDO architecture. Furthermore, in addition to the gray data pipelines connecting the competences (MDAO data graph), the process lines are now visible, which indicate the order of the workflow execution (MDAO process graph). These have also been included within the step of defining the MDO solution strategy by KADMOS. To give an example, the process lines going from the Converger to the competences Q3D[FLC]-EMWET-seq, Q3D[VDE]-SMFA-seq, and MTOW indicate that these three competences are executed in parallel, which is a specific characteristic of the Jacobi converger used in this MDO problem solution. As in any standard XDSM, this process information is also provided by means of the sequence number assigned to each diagonal block. In this case, the three aforementioned competences have all the same sequence number 6. The competence Q3D[FLC]-EMWET-seq is a combination of the sequentially running competences Q3D and EMWET, which have been merged into one competence block. Q3D performs an inviscid aerodynamic analysis to evaluate the aerodynamic loads on the wing, which are then used for the wing mass estimation by EMWET.
A right click on a competence gives the user the option to show the previously described hierarchical tree layout (see Fig. 13) of either all input or all output data for the respective competence. In addition, the user can be provided with competence information, including, e.g., its description, its role in the problem definition, or its role in the MDO architecture.
Within the process of re-configuring and adding new MDO problem solutions to an MDO case with KADMOS, the number of different MDO architectures for the same design problem can become quite large. One of the advantages of the presented visualization package is the fact that all of the graphs produced are eventually combined into one single package and can be selected via a drop-down list in the main menu of VISTOMS.
Therefore, within the scope of VISTOMS, the Edge Bundling view is very convenient to provide a general overview on interconnections between competences in an MDO system. It is noticeable that, for the tree view of an edge between two competences, one can see the connections in both directions at the same time (if applicable). Input nodes are marked as red circles, output nodes are marked as green circles, while the direction of the connection is given in the headline of the tree view (see overlay frame in the bottom of Fig. 15).
the standardized MDO workflow storage format CMDOWS
the MDO problem formulation system KADMOS for automated machine-readable graph data
the D3.js-based visualization package VISTOMS
All developments presented in this paper are open source and form a fundamental output of the AGILE project. Future work for the open-source platforms will focus on extending their capabilities to handle a larger variety of MDO systems, as they will be put to the test in future AGILE design campaigns and other MDO projects.
Aircraft Third-Generation MDO for Innovative Collaboration of Heterogeneous Teams of Experts, see: http://www.agile-project.eu.
Available at: http://cmdows-repo.agile-project.eu.
Available at: http://cmdows.agile-project.eu.
VISTOMS for Sellar problem available at: https://www.agile-project.eu/files/VISTOMS_SellarProblem.
VISTOMS for DUT wing design available at: https://www.agile-project.eu/files/VISTOMS_TUDWingDesign.
The research presented in this paper has been performed within the framework of the AGILE project (Aircraft Third-Generation MDO for Innovative Collaboration of Heterogeneous Teams of Experts) and has received funding from the European Union Horizon 2020 Programme (H2020-MG-2014-2015) under grant agreement n\(^\circ\) 636202. The authors are grateful to the partners of the AGILE consortium for their contribution and feedback.
- 2.Alexandrov, N.M., Lewis, R.M.: Reconfigurability in mdo problem synthesis, part 1. In: Proceedings of the 10th AIAA/ISSMO multidisciplinary analysis and optimization conference, AIAA paper, vol. 4307 (2004)Google Scholar
- 3.Atkinson, N.: bihisankey.js package—bidirectional hierarchical sankey diagram. https://github.com/Neilos/bihisankey (2015)
- 4.Belie, R.: Non-technical barriers to multidisciplinary optimisation in the aerospace industry. In: 9th AIAA/ISSMO Symposium of Multidisciplinary Analysis and Optimisation, pp 4–6 (2002)Google Scholar
- 5.Bostock, M.: D3.js website. (2015). https://d3js.org/
- 6.Bowcutt, K.: A perspective on the future of aerospace vehicle design. In: 12th AIAA International Space Planes and Hypersonic Systems and Technologies, Norfolk, VA, AIAA Paper, 2003-6957 (2003)Google Scholar
- 7.Ciampa, P.D., Nagel, B.: Towards the 3rd generation MDO collaboration environment. In: 30th Congress of the International Council of the Aeronautical Sciences (2016)Google Scholar
- 8.Flager, F., Haymaker, J.: A comparison of multidisciplinary design, analysis and optimization processes in the building construction and aerospace industries. In: 24th international conference on information technology in construction, pp 625–630 (2007)Google Scholar
- 9.Gazaix, A., Gallard, F., Gachelin, V., Druot, T., Grihon, S., Ambert, V., Guénot, D., Lafage, R., Vanaret, C., Pauwels, B., et al.: Towards the industrialization of new mdo methodologies and tools for aircraft design. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, p. 3149 (2017)Google Scholar
- 10.van Gent, I., Ciampa, P.D., Aigner, B., Jepsen, J., La Rocca, G., Schut, E.J.: Knowledge architecture supporting collaborative MDO in the AGILE paradigm. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference (2017)Google Scholar
- 11.van Gent, I., La Rocca, G., Hoogreef, M.F.M.: CMDOWS: a proposed new standard to store and exchange MDO systems. CEAS Aeronaut J (2017)Google Scholar
- 12.van Gent, I., La Rocca, G., Veldhuis, L.L.M.: Composing MDAO symphonies: graph-based generation and manipulation of large multidisciplinary systems. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference (2017)Google Scholar
- 13.van Gent, I., Lombardi, R., La Rocca, G., d’Ippolito, R.: A fully automated chain from mdao problem formulation to workflow execution. In: EUROGEN 2017 (2017)Google Scholar
- 14.Gondhalekar, A.C., Guenov, M.D., Wenzel, H., Balachandran, L.K., Nunez, M.: Neutral description and exchange of design computational workflows. In: 18th International Conference on Engineering Design (2011)Google Scholar
- 15.Grosskopf, A., Weske, M., Decker, G.: the process: business process modeling—using Bpmn. Meghan Kiffer Press (2005)Google Scholar
- 16.Hoogreef, M.: Advise, formalize and integrate mdo architectures—a methodology and implementation. Ph.D. thesis, TU Delft, Delft University of Technology (2017)Google Scholar
- 17.La Rocca, G.: Knowledge based engineering techniques to support aircraft design and optimization. Delft University of Technology, TU Delft (2011)Google Scholar
- 20.Lano, R.J.: The n2 chart. TRW Software Series (1977)Google Scholar
- 21.Lefebvre, T., Bartoli, N., Dubreuil, S., Panzeri, M., Lombardi, R., Della Vecchia, P., Nicolosi, F., Ciampa, P.D., Anisimov, K., Savelyev, A.: Methodological enhancements in MDO process investigated in the AGILE European project. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference (2017)Google Scholar
- 22.Nagel, B., Böhnke, D., Gollnick, V., Schmollgruber, P., Rizzi, A., La Rocca, G., Alonso, J.J.: Communication in aircraft design: can we establish a common language? In: 28th International Congress Of The Aeronautical Sciences, Brisbane (2012)Google Scholar
- 25.Schmidt, M.: Der Einsatz von Sankey-Diagrammen im Stoffstrommanagement. Beiträge der Hochschule Pforzheim. Hochsch. Pforzheim (2006). https://books.google.de/books?id=zhBbMgAACAAJ
- 26.Sellar, R., Batill, S., Renaud, J.: Response surface based, concurrent subspace optimization for multidisciplinary system design. AIAA paper 714, 1996 (1996)Google Scholar
- 29.Steward, D.V.: The design structure system: a method for managing the design of complex systems. IEEE Trans. Eng. Manag., 3, 71–74. IEEE (1981)Google Scholar
- 30.Vandenbrande, J., Grandine, T., Hogan, T.: The search for the perfect body: Shape control for multidisciplinary design optimization. In: 44th AIAA Aerospace Science Meeting and Exhibit, Reno, NV, 2006-928 (2006)Google Scholar
- 31.Wagner, T.C., Papalambros, P.Y.: General framework for decomposition analysis in optimal design. ASME Adv. Des. Autom. New York 65, 315–325 (1993)Google Scholar
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.