Hierarchical Engineering Models for Solver Integration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Commercial Off-The-Shelf (COTS) and open-source packages often present challenges for engineers due to differences in language and syntax, steep learning curves, vendor lock-in, and inefficient integration across software environments, lacking high-level abstractions that align with engineering systems.

Innovation Solution

A declarative object-oriented system is developed to mathematically describe hierarchical physical and engineering systems, allowing engineers to define components and relationships intuitively, with runtime processing to interface with various solvers and maintain model consistency, reducing the need for rewriting code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Power

If COTS packages are used, then numerical algorithms are provided efficiently, but the user interface and algorithm interaction do not align with HPES structure

Engineering Contradiction:
Improvealgorithm efficiencyVSAvoiduser interface alignment with HPES
Core Design Contradiction:
PowerVSEase of operation

Solution Approach 1:

The patent introduces a translation layer that acts as an intermediary between the user's HPES model and the COTS package's internal data structures. This layer automatically translates between the hierarchical physics-based representation and the package-specific formats, eliminating the need for manual translation while preserving both the efficiency of COTS algorithms and the intuitiveness of HPES modeling.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system creates a universal interface that can interact with multiple different COTS packages through a common HPES abstraction layer. This allows the same user-friendly HPES syntax to work with different backend packages (e.g., FEAST, MOOSE, custom solvers), making the interface universally applicable across various numerical methods and packages.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If COTS packages are learned and code is developed within their ecosystem, then specific framework performance is achieved, but vendor lock-in creates barriers to switching or integrating solutions

Engineering Contradiction:
Improveframework performanceVSAvoidswitching between packages
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system segments the computational workflow into distinct independent components: the HPES model definition layer, the translation layer, and the backend solver layer. This segmentation allows users to switch between different COTS packages by simply changing the backend layer without affecting the model definition or requiring code rewriting, thereby eliminating vendor lock-in while maintaining framework performance.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of requiring users to rewrite code when switching packages, the system creates a virtual copy of the package interface through the translation layer. This virtual copy maintains the same HPES API regardless of the underlying actual package, allowing seamless switching between different implementations without code changes.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If engineers translate their HPES understanding into generic data structures, then COTS package functionality is achieved, but cognitive load and complexity increase

Engineering Contradiction:
Improvepackage functionality accessVSAvoidtranslation complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The translation layer performs self-service by automatically handling the translation between HPES and COTS package formats without requiring user intervention. The system analyzes the HPES model structure and automatically generates the necessary translations, eliminating the cognitive burden of manual translation while maintaining access to package functionality.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS20250370735A1Defining hierarchical engineering systems
Publication Date: 2025.12.04 SRI INTERNATIONAL
  • US20250370735A1 patent drawing
  • US20250370735A1 patent drawing
  • US20250370735A1 patent drawing

AI summary

In an example, a method for solving problems involving a Hierarchical Physical and/or Engineering System (HPES) includes: receiving, by a computing system, a declarative object-oriented definition of the HPES having one or more sub-systems and/or one or more components; receiving, by the computing system, a definition of a first problem to be solved, wherein the first problem comprises at least one of: an optimization problem or an inverse problem; processing, by the computing system, the declarative object-oriented definition of the HPES to generate a data structure representing relationships and interactions between the one or more subsystems and/or the one or more components of the HPES; transpiling, by the computing system, a first optimized code using the data structure, the declarative object-oriented definition and the definition of the first problem; and generating, by the computing system, a solution to the first problem by executing the first optimized code.