Formulation and integration of MDAO systems for collaborative design

(1)

Formulation and integration of MDAO systems for collaborative design

A graph-based methodological approach

van Gent, Imco; La Rocca, Gianfranco

DOI

10.1016/j.ast.2019.04.039

Publication date

2019

Document Version

Final published version

Published in

Aerospace Science and Technology

Citation (APA)

van Gent, I., & La Rocca, G. (2019). Formulation and integration of MDAO systems for collaborative design:

A graph-based methodological approach. Aerospace Science and Technology, 90, 410-433.

https://doi.org/10.1016/j.ast.2019.04.039

Important note

To cite this publication, please use the final published version (if applicable).

Please check the document version above.

Copyright

Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy

Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim.

This work is downloaded from Delft University of Technology.

(2)

Contents lists available atScienceDirect

Aerospace

Science

and

Technology

www.elsevier.com/locate/aescte

Formulation

and

integration

of

MDAO

systems

for

collaborative

design:

A

graph-based

methodological

approach

Imco van Gent

∗

,

Gianfranco La Rocca

FacultyofAerospaceEngineering,DelftUniversityofTechnology,Kluyverweg1,2629HS,Delft,theNetherlands

a

r

t

i

c

l

e

i

n

f

o

a

b

s

t

r

a

c

t

Articlehistory:

Received 2 December 2018

Received in revised form 27 February 2019 Accepted 21 April 2019

Available online 3 May 2019 Keywords: MDO MDAO Graph theory Collaborative design Design tool

Thispaperproposesanovelmethodologyanditssoftwareimplementation,calledKADMOS (Knowledge-andgraph-basedAgileDesignforMultidisciplinaryOptimizationSystem),toincreasetheagilityofdesign teams incollaborative MultidisciplinaryDesign Analysisand Optimization (MDAO). Agilityhere refers to the ease and flexibility to assemble, adjust and reconfigureMDAO computational systems. Thisis a necessaryfeatureto complywiththe complex and iterativenature ofthe (aircraft)design process. KADMOShasbeendevelopedonthenotionthataformalspecificationofanMDAOsystemisrequired beforeproceeding withintegrationofthe executableworkflow.A thoroughformulationofthesystem becomesessentialwhensuchsystemisbuiltonthemanycontributionsoflarge,heterogeneousdesign teams.KADMOScanautomatethegenerationofsuchformulationsthroughagraph-basedmethodological approach. The graphsyntaxand manipulationalgorithms formthe corecontentofthispaper. First,a simple MDAO benchmarkproblemis used toillustrate KADMOS’sworking principles.Second,awing aerostructural design case is discussed to demonstrate KADMOS’scapabilities to enable collaborative MDAOonlargeproblemsofindustry-representativecomplexity. Nexttoitsgraph-theoreticfoundation, KADMOSmakesuseoftwodataschemas:onecontainingtheparametricrepresentationoftheproduct being designed and a second to store the achieved formulation of the MDAO system. The latter enables theinterchangeable use ofdifferentprocess integrationand design optimization platformsto automaticallyintegratethegeneratedMDAOsystemformulationasanexecutableworkflow.Theproposed approachhasbeenestimatedtobecapableofhalvingthetimetypicallyrequiredtosetupanditeratively reconfigureacomplexMDAOsystem,whileallowingdisciplineexpertsandsystemarchitectstomaintain constantoversightandcontrol oftheoverall systemanditscomponentsbymeansofhuman-readable dynamicvisualizations.

1. Introduction

Past research indicates that Multidisciplinary Design Analysis andOptimization (MDAO) can offerhuge benefits indesign with estimatedperformance gains of8-10% for innovative aircraft de-signandeven 40-50%gains fordesigning radically newconcepts [8,55]. Despite the high potential gains, MDAO is not as widely used in industry as one would expect. Both technical and non-technicalbarriers[1,6,46,49,50] arehamperingitsfullexploitation. Fig.1illustrates thefivemainstagesofagenericMDAO-based development process, arranged in two main phases. On the left sideonehastheformulationphase wheretheMDAOproblemis de-finedbasedonasetofdesigncompetences(i.e.arepositoryof

dis-*

Corresponding author.

E-mailaddresses:i.vangent@tudelft.nl(I. van Gent), g.larocca@tudelft.nl (G. La Rocca).

ciplinaryanalysistools).Theoutcomeofthisphaseistheso-called MDAO solutionstrategy: a complete and formal speciﬁcation, al-though inexecutable, of the formulated MDAO system. Different strategies,referredinliterature asMDAOarchitectures [38],can be usedtosolveagivenMDAOproblem,whereeachstrategyisbased on a different approach to coordinate the involved design com-petences. Classicexamplesarethemonolithic(thusincludingone optimizer)architecturesMultiDisciplinaryFeasible(MDF)and Indi-vidualDisciplineFeasible(IDF)andthedistributed(thusincluding multipleoptimizers)ones,suchasCollaborativeOptimization(CO) [9] andBi-LevelIntegratedSystemSynthesis (BLISS)-2000[52].In thiswork,bythetermMDAOstrategy,wealsoaddressotherforms of multidisciplinary coordination systems without optimization, such assinglepointdesignconvergenceschemes(hencetheMDA partofMDAO)andDesignOfExperiments(DOE).Theformulated MDAO solution strategy, based on whichever of the aforemen-tionedarchitectures,formstheblueprintoftheworkﬂowthatwill https://doi.org/10.1016/j.ast.2019.04.039

(3)

Abbreviations

AMR Architecture-speciﬁcMathematicalRelation BLISS Bi-LevelIntegratedSystemSynthesis CDS CentralDataSchema

CO CollaborativeOptimization

CPACS CommonParametericAircraftConﬁgurationSchema CMDOWS CommonMDOWorkﬂowSchema

DOE DesignOfExperiments DVD DesignVariableDependent DSM DesignStructureMatrix DVI DesignVariableIndependent FDT FunctionalDependencyTable FPG FundamentalProblemGraph

FT FuelTank

IDF IndividualDisciplineFeasible I

/

O Input/Output

KADMOS Knowledge- andgraph-basedAgileDesignfor Mul-tidisciplinaryOptimizationSystem

MDA MultidisciplinaryDesignAnalysis

MDAO MultidisciplinaryDesignAnalysisandOptimization MDF MultiDisciplinaryFeasible

MDG MDAODataGraph

MDO MultidisciplinaryDesignOptimization MPG MDAOProcessGraph

MTO MaximumTake-Off

PIDO ProcessIntegrationandDesignOptimization PSN ProcessStepNumber

QOI QuantityOfInterest

RCG RepositoryConnectivityGraph XDSM eXtendedDesignStructureMatrix XML eXtensibleMark-upLanguage

ZF ZeroFuel

Fig. 1. Overview

of MDAO terminology for the MDAO-based development process used in this paper. The process is divided in two phases: formulation (left) and execution

(right). The application area of KADMOS within the overall MDAO system development process is indicated by the blue box. (For interpretation of the colors in the ﬁgure(s), the reader is referred to the web version of this article.)

be integrated andoperated in the executionphase of the MDAO-baseddevelopmentprocess,asillustratedintherightpartofFig.1. Inpractice,animplementationgap impairsastreamlined transi-tionfrom the formulationto the executionphase andback. This is due to the fact that the non-formal specification of the for-mulated MDAO solution strategy needs to be translated into an executablesystemby meansofaprocess thatislargely basedon manualoperations. ThistranslationoftheMDAO blueprint intoa software-specificexecutableworkflowisusuallydonethroughthe graphicaluserinterface ofaProcessIntegration andDesign Opti-mization(PIDO) platformsuchasModelCenterIntegrate[69],RCE [65], Optimus [70], ora script-based interface, as in the caseof OpenMDAO [26,27,63].Asaconsequence,theimplementationgap growswiththesizeoftheMDAOsystemandtheheterogeneityof thedesignteam.Thelatterisdefinedasthediversityoftheteam measuredby theamountofdisciplinarydomains,work locations, software implementation methods and rolesin the development andutilizationoftheMDAOsystem.

Moreover,inarealisticdesignprojectmultipleiterationsofthe wholeMDAO-baseddevelopmentprocessaregenerallyperformed. Insightgainedduring orafteranexecutionrunwilltypically trig-gerchangesinthetoolrepository(e.g.addition,removal, replace-ment), in the formulation of the MDAO problem (e.g. change of objective,additionorremovalofconstraintsanddesignvariables), orintheMDAOsolutionstrategy(e.g.fromaDOEarchitecturefor designspaceexploration toanotherforactual optimization).This reconfigurationprocess ofthe MDAO system can be iterated un-tila satisfactorydesignisfound ortheprojectdeadlinehasbeen reached.Thetimerequiredforeachiterationstronglydependson theeasetoadjustandreconfiguretheMDAOsystemdefinitionand theabilitytobridgetheimplementationgap.

Inthe industrialaircraft designcontext, boththe size of typi-cal MDAO problems andtheneed toleverage on distributedand heterogeneous design teams severely frustrate any collaborative MDAO ambition. In the words of Pate etal. [44] theformulation oftheseproblemshasbecomeincreasinglycomplexasthenumberof analysistoolsanddesignvariablesincludedintypicalstudieshasgrown. Inthiscontexttheproblemofdeterminingafeasibledataflowbetween toolstoproduceaspecifiedsetofsystem-leveloutputsis combinatori-allychallenging.Especiallywhencomplexandhigh-fidelitytoolsneedto beincluded,thecostandtimerequirementstointegratetheMDAO sys-temcaneasilyapproachthecostandtimerequirementsofcreatingany ofthedisciplineanalysesthemselves. ArecentsurveybyCiampaand Nagel [10] oncollaborativeMDAO-oriented research projects per-formedattheGermanAerospaceCenterconfirmedthat60-80%of theoverallprojecttimewasusedjusttoachieveafirstexecutable dataflow.

Next to the impact on process lead time, the current lack of agilityintheformulationandintegrationofMDAOsystemshinders bothanefficientreuseofexistingtoolsandtheexploitationofnew ones, asforeveryMDAOproblem(re-)formulation,thetoolshave tobe(re)integratedintoanewworkflow.Evenwhenthesameset of tools needs to be coordinated according to a different MDAO architecture,reshufflingthepreviouslygeneratedexecutable work-flow is neither a trivial operation, nor fast (a notable exception beinganimplementationinOpenMDAOV0[25]).

Thislackof(re)conﬁgurationagility versusthepotential bene-ﬁtsoftheMDAO methodwithrespecttoexisting designmethods is effectivelysummarizedin Fig. 2by Flager andHaymaker [18], which is the result of a comparison study between the Boeing legacy design method and an MDAO-based process for the de-velopment of a hypersonic vehicle [8,55]. The mainhurdle

(4)

iden-Fig. 2. Comparison

of legacy and MDAO design process metrics for the design of a

hypersonic vehicle [18].

tified for the MDAO approach was the long set-up time of the MDAOworkflow(14weeks),whichwasmorethandoublethetime necessary to deliver the first design using the legacy method (6 weeks),with theconsequent risk associatedto the late availabil-ityof thefirst results.The potential of theMDAO-based process, however, is also clear: once the set-up of the MDAO workflow iscomplete,an enormousamountofiterations canbe performed (1000vs. 2.5forthelegacymethod), leavingmuchmoretime to theinterpretationoftheresultsratherthanthecoordinationofthe generatedinformation.

The longer specification time required for the MDAO system specificationisdueto thefact that theautomation ofthe multi-disciplinaryanalysisworkflow (whichisanecessarycondition for MDAO)isonlypossibleifalltheconnectionsbetweenthedifferent disciplinary analyses are created correctly, down to the smallest detail.Without therightformalization forsystemspecificationin theformulationphase,thecreationofthisautomatedworkflowis a complex andtime-consuming trial-and-errorprocess. In indus-trialdesignsituations,wheredeadlinesarestrictandrisksneedto beminimized,theresultingpostponementoftheinitialdesign,in combinationwiththetime-consumingdetailedspecification,poses amajorhurdle.Asaconsequence,implementationsoflargeMDAO systemsinindustry are scarce,generallytailor-madeto aspecific applicationandtoodifficulttoreconfigure.

Theformalizationandmethodologypresentedinthispaper en-able an agile approach forthe specification andmanipulation of MDAO systems of whatever size, to facilitate their transforma-tion into executable workflows by means of any PIDO platform of choice and thereby drastically narrowing the implementation gap.Itssoftwareimplementation,calledKADMOS(Knowledge- and graph-based Agile Design for Multidisciplinary Optimization Sys-tem),offersMDAOsystemarchitects theabilitytoformulatelarge andcomplex MDAO systems,based on a repositoryoftools pro-videdbyheterogeneousdesignteams.ThespecificKADMOS appli-cation area within the overall MDAO-based development process is indicated by the blue box in Fig. 1. This paperillustrates and demonstratesKADMOS’sabilitytosupportallstagesoftheMDAO system formulation phase, from the definition of a design com-petence repository, up to the generation of a complete system formulation,readytobetranslatedintoexecutableworkflows.

This paper caters to a broad audience, reflecting the variety of people’s roles involved in collaborative MDAO projects. Read-ers unfamiliar with the MDAO field (e.g. disciplinary specialists), or those who would like to havea deeper understanding ofthe motivation for KADMOS’s development, should read the state of theartinSect.2.A top-leveldescriptionofKADMOS isprovided inSections3and4andisofinteresttoanyreaderinvolvedin col-laborativeMDAO. Readersspecifically interested inthedeveloped graphsyntax andconditions(e.g. integrators, collaborative

frame-Fig. 3. Schematic

summary of the two main system composition approaches found

in literature.

workdevelopers)shouldreadSections5and6,whileotherreaders cansafelyskipthosesections.Acasestudyconcerningthe collab-orative designofapassengeraircraftwingispresentedinSect.7

andisrelevanttoreaders(e.g. executives andaircraft manufactur-ers) interested in evaluating the impact of theKADMOS package onacollaborativeMDAOprojectofrealisticcomplexity.

2. Stateoftheart

The composition, representation and manipulation of large, complexengineeringdesignsystemshasbeenunderinvestigation for several decades. This section describes the state of the art, fromwhich thefunctional requirementsforKADMOS arederived inSect.3.

2.1. Systemcomposition

The composition of the MDAO system, i.e. the wayits differ-ent elements are interconnected into a computational system, is an unreported topic inmostwork. Thoughit might seemtrivial, depending onthe approach, the assemblyof all components can be a cumbersome task for large MDAO systems, with a big im-pactonthetimespentintheformulationphase.Thisisespecially true whena large, heterogeneousdesign teamis involved.A key assumptionaffectingthesystemcompositioniswhethervariables are related to a single component or shared and/or coupled to multiple components.Twobasic approachesforsystem composi-tioncanbefoundinliterature:decentralizeddataandcentralized datamapping,both summarizedinFig. 3.Whilebothapproaches would eventually result inthe same MDAO system, the role and responsibilitiesofsystemintegratorsandtoolsprovidersdifferfor eachcompositionmethod.

Tosserams et al. [54] have a decentralized data mapping ap-proachintheir

language forproblempartitioning. Intheir sys-tem each componentcan be deﬁnedindependently andit is the responsibilityofthecomponentprovidertodeﬁnelocalandglobal

(5)

inputvariables.When thecomponentsareassembled,thesystem integratorhastomanually maptheglobalinputs/outputs (I/O)of allcomponents,thatistoidentifywhichgloballydeﬁnedvariables are actually referring to the same value. A similar approach can befound in object-oriented frameworkssuch as

π

MDO[39] and OpenMDAO.InOpenMDAOtheusercanprovidedifferentnaming conventions for the same variable in each component and then explicitlystate that the components are actually referring to the samevariablebyconnectingthem.

Thedecentralizeddatamappingapproachleadstoahigh work-load for the system integrator, proportional to the size of the MDAOsystem. Aclearadvantage ofthisapproachisthe freedom left to the various tool providers, as they can decide their own variablenames astheysee ﬁt.Hence, theMDAO system integra-torisassignedextraresponsibilities,inexchangeofanon-intrusive approachtowardsthetool providers.Furthermore,asconnections arehandcraftedbytheintegrator,avalidMDAOsystemcanbe in-stantiateddirectly, without the need to ﬁx problematic nodesor connectionsposthoc.

In the centralized data mapping approach, a system-wide naming convention is used to establish component connectivity. Alexandrov and Lewis [3,4] use this method in their linguistic approachcalledREMS;componentprovidersdeﬁnetheir I/O vari-ables according to a shared dictionary of variable names, which needstobe expandedwitheachnewsystemcomponentthat in-troducesnewvariables.Theintegratoristhusrelievedofthe map-pingburden,attheexpenseofanextra managementtaskforthe dictionaryand alimited freedom invariable namingforthe tool providers.Thisapproach can alsobe usedin OpenMDAOby pro-motingvariablenamestoacommonsharedvariablenamewithin themodel,thereby automaticallyconnectingthesevariables.Also Hoogreef [31] uses thecentralized data mappingapproach inhis ontology-basedMDAO-support frameworkInFoRMA, inwhichthe userbuildsandassemblesthesystemusinganinteractiveN2 chart toaddcomponentsanddeﬁnecouplings.

Anothervariantofthecentralizedapproachwouldbe toadopt aCentral Data Schema (CDS).TheadoptionofaCDSavoidsthe is-sueofupdating thedictionary(REMS) orlistof promotednames (OpenMDAO) for each MDAO systemdefinition. Nagel et al. [43] haveproposed a standard XML-based schemafor aircraftdesign, calledCommon ParametricAircraftConfiguration Schema(CPACS) [60]. In practice, CPACS provides an extensive predefined stan-darddictionary,whichismeanttocontainallthetypicalI/Odata ofthe analysistools used in conceptual andpreliminary aircraft design.1 _When _using _CPACS, _each _disciplinary _tool _in _the _MDAO systemtakesaCPACSfileinstanceasinputandhastowriteits re-sults to a new CPACS file. All data is then gatheredby merging the different complementary CPACS files. Thus, once all compo-nentprovidershave“madetheinvestment”ofrenderingtheirtool CPACS-compatible, assembling even large executable MDAO sys-temsbecomesarelativelyeasytaskfortheintegrator.

TheCPACSdefinitionhassofarbeenusedinmultiple collabo-rativeprojects onaircraftMDAO [24,35,41,42] and hasproven its valuefacilitatingtheassemblyoflargeanddistributedMDAO sys-tems. Whereas CPACS is aircraft specific, a CDS would prove its value in any other application domain, given a schema is made availableapriori.TheapproachisgainingmomentumintheMDAO community,withasimilar typeofschemaunderdevelopment in the wind energy domain by Dykes et al. [14]. This schema also usesfile I/Otoexchangedata(YAML-basedinsteadofXML), how-ever,conceptuallyaCDSapproachdoesnotnecessarilydependon

1 _{Any missing data in the schema can be temporarily stored under a “free”}

ele-ment. If such data appear more often than a single project instance, the structure under the free element can be suggested for adoption in the oﬃcial schema.

ﬁle-baseddataexchange(e.g.astring-basednamingconventionor Pythondictionary).

Althoughschema-centeredreroutingofthetoolconnections fa-cilitates workflow assembly, it comes with two limitations. First, onecaneasilylooseoversightonthesystem’sconnectivity.For ex-ample,ifatool providingthevaluesforcertainCPACSdatanodes is removed, it is difficult to determine whether some other tool is affected by the lack of those input data. Second, contrary to the handcrafted connections in the decentralized approach, the indirect componentcouplings ofthe schema-based approachcan easily lead to a system with problematic variables and connec-tions.Hence,adedicatedformulationsystemisrequiredtoprovide systemoversight,checkforproblematicvariablesandconnections, and fix them.This formulation systemis proposed in this paper andprovides themissinglinkbetweenthehandcrafted decentral-izedapproachandtheautomaticcentralizedmannerofcomposing MDAOsystems.

2.2. Systemrepresentation

Systemrepresentationsareusuallymotivatedbytheirintended use,suchasperformingspecificmachineoperations(e.g. partition-ing)orprovidingahuman-readableoverviewoftheMDAOsystem. Well-knownhuman-readablerepresentationsaretheN2_chart_[₃₄_], theDesignStructureMatrix(DSM)[53] andtheFunctional Depen-dency Table (FDT) [57]. The DSM approach, which only specifies the data coupling between different components, was extended by Lambe and Martins [33] into the eXtended Design Structure Matrix (XDSM) to include also information concerning the pro-cesstobeexecuted. Today,theXDSMnotationcan beconsidered a de-facto standard within the MDAO community for providing human-readableoverviewsofMDAOworkflows,independentfrom any proprietary PIDO tool formalization. Since the readability of anXDSM asastaticdocumentdegradeswiththesizeofthe rep-resentedcomputationalsystem, web-baseddynamicXDSM visual-izationtoolshavebeendevelopedbyGazaixetal. [19] andAigner etal. [2],withtheir respective developmentsofthe XDSMjs[67] packageandVISTOMS[66].

All commercialPIDOplatforms provide agraphical user inter-face to assemble and display an executable MDAO workflow. In the background these workflows are represented in a machine-interpretableformat,oftenbasedonXMLorproprietarystandards. Object-orientedframeworksforMDAOhavebeendescribedin sci-entificliteraturethatcreatemachine-interpretablerepresentations ofgivencomputationalsystemsbyconstructingprogramming ob-jects [25,39]. Thisapproach hasthe majoradvantage that a soft-warepackagecanbecreatedthatcontainsanintegratedcollection of methods to execute the MDAO system the best way possible (e.g.usingdifferentoptimizationstrategiesortakingbenefitfrom parallelcomputingmethods).Thedownside ofthisrepresentation is that it forces the user to employ the same platform forboth theformulationandtheexecutionofthecomputationalworkflow. However, most of theseplatforms are rathergeared towards the execution ofthe computational systemandoffer limited support intheformulationphase.Forexample,theyarenotabletoprovide adequatehuman-readableoverviewsoflargeandcomplexsystems, whichisadealbreakerwhenformulatingMDAOsystemsina col-laborativeenvironment.

Inother work,machine-interpretablerepresentationsofMDAO systemsarecreatedbydeﬁningalanguage.Examplesofthese lin-guisticrepresentationsarethe

χ

[17],

[54] andREMSlanguages. TheselanguagesallowanintegratortocomposetheMDAOsystem in a relatively straightforward way (once familiar with the syn-tax), sothatalgorithms builtupon thelanguagecanperform sys-temmanipulations,likeproblemdecompositionandcoordination. AradicallydifferentrepresentationofMDAO systemswas

(6)

investi-gatedbyHoogreef [31],whomakesuseofontologiestomodeland storeMDAOsystemsinhisInFoRMAplatform.Byrepresentingthe MDAOsystemasa‘meaningful’ (semantic)web ofdata,semantic reasoningengines [7] areusedinInFoRMAtoassessand manipu-latethesystem.

Pate et al. [44] realized that manyof the MDAO system rep-resentationscan be broughtback tothe basicmathematical con-struct of (directed) graphs. Thisis true for some languages such asREMS andInFoRMA’s ontologies, butalso forpurely graphical representationslike theN2 chart andtheDSM. Basedonthis re-alization, Pate et al. defined a graph-based syntax to store and manipulateMDAOsystems.Threetypesofdirectedgraphsare de-fined in Pate et al.’s graph syntax that map one-on-one to the threestagesoftheMDAOsystemdevelopmentprocess illustrated in Fig.1. These are themaximal connectivitygraph to represent thetoolrepository,theFundamentalProblemGraph(FPG)to rep-resent thestatement oftheMDAO problem,andtheproblem so-lutiongraphto representthe MDAO solutionstrategy adoptedto solvethefundamental problem.Thesegraphdefinitionsandtheir manipulation algorithms are mainly focused on the challenge of findingpossiblecombinationsofdesignandanalysistoolstosolve agivenMDAOproblem.Thustheirmainobjectiveistheautomatic determination ofthe FPG, starting from the larger maximal con-nectivitygraph.

2.3. Systemmanipulation

Apartfromthe(X)DSMvisualizations,alloftherepresentations discussed in the previous section are machine-interpretable and areset upto enable variousformsofcomputerized manipulation of the MDAO system. These manipulations are generally related to the link between subsequent stages in the formulation phase (Fig.1) andaimatautomating (partof)the workrequiredto ad-vancefromonestagetotheother.

The first link is between the tool repository and the MDAO problem formulation. In general, automation in the first link in-volvesthecreationofmethodsto1)identifypotentialdesign vari-ables, objectivevaluesand constraints,2) markthem assuch, 3) findvalidcombinationsoftoolstoanalyzetheproblemandfinally 4)toremoveunnecessaryfunctions(tools)andvariables.Thework ofPateetal. [44] addressedinSect.2.2focusesspecificallyonthis area. Theyoffer a graph syntax andsuggest algorithms to deter-minedifferentpossibleMDAOproblemsbasedonatoolrepository definition. Also in the REMS language, the necessary manipula-tions to achieve the MDAO systemformulation are basedon the fullgraphofavailablefunctionsandcoupledvariables.

The second link, betweenthe MDAO problemand the MDAO solutionstrategy,ismorecomplexandhandledinmanydifferent ways in earlier work. In thislink the MDAO problem has to be decomposed to make it computationally tractable. This is gener-allyachievedbymeansofpartitioningandclusteringmethods.The

language isanexampleofamanipulation languagespeciﬁcally developedforsystemdecomposition.Othersystemdecomposition methodsare available inliterature, based onDSM [28,47,58] and FDT[5,40].

Afterdecomposition,a solutionstrategyhastobe imposedon theMDAO problemtocoordinate its execution. As anticipatedin the introduction,different MDAO architectures exist inliterature, each oneproviding adifferent recipetocoordinate the computa-tionalsystem.MartinsandLambe [38] haveprovidedanextensive reviewofthemostcommonlyused,includingbothmonolithic(e.g. MDF, IDF), and distributed types (e.g. CO, BLISS-2000). The fact that the same MDAO problemcan be solved using different so-lution strategies was one of the reasons to develop the MDAO frameworks

π

MDO, OpenMDAO, and InFoRMA, so that different

architecturescouldbetestedquicklyonthesameproblemby au-tomaticallyreconﬁguringtheexecutableworkﬂow.

ThethirdlinkbetweentheMDAOsolutionstrategyandthe exe-cutableworkﬂowconcernswiththeimplementationgapdiscussed above.Pastresearchframeworkshaveeithertightlyintegratedthe executableworkﬂowinthesameformulationframework,asisthe casefor

π

MDOandOpenMDAO,orworkedonmethodsto estab-lish an automated link to external PIDO platforms. The latter is thecaseofInFoRMA,whereabuilt-inmechanismparsingthe sys-temknowledgebasecreatesthematchingexecutableworkﬂowin Optimus.

provides an export moduleto enable the creationof executableworkﬂowsinMATLAB[68].

Despite these frameworks that can provide executable work-flowsbasedondifferentsolutionstrategies,animplementationgap isstillexperiencedwhenperformingcollaborativeMDAOwithin a large,heterogeneousteam,wheredifferentPIDOsystems or com-putational environments and optimization packages are at hand. A framework like OpenMDAO offers excellent possibilities to set up single-user executable MDAO workflows, but is limited in its capability tosupportcollaborative MDAOsystemformulationand to execute workflowson a distributed server environment.Some PIDO platforms available on the market allow the integration of multilevel and distributed MDAO workflows through manual “drag&drop” manipulations via their interface, but, at date,none providesactualformulationcapabilities[12,30].

3. RequirementsfortheKADMOSsystem

From the review of the state of the art it can be concluded that whilemultiplesolutionsexistfortheexecutionofevenlarge computational systems, there is lack of adequate support in the formulation phase. Methods have been developed to specifically address some of thestages in thisphase, but no comprehensive solutions addressing the whole MDAO system formulation in a collaborativeenvironment havebeenfound.Whilesome method-ologieshavebeenprovenabletoclosetheimplementationgapby means ofdedicatedinterfaceswithaPIDOtool,noneprovidethe flexibility to choose betweendifferentintegrationplatforms. Sev-eralgraph-basedrepresentationandmanipulationapproacheshave beenproposed byvarious authors,whichhaveprovenvery effec-tive within the limited scope of some of the formulationstages. The KADMOS systempresented in this paperaims atfilling this gapinthestate oftheart, byleveragingon thehighpotential of graph-basedrepresentation andmanipulation methods,to deliver aneutral, open-sourceplatform,specificallytargetedtothe devel-opment of large,distributed andcollaborative MDAO systems.To thispurpose,thefollowingtop-levelrequirementswereset:

1. Systemcomposition: ThesystemshouldbebasedontheCDS approachforI/Odataexchange.

2. Systemrepresentation: The syntax should be based on the graph-theoretic foundation for MDAO systems initiated by Pate et al., butshould also providethe human-readability of XDSMs.

3. Systemmanipulation: KADMOS should support automated formulation of MDAO solution strategies for MDA, DOE and MDOarchitectures.MDO-typearchitecturesshouldincludethe previously mentioned monolithic anddistributedapproaches, at leastincludingthe MDF, IDF, COandBLISS-2000 architec-tures.

4. PIDOplatform independence: The MDAO solution strategy formulated with KADMOS should be portable to a range of PIDO platforms, while maintaining complete independence fromthem.

5. Controlledautomation: The systemshould automate all the repetitive, non-creative tasks necessary to advance from one

(7)

formulation stage to theother, whilekeeping the system ar-chitect in control of all settings and strategic decisions that require engineering judgment (e.g. to deﬁne the problem, to pickthearchitecture).

6. Toolheterogeneity: Thesystemshouldsupportabroadrange of design tool types ranging from simple mathematical re-lations, to more complex surrogate model relations, up to complex disciplinary tools to be executed as black boxes on separate serverdomainsbecauseofintellectualproperty con-straints.

7. Scalability: The systemshould be able to handlesystems of anysizeandcomplexity.

4. KADMOSgraphtypes

Thefollowinggraphsrepresentthefundamentalmeansusedin KADMOStostoreandmanipulatetheMDAOsystemthroughoutits entireformulationprocess:

Data graphs

Repository Connectivity Graph (RCG) Basedon arepositoryof CDS-compatibledesignandanalysistools,agraphcanbe cre-ated that links all the I/O variables and represents the toolrepository.

Fundamental Problem Graph (FPG) TheFPGisanenriched(i.e. con-taining additionalattributes)subset (i.e. duetoremoval ofunnecessary functionsandvariables)oftheRCG.Itis createdbyperforminggraphmanipulationsonanRCGto deﬁne a graph that represents a valid (in terms of the strict KADMOS graph conditions discussed in the next sections) MDAO problem. This graph can then be used toimposeanMDAOarchitectureonit.

MDAO Data Graph (MDG) TheMDAOsolutionstrategystageis repre-sented by two graphs: a dataand aprocess graph.The MDG is the data graph that stores the data exchanged by the executable blocks and the CDS nodes that are required to solve the MDAO problem, according to the selected architecture.The executableblocksin theMDG include both therepository toolsfromthe FPG andthe

architectureelements,necessary toimplementthe MDAO architecture athand,suchasconvergers,optimizers,and Architecture-speciﬁc MathematicalRelations(AMRs)(i.e. consistencyconstraintfunction).

Process graphs

MDAO Process Graph (MPG) This graph does not contain any data node, butonlytheexecutableblocksfromtheMDG and thespeciﬁcationoftheirexecutionsequence.

The general KADMOS graph syntax will be described in the next section. The detaileddescription of the individual graphs is provided in Sect. 6, supported by a small illustrative example. KADMOS [61] isimplementedasaPythonpackage.Allgraphsare subclassesofthe

DiGraph

classfromtheNetworkX[29] package; seetheclassdiagraminFig.4.

Althoughthere isaconceptualresemblancebetweenKADMOS graphsandthose proposedbyPate etal,thereare notable differ-encesinthegraphsyntax,aswellasinthescopeand implemen-tation of the entire MDAO support system. The most significant difference with respect to Pate’s graph-based methodology con-cerns the scope.Whereas Pate’sgraph formulationis focused on the transition between the first and second stage of the MDAO developmentprocess,KADMOS hasabroaderscopeincludingthe transitionsto stages three andfour. The inclusion of these addi-tionalstagesrequiredamoresophisticateddefinitionofthesyntax andthe graph-theoretic conditions the graphs haveto satisfy. In addition,KADMOSisbasedontheCDSapproachforsystem

com-Fig. 4. Class diagram of the KADMOS package. N.B. BusinessProcessGraph

class is not discussed in this paper.

position, which further differentiates the syntax and conditions. Finally,theKADMOSsyntaxcoversbothmonolithicanddistributed MDO architectures,whereas thelatterwerenotcovered byPate’s approach.

5. KADMOSgraphsyntaxandmaingraphclasses

This section provides a formal definition of the graph syntax adoptedinKADMOS. Thetwo maingraphclasses(Fig. 4) are de-fined aswell. Thesyntax followsthenotation ofDiestel [13] and Pate et al. [44]. Key concepts of graph theory are briefly revis-ited here for convenience, followed by the definition of nodes (Sect.5.1),edges(Sect.5.2),andmaingraphclasses(Sect.5.3)used inKADMOS.

AgraphG isbuiltusingasetofverticesV (ornodes)andaset ofedges E (alsocalledconnections):

G

= (

V

,

E

)

in which E

⊆ [

V

]

2, meaning that the elements of E are two-element subsets of V . All KADMOS graphs are a special type of graphs, calleddirected graphs (ordigraphs),2 _where _{E contains}_a set of ordered pairs to indicate the edge direction. The node v

wouldbeconnectedtothenode w withtheedgee

= (

v

,

w

)

.Every edgeina digraphhasaninitial vertexinit

(

e

)

anda terminal ver-texter

(

e

)

.Thesetofedgesgoingoutofv aredenotedwithE+

(

v

)

andthetotalamountofedgesgoing outof v iscalledthe outde-gree of the node andisdenoted with

δ

+

(

v

)

.Similarly, theset of incomingedgesaredenotedas E−

(

v

)

andtheindegree isdenoted with

δ

−

(

v

)

.

An example digraph is shownin Fig. 5. This graph wouldbe deﬁnedwiththetwosets:

V

= {

a

,

b

,

c

,

d

,

e

,

f

}

E

= {(

a

,

a

), (

a

,

d

), (

b

,

a

), (

b

,

e

), (

d

,

b

), (

d

,

c

), (

e

,

b

)

}

Aloop inadigraphwouldbedeﬁnedbyanedgewithinit

(

e

)

=

ter

(

e

)

. In KADMOS graphs these kind of loops are not allowed, meaning that only simpledigraphs are used. A loopedpair is al-lowed in simple digraphs. Looped pairs are deﬁned as pairs of nodes

{

v

,

w

}

forwhichthereisanedgeinbothdirections,hence

(

E+

(

v

)

⊃

e

|

ter

(

e

)

=

w

)

∧ (

E−

(

v

)

⊃

e

|

init

(

e

)

=

w

)

. See the pair

2 _{More speciﬁcally, most graphs are directed}_{cyclic graphs,}

_{though acyclic graphs}

(8)

Fig. 5. Example of a directed graph illustrating some key concepts.

{

b

,

e

}

in Fig.5. The amount of such looped pairs of one node v

withrespecttoitsneighbors isreferredtoasthecircularityindex:

cir

(

v

)

.ThisisoneofthefundamentalKADMOSextensionstoPate’s syntax.

Apath Q

= (

V

,

E

)

from v0 to vk ingraphG is asubgraph of

G ( Q

⊆

G)withV

= {

v0

,

v1

, ...,

vk

}

andE

= {(

v0

,

v1

),

(

v1

,

v2

),

...,

(

vk−1

,

vk

)

}

. See as example the path with V

= {

e

,

b

,

a

,

d

,

c

}

in Fig.5. Acycle C is a pathfor which v0

=

vk,e.g. the cyclewith

V

= {

b

,

a

,

d

,

b

}

inFig.5.

Inan acyclic directed graphthe nodescan always be ordered insuchawaythat onemovesforwardwhenfollowingtheedges. This is called a topologicalordering of the graph. Hence, if a di-rectedgraphhasthetopologicalorderingofthevertices

v

,

w

, . . .

, it means that forevery edge inthe graph the initial vertexalso comesbeforetheterminalvertexintheordering(e.g.if

∃(

v

,

w

)

:

v

comesbeforew intheordering).

To combine graphs, a notation for the union of a set of sets is required. If we deﬁne I to be a non-empty set such that for each i

∈

I there is a corresponding set Ai, then the set of sets

A

= {

Ai

|

i

∈

I

}

iscalledanindexedfamilyofsetswithindexi and indexingsetI [51].Theunionofthisfamilyofsetscanbedenoted indifferentways:

i∈I Ai

=

A∈A A

= {

x

|

x

∈

A for some A

∈

A

}

Finally,thesizeofaset B iscalledthecardinality andisdenoted by

|

B

|

.AsetdifferenceisdenotedasA

\

B

= {

x

∈

A

|

x

∈

/

B

}

.

5.1. Nodedeﬁnitions

The deﬁnitionofnodesin aKADMOS graphis done using at-tributes. The different node attributes are listed in Table 1. The attributevaluesareusedthroughoutthewholepackagetoinspect andmanipulatethegraphs.Themainattributeofanodeisits cat-egory,denotedascat

(

v

)

,whichcanhavethetwofollowingvalues: function (vf): operators, alsocalledexecutableblocks.Every

possi-bleoperator is deﬁned asa function node inKADMOS, e.g. a mathematical expression,an analysistool, an op-timizer, a converger. The subset of function nodes in a graphG isdenotedbyVf

= {

v

∈

V

|

cat

(

v

)

=

function

}

.

variable (vv): elementsfromtheCDS.Thesevariablenodescan

rep-resent different variable types, such as scalars, vectors andmatrices. ThesubsetofvariablenodesinagraphG

isdenotedbyVv

= {

v

∈

V

|

cat

(

v

)

=

variable

}

.

All nodes can get an instance speciﬁed. A node instance at-tributeisusedtoallowmultipleinstancesofanode thatreferto thesametoolinthetoolrepository,ortothesameelementinthe CDS.Anodeinstanceisanintegervaluedenotedbyins

(

v

)

,where thedefaultinstance valueis zero.Apractical exampleofthe use ofnode instances fora variableisthe situationwheretwo func-tions (e.g. A and B) havethe samevariableb as output,butthe valueswrittenbythosetoolsarerequiredatdifferentmomentsin theMDAO systemexecution. In such acase, it could be required

that A ﬁrstdetermines thevalue ofb (ins

(

b

)

=

0) whichis used bysomeother tools,andB lateroverwritesthisvalue(ins

(

b

)

=

1) to be used by other toolsin the MDAO system. Hence, thenode instances are required in the graphto be able to indicate which functionsareusingandproducingwhichnodeinstance.

Another key attribute of both function and variable nodes is the role they play ina certain graph.Two typesofroles are de-ﬁnedinKADMOSgraphs:theproblemrole (denotedpr

(

v

)

)andthe

architecturerole (denoted ar

(

v

)

). The problem role is usedin the FPG to indicate special variables, such as design variables, con-straints, objective, andquantities of interest (QOIs).The problem role ofa function intheFPG isrelatedto its positionwithin the MDAO systemand will be further explained inthe next section. The architecturerolesareusedintheMDGandMPG.Theseroles indicatespecialvariableandfunctionnodesrequiredbyMDAO ar-chitectures,such asinitial guesses,copyvariables,optimizersand consistency constraintfunctions. Afulllistofarchitecture rolesis providedinTable3andisfurtherdiscussedinSect.6.

An attribute speciﬁc for function nodesis the mode attribute,

denoted by mode

(

v

)

. This attribute is used to indicate that the sametoolfromtherepositorycanbeexecuted indifferent opera-tional modes(e.g.an aerodynamic analysistool canoperate both in viscous orinviscid mode), using different I/O branches in the CDS. Byusingthe keyword‘mode’the I/Osofthe different func-tion modescan beﬁltered automatically, asshowninFig. 6. The advantageofusingthemodeattributeisthatatoolwithmultiple executionmodescanstill be storedinthe repositoryasone tool, withonlyonemappingdeﬁnitiontotheCDS.

Anotherfunction-node-speciﬁcattributeistheorderedset con-tainingthe processstepnumbers (PSNs),denoted bypsn

(

v

)

.These step numbersare integers usedto specifythe executionorderof thefunctionnodesinaprocess graph(Fig.7b).Theprocess num-beringadherestotheXDSMconvention.Afunctionnodecanhave multiple PSNs to allow for cycles. The maximum and minimum PSNspresentinagraphG aredenotedbyrespectivelymaxpsn

(

G

)

andminpsn

(

G

)

.

5.2. Edgedeﬁnitions

Twoedgetypesare deﬁned, calleddata andprocess edgeand belonging,respectively,tothetwomaingraphclasses

DataGraph

and

ProcessGraph

.

5.2.1. Dataedge(ed)

Thisedgerepresentstherelationbetweenavariablenodeand a function node. All dataedges in a graphare denoted by Ed

=

{

e

∈

E

|

cat

(

e

)

=

data

}

. A data edge is always deﬁned using one variablenodeandonefunctionnode.Ifter

(

ed

)

∈

Vf thentheedge isaninputedge and,viceversa,ifter

(

ed

)

∈

Vv thentheedgeisan

outputedge.

5.2.2. Processedge(ep)

Thisedge representstherelationbetweenfunction nodesina process graph. The subset of process edges in graph G is Ep

=

{

e

∈

E

|

cat

(

e

)

=

process

}

.Justlikefunctionnodes,theprocessedge canhaveaPSNattribute,denotedbypsn

(

e

)

.Forprocessedgesthe PSN is not an ordered set, buta single integer value, since each processedgecanonlyrepresentasinglestep(Fig.7b).

5.3. Maingraphclassesdeﬁnitions

Themain KADMOSgraphclasses

DataGraph

and

Process-Graph

(see class diagram inFig. 4), are deﬁned using thenode andedgedeﬁnitionsfromtheprevioussections.

Any instance of the

DataGraph

class is a digraph D

=

(

VD

,

ED

)

complyingtothefollowingconditions:

(9)

Table 1

List of attributes for graph nodes and edges.

Attribute name Notation Valid for Typical values

category cat() V∧E function, variable, data, process

subcategory sct() V input, coupling, collision, hole, sink (see Table2)

instance ins() V 0, 1, 2, 3

problem role pr() V design variable, objective, coupled, post-coupling architecture role ar() V initial guesses, copies, optimizer (see Table3)

mode mode() Vf viscous, inviscid, 1, 2, 3, A, B, C

process step number psn() Vf∧Ep {0,7},{1}for Vf or 1,2,3,4,5 for Ep

Fig. 6. Illustration

of the use of the attribute

mode.

Tool A can operate in two modes, using/producing different I/O values (right). Tool A is stored in the repository as one

tool (center), requiring only one mapping to the CDS accounting for both modes (center, left).

Fig. 7. Example instances for each of the two main graph classes in KADMOS.

(1)

|

Vf

|

+ |

Vv

|

= |

VD

|

(2)

|

Ed

|

= |

ED

|

Wherecondition(1)statesthatallnodesbelongtoeitherthe func-tion orvariable categoryandcondition(2)thatalledgesshouldbe dataedges,thusconnectingfunctionnodeswithvariablenodes,as showninFig.7a.

Instances of the

ProcessGraph

class are digraphs P

=

(

VP

,

EP

)

meetingthefollowingconditions:

(1)

|

Vf

|

= |

VP

|

(2)

|

Ep

|

= |

EP

|

(3)

∀

v

∈

VP

: δ

−

(

v

)

+ δ

+

(

v

)

≥

1 (4) minpsn

(

P

)

=

0 (5)

∀

e

∈

EP

:

psn

(

e

)

∈ Z

> (6)

∀

v

∈

VP

: |

psn

(

v

)

|

>

0

∧ ∀

i

∈

psn

(

v

)

:

i

∈ Z

≥ (7)

∀

e

∈

EP

:

psn

(

e

)

∈

psn

(

ter

(

e

))

(8)

∀

e

∈

EP

:

psn

(

init

(

e

))

x

|

x

<

psn

(

e

)

Where conditions (1) and (2) mean that all nodes should be functionnodesandalledgesshouldbeprocessedges,respectively. Condition(3)statesthateachnodeshouldbeconnectedtoatleast oneedgeandcondition(4)enforcestheprocessdeﬁnitiontostart ata PSNof zero.Conditions (5) and(6) ensure that all PSNsare positive integers,andonly nodescanhave aPSN ofzero.Finally, conditions (7) and (8) enforce process continuity by demanding thenodesaroundaprocessedgetohavecorrespondingPSNs(e.g. aprocessedge e withpsn

(

e

)

=

4 shouldhavean init(e)that con-tainsaPSNof3orlowerandater(e)containing aPSNof4).An exampleofaprocessgraphisshowninFig.7b.

5.4. Nodesubcategorization

A more refined subcategorization of all the nodes in a graph can be definedbased on their indegree, outdegree, and circular-ityindex. Thiscategorization can beinferred automatically based on these three properties. All possible subcategories, denoted by sct(v),are listed inTable 2. The subcategoriesplay an important role inthe differentgraphclasses,assome subcategoriesare not allowedincertainstagesoftheMDAOsystem,whileothersrequire aspecifictreatmentinthegraphmanipulationalgorithms.For ex-ample, thehole andcollisionnode subcategories (also presentin thesyntax by Pateetal. [44]),are generallyconsidered problem-aticandneedtoberemovedorfixed.Acrucialnewsubcategoryin theKADMOSsyntaxisintroducedwiththecircularvariablenodes, which are relatedto the circularity index introduced in the pre-vious subsection.These nodesrequirea specific treatmentin the datagraphs,aswillbediscussedinSections6.2and7.

(10)

Table 2

Subcategory deﬁnition of graph nodes and references to example nodes.

cat sct δ− δ+ cir Fig.7a

variable hole 0 0 0 a

supplied input 0 1 0 b

supplied shared input 0 >1 0 c

output 1 0 0 d

collision >1 0 0 e

coupling/

pure circular coupling 1 1 01 fg shared coupling/

shared circular coupling 1 >1 01 hi collided coupling/

collided circular coupling >1 1 01 jk collided shared coupling/

collided shared circular coupling >1 >1 0≥1 ––

function hole 0 0 0 A

source 0 >0 0 B

sink >0 0 0 C

complete >0 >0 ≥0 D

6. KADMOSgraphs

Thefourgraphtypes(RCG,theFPG,theMDGandMPG) intro-ducedin Sect. 4 (Fig. 4), are subclasses of the two main classes discussed in the previous section. In this section we make use ofasimpleanalyticalMDAOproblemtoclarifythedetermination anduseofthesefourgraphclasses:theSellarproblem[48]. This problemcanbedescribed bythe followingtools,wherethetools indicated withD representthe actual disciplines, F the objective function,andGtheconstraints:

D [mode=1]

⇒

y1

=

c

· (

z21

+

x1

+

z2

−

0

.

2

·

y2

)

D [mode=2]

⇒

y2

=

c

· (

√

y1

+

z1

+

z2

)

F

⇒

f

=

x2₁

+

z2

+

y1

+

e−y2 G [mode=1]

⇒

g1

=

y1 3

.

16

−

1 G [mode=2]

⇒

g2

=

1

−

y2 24

.

0

TobetterillustratethedifferentKADMOSgraphs weassume here tostartwithabroadertoolrepository,where,next toD,FandG, thefollowingﬁveﬁctitioustoolsareadded:

A

⇒

b

=

f

(

a

)

B

⇒

b

=

f

(

b

)

;

z1

=

f

(

b

)

;

z2

=

f

(

b

)

C

⇒

c

=

f

(

b

)

E

⇒

y1

=

f

(

b

,

z1

,

z2

)

;

y2

=

f

(

b

,

z1

,

z2

)

H

⇒

x1

=

f

(

x0

)

Before theﬁrst graphinthe KADMOSapproach, theRCG,can be created,thetoolshavetobemadecompatibletoasingleCDSand storedinthetoolrepository,asillustratedinFigs.8aand8b.

6.1. Repositoryconnectivitygraph

TheRCGisaspeciﬁctypeofdatagraph(seeSect.5.3).TheRCG

R

= (

VR

,

ER

)

canbebuiltbycombiningthedatagraphsthat rep-resentindividualfunctions.Foreachuniquefunction/mode combi-nation i

∈

Ir storedinthetoolrepository Ir

= {

1

,

2

, . . . ,

m

}

a data graphcanbeconstructed:

Di

= (

VD,i,ED,i)

Fig. 8. Extended Sellar problem tool repository.

Wherethenodesare:

VD,i

=

vf,i

Vv,I,i

Vv,O,i

inwhich vf,irepresentsthefunctionnode, Vv,I,i areallthe vari-ablesfromtheCDSbasedontheinputﬁle,andVv,O,i containsall theoutputﬁlevariables.Theedgesof Diarethen:

ED,i

=

E−

(

vf,i)

E+

(

vf,i) where: E−

(

vf,i

)

= {(

vv

,

vf,i

)

|

vv

∈

Vv,I,i

}

E+

(

vf,i)

= {(

vf,i,vv)

|

vv

∈

Vv,O,i

}

The data graph of the tool D[1] ([1] denotes mode

(

D

)

=

1) is shown in Fig. 8c.The nodes andedges of the RCGcan be writ-tenas: VR

=

i∈Ir VD,i ER

=

i∈Ir ED,i

(11)

Fig. 9. RCG of the extended Sellar tool repository.

TheRCGshowninFig.9isautomaticallyinstantiatedby KAD-MOSbased on the Sellartool repository deﬁnedabove. After in-stantiation, thesubcategory ofthe nodes (Table 2) can be deter-minedtoinspectthegraph,leadingtotheidentiﬁcationofthefour mainnodesubcategoriesforeachvariablenode v,asillustratedin Fig.9legend:

•

inputwhen

δ

−

(

v

)

=

0

∧ δ

+

(

v

)

>

0

•

outputwhen

δ

−

(

v

)

=

1

∧ δ

+

(

v

)

=

0

•

coupledwhen

δ

−

(

v

)

=

1

∧ δ

+

(

v

)

≥

1

∧

cir

(

v

)

=

0

•

problematicforallothernodes

These main node subcategories will be further discussed in the nextsection.NotethatforallnodesinanRCGins

(

v

)

=

0.

6.2.Fundamentalproblemgraph

The FPG contains the definition of the fundamental MDAO problemto be solved, thus it is a subset of the RCG, containing only the tools that are strictly necessary to solve the optimiza-tionproblemathand,plus extra informationonthe specific role ofthetools(whichoneisacoupleddiscipline,whichtheobjective function,etc.)andinvolvedvariables(which onesaredesign vari-ables,whichfixed parameters,etc.). TheFPG isthestarting point toimposeoneoftheMDAOarchitecturesinthethirdstageofthe formulationphase.

TheFPGhastomeetstricterrequirementsthantheRCG.In ad-ditiontothestandarddatagraphconditions,anFPG F

= (

VF

,

EF

)

hastomeetthefollowingextraconditions:

(1)

∀

v

∈

VF,f

:

v

∈

VR,f

∨

v is merged based on

⊆

VR,f

(2)

∀

v

∈

VF,v

:

v

∈

VR,v if ins

(

v

)

=

0, else

∃

w

∈

VR,v

:

w

=

v except ins

(

w

)

=

ins

(

v

)

∧

ins

(

w

)

=

0

(3)

∀

v

∈

VF,v

:

cir

(

v

)

=

0

∧ δ

−

(

v

)

+ δ

+

(

v

)

≥

1

∧ δ

−

(

v

)

≤

1 (4)

∀

v

∈

VF,f

: δ

−

(

v

)

≥

0

∧ δ

+

(

v

)

>

0

(5)

∀

v

∈

VF,f

:

pr

(

v

)

∈ {

uncoupled-DVI, uncoupled-DVD, coupled

,

post-coupling

}

(6)

∀

v

∈

VF,v

:

if pr

(

v

)

=

design variable

⇒ δ

−

(

v

)

=

0 (7)

∀

v

∈

VF,v

:

if pr

(

v

)

=

QOI

⇒ δ

−

(

v

)

=

1

(8)

∀

v

∈

VF,v

:

if pr

(

v

)

=

objective

∨

constraint

⇒ δ

+

(

v

)

=

0 (9)

∀

v

∈

VF

: ∃

path Q

= (

VQ

,

EQ

)

where v

∈

VQ

∧

VQ

w

where pr

(

w

)

∈ {

QOI, objective, constraint

}

Wherecondition(1)statesthatfunctionnodeshavetobepresent intheRCG alreadyorcan onlybe merged nodesbasedon func-tion nodes from the RCG. Condition (2) states that all variables shouldalsobepresentintheRCGorcanonlybeinstancesofRCG variables.Condition(3)impliesthatthevariablescannotbeholes,

Algorithm 1. FPG composition process.

1. M: Anticipate whether the MDAO architecture to be imposed is of type MDA, DOE or MDO.

2. M: Mark problem roles of variables based on the type of MDAO architec-ture:

a: If architecture type =MDO or DOE, then mark design variables. b: If architecture type =MDO, then mark objective.

c: If architecture type =MDO, then mark constraints. d: Mark QOIs for all architecture types.

3. M: Solve problematic nodes based on conditions (3) and (4). 4. A: Check graph validity based on all conditions except condition (5). 5. M: Merge functions to compress graphs.

6. A: Assign problem roles of functions (condition (5)). 7. A: Specify execution sequence.

8. A: For distributed MDO architectures, specify the distribution of the cou-pled functions.

Legend A: automated step

M: manual step using scripting commands

collided,orcircular.Condition(4)demandsthatallfunctionnodes are ofsubcategory‘source’or ‘complete’.Both conditions (3) and (4)arerelatedtothesubcategorieslistedinTable2.Condition(5) states that all function nodes in the graph should have a prob-lem role assigned (these roles will be further discussed later in thissection).Condition(6) stipulatesthat designvariablesshould be inputs, whereas QOIs can be couplings or outputs (condition (7)), andobjectiveandconstraint nodesmust be outputs (condi-tion(8)).Finally,condition(9)demandsthat,forallnodes,atleast one path can be created that leads to a QOI, objective, or con-straint. Hence, nodes not included in anyof those paths can be removed.

WhiletheRCGcan bedefinedbyKADMOS infullautomation, onthesolebasisofthetoolrepository,theFPGgraphisdefinedon thebasisofthedesignteamspecificationoftheMDAOproblemto be solved (e.g.what is theobjective? what arethe constraints?). Several support functionsare provided by KADMOS to assist the design team in the FPG composition process. A suggested semi-automatic composition process for crafting the FPG is given in Algorithm1.

The FPG composition process for the Sellar problem is illus-trated in Fig.10. Thisprocess starts fromthe RCGin Fig. 9.The anticipated architecture type (step 1) is MDO.In step 2(refer to Fig.10a)x0,z1,andz2 aremarkedasdesignvariables.Inorderto make z1 andz2 validdesign variablestheincomingedges

(

B

,

z1

)

and

(

B

,

z2

)

mustbe removed. Theobjective f and constraints g1 and g2 candirectlybe markedassuch,sincethesearealreadyof the valid subcategoryoutput. Finally, ifthe design team is inter-ested inkeepingtrackofthecouplingvariable y2,thishastobe deﬁnedasaQOI.Therefore,thepreferredfunctiontodeterminey2 hasto beselected (betweentool DandE).Inthiscase, tool Dis selected,alsoforthevariable y1,thustheedges

(

E

,

y1

)

and

(

E

,

y2

)

areremoved.

The onlyproblematic nodesleft inthegraph(step 3) aretool Eandvariableb.Afterthepreviousedgeremoval,toolEisnowa sinkandcansafelyberemoved fromthegraph.Nodeb expresses

aspecialcase,inwhichatool takesan initialvalueandthen up-dates that same value. Hence, theinput andoutput point to the samelocationoftheschema.Thisiscommonpracticeforsystems using a CDS approach, when toolstake initial guesses orupdate thevalues(e.g.awinggeometry)storedinaschemaﬁle.Thistype ofnodeismadevalidbysplittingitintwoinstancesusinga KAD-MOSmethodresultinginb (ins

(

b

)

=

0)andbi1_(ins

₍

_b

₎

₌

_1)._Hence, thisisthemomentwhennodeinstancesarecreated.Thesplitting ofnodes isa crucialoperation, sincenot every collided or circu-larnodeinthedatagraphcan besolved byjustremovingedges. Inrealisticdesigncases,collisions andloopedpairsarecommonly present,aswillbefurtherdiscussedinSect.7casestudy.Fig.10b

(12)

Fig. 10. Sellar problem FPG composition.

depicts the FPG of the Sellarproblem after the executionof the previoussteps.

In step4 aKADMOS check methodisexecuted which returns a positive result.Then the teamcan mergefunctionsthatbelong together andthat can be executed in sequence (i.e. without any feedbackcoupling)orinparallel(i.e.withoutanycoupling).Hence, in step 5the function sequence

A

,

B

,

C

is mergedas one func-tionABC,andthesetofparallelfunctions

{

G[1]

,

G[2]

}

ismergedas G[1,2]. See Fig.10cforthe resultinggraph.Thesefunction merg-ersareusefultodeclutterthesystem(andmaintainoversight)by clusteringmoredisciplinesintofewer“macro-discipline”blocks.

Step6oftheFPGcompositionprocessconsistsinthe determi-nation of theproblemrole ofthe variousfunctions. The function problem roles in an FPG belong to one of four main groups: uncoupled-DVI,uncoupled-DVD,coupled,andpost-coupling,where thesuﬃxofthetwouncoupledtypesindicateswhetherthe func-tions are Design Variable Dependent (DVD) or Design Variable Independent (DVI).Thecoupledfunctionsarethesetoffunctions that are involved incycles inthe FPG. Thesecycles indicatethat a method is requiredto convergethe system, since any orderof executing the tools will always require some feedback loop. The singlecyclepresentintheSellarFPGisdepictedinFig.10c.Hence, tools D[1] andD[2] havethe problemrole ‘coupled’. The uncou-pled functions are all the functions on an incoming path with respect to the cycles, for examplethe function ABC on the path

{

a

,

ABC

,

c

,

D[1]

}

.Thedefaultproblemrole foruncoupledfunctions is uncoupled-DVI. However, if the FPG contains design variables, then some of the uncoupled functions could also be DVD and shouldbemarkedassuch,seetoolHinthisexample.This distinc-tionisrequiredlatertocorrectlypositiontheuncoupledfunctions eitheroutside(if DVI)orinside (ifDVD) themaincyclehandling design variables (i.e. DOE or optimizerblock). The post-coupling functionsaresimplyalltheremainingfunctions.Theproblemroles areshowninFig.10d.

In step 7 the description of the fundamental MDAO problem iscompleted byspecifyingthesequenceofthefunctions. The se-quences for each problem role are determined automatically in KADMOS.Theuncoupledandpost-couplingsequencesare straight-forward, since no cycles are present in those function sets. Any sequence of functions that constitutes a topological order of the nodes isvalid, whereforthe uncoupled functionsthe most opti-malsequenceisasequencewheretheDVDfunctionsarerequired aslateaspossible,hence

ABC

,

H

.Thesequencingofthecoupled functionsismorechallengingastheamountoffeedbackvariables can depend on the sequence given. For thispurpose, sequencing algorithms have been implemented that search for the optimal sequence byminimizing theamountoffeedbackcouplings. How-ever,fortheSellarproblembothpossiblesequenceshavethesame amount offeedbackvariables,thus thesequence

D[1]

,

D[2]

was arbitrarilyselected.Thepost-couplingsequenceissetto

F

,

G[1,2]

. If a distributed MDO architecture needs to be implemented, then thecoupledfunctionsinthe FPGneed tobe groupedto in-dicate howthesystemneeds tobedistributed.Thisgroupingcan bedeterminedautomaticallyusingpartitioningalgorithms,suchas the Metis partitioning algorithm [32] implemented in KADMOS. In the small Sellar example, the two groups are simply the two coupledfunctions.TheotherfunctionsintheFPGwillbegrouped automatically whenthe distributedMDOarchitecture is imposed, asfurtherdiscussedinSect.6.6.TheFPGinFig.10dhasbeen de-ﬁned withthe MDOarchitecture typesinmind,butitispossible tousenearlythesameFPGalsoforMDAandDOEbysimply reas-signingvariableproblemrolesbasedonstep2ofAlgorithm1.