Modeling Analyses

New to SMTK 3.1 - Hierarchical Analyses.

When modeling simulation information in SMTK, you can associate a set of categories (currently a category is represented simply as a string) with each attribute item. This information can then be used to filter the information when it is being displayed. For example an item could belong to both the Heat Transfer and CFD categories and will be displayed if category filtering is off or if either the Heat Transfer or CFD categories is active.

An analysis is represented as a collection of categories.
For example in Truchas (an open source 3D Multiphysics Simulation code for Metal Casting and Processing) the user can perform a Heat Transfer simulation that can optionally involve Induction Heating and or Enclosure Radiation. Prior to 3.1 the only way to was to define 4 analyses:

  • Heat Transfer
  • Heat Transfer with Induction Heating
  • Heat Transfer with Enclosure Radiation
  • Heat Transfer with Both Induction Heating and Enclosure Raditation

This can become intractable when dealing with a large number of combinations. In the case of Truchas, in additional to Heat Transfer, the engineer can also include CFD and Solid Mechanics resulting in 19 possible combinations.

In order to make modeling analyses simpler, in SMTK 3.1 you can define analysis hierarchies. So for example Enclosure Radiation could be “derived” from Heat Transfer. This means that Enclosure Radiation includes all of the categories associated with Heat Transfer plus those explicitly associated with Enclosure Radiation. Below shows an example XML snippet from the Truchas template file:

  <Analyses>
    <Analysis Type="Heat Transfer">
      <Cat>Heat Transfer</Cat>
    </Analysis>
    <Analysis Type="Enclosure Radiation" BaseType="Heat Transfer">
      <Cat>Enclosure Radiation</Cat>
    </Analysis>
    <Analysis Type="Induction Heating" BaseType="Heat Transfer">
      <Cat>Induction Heating</Cat>
    </Analysis>
    <Analysis Type="Fluid Flow">
      <Cat>Fluid Flow</Cat>
    </Analysis>
    <Analysis Type="Solid Mechanics">
      <Cat>Solid Mechanics</Cat>
    </Analysis>
  </Analyses>

Analysis View

A new View has been created to display Analysis information and to control how categories get processed. Prior to SMTK 3.1, all of the categories that were defined in the SBT template file were available for information filtering. In addition, if there were several different analyses that could be defined in the template, the user would typically need to choose the specific analysis during export time. This can lead to some confusion. For example in the case of Truchas, a user would be able to see information related to CFD even if the analysis being defined was going to only involve Heat Transfer.

In order to address this situation, the new Analysis View presents the user with the hierarchy of analyses and the user can then indicate which analyses they wish to model. Once this is done, only the categories related to the analyses selected will be available in the category list. In addition, if explicit category filtering is disabled, only information that has at least one of its categories in the list will be displayed. In the previous example, if Heat Transfer is the only analysis selected then only items categorized as Heat Transfer would be visible. If the user also selected Enclosure Radiation the items that belonged to either Heat Transfer or Enclosure Radiation would be displayed. In addition, the user no longer needs to specify which analyses are being performed during export since the export operation can now access this information from the Analysis attribute created by the Analysis View.

Proposed New Features - Exclusive Analyses

The current implementation assumes that any combination of the top level analyses (or their children) are valid. If on the other hand you wanted to support a workflow where only one in the top level (or children analyses under a parent) was supported, this would not be possible.

What I propose is to add the concept of Exclusive - so for example if you wanted to support optionally either Induction Heating or Enclosure Radiation (but not both) you could use the Exclusive option on the Heat Transfer Analysis indicating only one of its children could be selected:

  <Analyses>
    <Analysis Type="Heat Transfer" Exclusive="true">
      <Cat>Heat Transfer</Cat>
    </Analysis>
    <Analysis Type="Enclosure Radiation" BaseType="Heat Transfer">
      <Cat>Enclosure Radiation</Cat>
    </Analysis>
    <Analysis Type="Induction Heating" BaseType="Heat Transfer">
      <Cat>Induction Heating</Cat>
    </Analysis>
    <Analysis Type="Fluid Flow">
      <Cat>Fluid Flow</Cat>
    </Analysis>
    <Analysis Type="Solid Mechanics">
      <Cat>Solid Mechanics</Cat>
    </Analysis>
  </Analyses>

In addition to state that the top level analyses are Exclusive with respects to each other you do the following:

  <Analyses Exclusive="true">
    <Analysis Type="Heat Transfer" Exclusive="true">
      <Cat>Heat Transfer</Cat>
    </Analysis>
    <Analysis Type="Enclosure Radiation" BaseType="Heat Transfer">
      <Cat>Enclosure Radiation</Cat>
    </Analysis>
    <Analysis Type="Induction Heating" BaseType="Heat Transfer">
      <Cat>Induction Heating</Cat>
    </Analysis>
    <Analysis Type="Fluid Flow">
      <Cat>Fluid Flow</Cat>
    </Analysis>
    <Analysis Type="Solid Mechanics">
      <Cat>Solid Mechanics</Cat>
    </Analysis>
  </Analyses>

To make defining heirachrical analyses easier and cleaner is it possible to allow Analyses to be nested in the same way that ItemDefinitions are nested in Group Items?

For example, using the use-case you specified here with some additions (in bold):

that would currently translate to:

  <Analyses>
    <Analysis Type="Heat Transfer">
      <Cat>Heat Transfer</Cat>
    </Analysis>
    <Analysis Type="EnclosureRadiationHeatTransfer" 
              Label="Enclosure Radiation" BaseType="Heat Transfer">
      <Cat>Enclosure Radiation</Cat>
    </Analysis>
    <Analysis Type="InductionHeatingHeatTransfer"
              Label="Induction Heating" BaseType="Heat Transfer">
      <Cat>Induction Heating</Cat>
    </Analysis>
    <Analysis Type="Fluid Flow">
      <Cat>Fluid Flow</Cat>
    </Analysis>
    <Analysis Type="EnclosureRadiationFluidFlow" 
              Label="Enclosure Radiation" BaseType="Fluid Flow">
      <Cat>Enclosure Radiation</Cat>
    </Analysis>
    <Analysis Type="InductionHeatingFluidFlow"
              Label="Induction Heating" BaseType="Fluid Flow">
      <Cat>Induction Heating</Cat>
    </Analysis>
  </Analyses>

As you can see the sub Analysis names get very long fast. For a more complex Analysis hierarchy it would be a nightmare.

However, if we can apply the same conventions to Analyses definitions that we already apply to Group item definitions we can instead translate the example Analysis hierarchy to:

  <Analyses>
    <Analysis Type="Heat Transfer">
      <Cat>Heat Transfer</Cat>
       <Analysis Type="Enclosure Radiation">
         <Cat>Enclosure Radiation</Cat>
       </Analysis>
       <Analysis Type="Induction Heating">
         <Cat>Induction Heating</Cat>
       </Analysis>
    </Analysis>
    <Analysis Type="Fluid Flow">
      <Cat>Fluid Flow</Cat>
       <Analysis Type="Enclosure Radiation">
         <Cat>Enclosure Radiation</Cat>
       </Analysis>
       <Analysis Type="Induction Heating">
         <Cat>Induction Heating</Cat>
       </Analysis>
    </Analysis>
  </Analyses>

Using this style will not only shorten type names but it will also remove the need to specify BaseType and make the code easier to read and understand at a glance which will reduce the chances of making mistakes.

@Bob_Obara @johnt what do you guys think?

Another thought that comes to mind is that the proposed tree style Analysis Model will enable us to provide an easier method for specifying default Configurations that a developer might want to include with their SBT.

Currently to do that we need to first read in the SBT so that the Analysis Model is translated into an AttDef that we then instantiate to make the required default Configs, export as xml, and finally copy/past into the sbt.

This is not only a lengthy process for default Config creation but also makes it a hassle to update default configs after making changes to the Analyses model.

Instead we can specify default configs like this: (assuming the Analysis Model from my previous post)

  <Configs>
    <Config Name="DefaultConfig1" AdvanceWriteLevel="1" AdvanceReadLevel="0">
      <AnalysisType= "Heat Transfer">
        <AnalysisType= "Enclosure Radiation"/>
      </AnalysisType>
      <AnalysisType= "Fluid Flow">
        <AnalysisType= "Induction Heating"/>
      </AnalysisType>
    </Config>
  </Configs>

This configuration will turn on ‘Heat Transfer’ along with its subanalysis ‘Enclosure Radiation’ and ‘Fluid Flow’ along with its subanalysis ‘Induction Heating’. Notice that I only have to specify the Analyses that I want on.

Another example would be if Heat Transfer and Fluid Flow were modeled as Exclusive Analyses:

  <Analyses>
    <Analysis Type="Simulation Type" Exclusive="True">
      <Analysis Type="Heat Transfer">
        <Cat>Heat Transfer</Cat>
         <Analysis Type="Enclosure Radiation">
           <Cat>Enclosure Radiation</Cat>
         </Analysis>
         <Analysis Type="Induction Heating">
           <Cat>Induction Heating</Cat>
         </Analysis>
      </Analysis>
      <Analysis Type="Fluid Flow">
        <Cat>Fluid Flow</Cat>
         <Analysis Type="Enclosure Radiation">
           <Cat>Enclosure Radiation</Cat>
         </Analysis>
         <Analysis Type="Induction Heating">
           <Cat>Induction Heating</Cat>
         </Analysis>
      </Analysis>
    </Analysis>
  </Analyses>

My default would look like this:

  <Configs>
    <Config Name="DefaultConfig1" AdvanceWriteLevel="1" AdvanceReadLevel="0">
      <AnalysisType= "Simulation Type">
        <AnalysisType= "Fluid Flow">
          <AnalysisType= "Induction Heating"/>
        </AnalysisType>
      </AnalysisType>
    </Config>
  </Configs>

If my Analysis Model updates I just need to make sure to make the necessary changes where needed in my Configs sections. That is relatively quicker and easier to do compared to the current method which requires us to go through the import -> creation -> export -> copy/past process all over again.

I’m the process of supporting Analysis Configurations and I would like to support both the current design of explicitly naming the analysis as well as having the name be computed based on the analysis path. So here are a couple of ideas as to how the format would look:

This one assumes that the analysis names are unique.

<Configurations AnalysisAttributeType="Analysis">
  <Config Name="C1">
    <Analysis Type="A1"/>
    <Analysis Type="A2">
      <Analysis Type="A2B1"/>
    </Analysis>
  </Config>
</Configurations>

This one specifies that the analysis names are relative.

<Configurations AnalysisAttributeType="Analysis">
  <Config Name="C1" Specification="Relative">
    <Analysis Type="A1"/>
    <Analysis Type="A2">
      <Analysis Type="B1"/>
    </Analysis>
  </Config>
</Configurations>

That looks really good!

Are you also planning on adding support for AdvanceLevel specfication?

For example:

<Configurations>
  <Config Name="C1" 
    Specification="Relative" 
    AdvanceWriteLevel="2" 
    AdvanceReadLevel="1">
    <Analysis Type="A1"/>
    <Analysis Type="A2">
      <Analysis Type="B1"/>
    </Analysis>
  </Config>
</Configurations>