Fuse tight composer

Sriram, between our discussion and this summary I understand this problem. Also, the description of the algorithm is more detailed than what you have in the comments, so you should include it there.

Greg Bronevetsky
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky@llnl.gov<mailto:bronevetsky@llnl.gov>
http://greg.bronevetsky.com

From: Sriram Aananthakrishnan [mailto:notifications@github.com]
Sent: Friday, June 27, 2014 11:35 AM
To: sriram87/edg4x-rose
Cc: bronevet
Subject: Re: [edg4x-rose] Fuse tight composer (#4)


In projects/fuse/src/analysis/tight_composer.C:

> +    boost::shared_ptr<AnalysisMapAOType> amAO_p = boost::make_shared<AnalysisMapAOType>();

> +    list<ComposedAnalysis*>::iterator a = allAnalyses.begin();

> +    list<Expr2AnyKey>::iterator qIt;

> +    list<boost::shared_ptr<AOType> > aopList;

> +

> +    // Dispatch queries to each analysis

> +    for( ; a != allAnalyses.end(); ++a) {

> +      if(implementsExpr2AnyOp(*a)) {

> +        aopList.clear();

> +        for(qIt = queryList.begin(); qIt != queryList.end(); ++qIt) {

> +          Expr2AnyKey query = *qIt;

> +          // Transition this query to analysis state corresponding to *a

> +          tcqm.transToAnalState(query, *a);

> +          // dispatch the query to the analysis

> +          boost::shared_ptr<AOType> ao_p = Expr2AnyOp(*a, query.sgn, query.pedge);

> +          // Add it to the list

@bronevet<https://github.com/bronevet>
Greg
The idea behind this method is the following. All queries Expr2any or OperandExpr2Any queries to the TightComposer are translated into list of queries. List of queries because different part edges from getOperandPartEdge. We get a list of queries as input this method. The queries are also marshaled simultaneously into different query states. The different query states are init, analysis (when the query has been dispatched to an analysis) and finish. The list of queries are checked for if they are recurrent. Note that queries are marshaled simultaneously. So even if one of them create a cycle by forwarding the query back to the composer, all of them would be in the same state. If the queries are recurrent Full object is returned. If not the queries are all initialized and dispatched to individual analysis. So at line 189, you can see that the analysis' Expr2Any method is invoked. We dispatch the query for each analysis and for each PartEdge and for each analysis the results a re combi ned using Union/Intersect objects. Finally these Union/Intersect objects are added to Mapped abstract objects corresponding to each analysis. This collection is a simply a list. We discussed last week as to why a list would be sufficient. The only problem though is that the line 189 can return Full objects which means the list will be not be aligned and we cannot do indexed item comparison (i.e., first item with first item etc.) We should not be storing any Full objects in this list. However the two list objects will contain the abstract objects from the same analysis. The change we have to do is to replace the indexed item comparison with item by item comparison. This will square the complexity but can be useful.

What do you think?

—
Reply to this email directly or view it on GitHub<https://github.com/sriram87/edg4x-rose/pull/4/files#r14307948>.