Greedy volume mesh updates under large design changes in computer-aided engineering (CAE) tools

The CAE computing system addresses inefficiencies in mesh updates by maintaining a morphed volume mesh model and aggregating updates, improving simulation efficiency and reducing development time for complex designs.

WO2026035274A1PCT designated stage Publication Date: 2026-02-12SIEMENS CORP
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/US2024/041602
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-08-09
Publication Date
2026-02-12

AI Technical Summary

Technical Problem

Current CAE automation methods are inefficient, consuming significant time and resources for mesh updates, especially with complex geometries, and are limited in handling multiple design changes, hindering the exploration of design space.

Method used

A CAE computing system that maintains a morphed volume mesh model in memory, updating it incrementally with each design change, and aggregates updates when appropriate to reduce complexity and processing time, using a greedy approach.

Benefits of technology

Enhances simulation efficiency and reduces product development time by maintaining a simulatable digital twin of the design model, allowing smooth iteration and efficient handling of multiple design changes without losing design history.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2024041602_12022026_PF_FP_ABST
    Figure US2024041602_12022026_PF_FP_ABST
Patent Text Reader

Abstract

Current approaches to computer-aided engineering (CAE) automation are often inefficient. For example, automated workflows often consume significant amounts of time and processing resources, among other resources. A CAE computing system can perform various operations to enable efficient simulations of an object or product during the design phase of the object of product.
Need to check novelty before this filing date? Find Prior Art

Description

202318572GREEDY VOLUME MESH UPDATES UNDER LARGE DESIGN CHANGES IN COMPUTER-AIDED ENGINEERING (CAE) TOOLSSTATEMENT OF GOVERNMENT RIGHTS

[0001] This invention was made with government support under contract number FA8750-20- C-0542 awarded by Defense Advanced Research Projects Agency (DARPA). The government has certain rights in this invention.BACKGROUND

[0002] Designing, exploring, and optimizing complex engineering parts presents various difficult technical challenges. Original equipment manufacturers (OEMs) can push their 3- dimensional part performance by running accurate simulations, so as to explore the design space of the part or component. In some cases, it is recognized herein that every instance of the design space requires a high-quality volume mesh as input for the corresponding Computer-aided engineering (CAE) analysis. Furthermore, various partial differential equation (PDE) methods require a mesh, such as finite elements, finite volumes, and volume of fluids, among others).

[0003] In some cases, products with different geometries can be ranked by CAE analysis. For example, designers / analysts can iterate many times between geometric design changes and simulations to reach product or component requirements. These iterations have been the focus of CAE automation. It is recognized herein, however, that current approaches to CAE automation are often inefficient. For example, automated workflows often consume significant amounts of time and processing resources, among other resources.BRIEF SUMMARY

[0004] Embodiments of the invention address and overcome one or more of the described-herein shortcomings or technical problems by providing methods, systems, and apparatuses for enhancing the generation of computer-aided engineering (CAE) meshed surfaces within CAE tools, so as to decrease product development time and enhance the user experience associated with various tools.

[0005] In an example aspect, a CAE computing system described herein can perform various operations to enable efficient simulations of an object or product during the design phase of the202318572 object of product. For example, the CAE computing system can obtain and display an initial model(e.g., CAD model) representative of a physical object, during a design phase of the physical object. The physical object can define an outer surface and an interior structure opposite the outer surface. The system can generate a volume mesh model from the initial model. The volume mesh model can define a representation of the interior structure of the physical object. During the design phase, the system can make and display a first design update to the initial model, so as to define a first design update to the initial model. The design updates can be responsive to a user making a change to the model via a user interface of the system. In response to the first design update, the system can perform a first update to the volume mesh model, so as to generate a morphed volume mesh model. The system can save the morphed volume mesh model in memory. In various examples, during the design phase, the system can make a plurality of consecutive design updates to the first design model, so as to define an updated design model. After each design update of the plurality of consecutive design updates, the system can perform a respective mesh update to the morphed volume mesh model corresponding to the respective design update, so as to iteratively generate an updated morphed volume mesh model. The system can save the respective updated morphed volume mesh model in memory.

[0006] At any time during the design phase, the system can retrieve the updated morphed volume mesh model from memory, so as to define a retrieved current morphed volume mesh model, and perform a simulation of the physical object using the retrieved current morphed volume mesh model. In some examples, the system can determine whether a subset of the plurality of consecutive design updates can be aggregated into a single mesh update of the morphed volume mesh model. For example, in cases in which mesh morphing of the aggregated updates is more robust (mesh morphing is less difficult to resolve) as compared to individual updates, the system aggregates the subset of design updates. When the subset can be aggregated, the system can tag the design updates in the subset as aggregated design updates, and add the aggregated design updates to a feature tree stored in the memory.BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0007] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the invention, there is shown in the drawings embodiments that are presently202318572 preferred, it being understood, however, that the invention is not limited to the specific instrumentalities disclosed. Included in the drawings are the following Figures:

[0008] FIG. 1 shows example operations that can be performed by a computer-aided engineering (CAE) computing system, in accordance with an example embodiment.

[0009] FIG. 2 shows an example design model that is updated, resulting in a corresponding update to a volume mesh model, in accordance with an example embodiment.

[0010] FIG. 3 illustrates a computing environment within which embodiments of the disclosure may be implemented.DETAILED DESCRIPTION

[0011] It is recognized herein that current approaches to making design changes in a computer- aided design (CAD) model require that mesh updates are propagated to a computer-aided engineering (CAE) tool. It is further recognized herein that, in particular for complex geometries, such updates take a substantial amount of time, which can result in CAE tool partial nonresponsiveness and an increase in part development time, among other technical issues.

[0012] By way of background, it is recognized herein that some current approaches involve volume mesh morphing algorithms, such as free-form deformations (FFD) and radial basis functions (RBF), which mainly target situations where meshes are deformed, thereby directly skipping a geometrical parametrization step. Example situations for such volume mesh morphing include flowstructure co-simulation scenarios, wherein in each time step the fluid and mechanical structure mesh needs to be deformed according to the dynamical behavior of the entire system. It is recognized herein that these techniques (e.g., FFD, RBF) have technical drawbacks when applied to various design and simulation workflows within CAE tools. In particular, for example, the allowable geometrical variation across part instances for achieving decent quality meshes is limited to reduce geometrical changes, which hinders the size of the design space that can be explored within the CAE tool. By way of further example, these morphing techniques are exposed in CAE tools for one design change rather than a sequence of design changes. But it is recognized herein that completing multiple design changes before the CAE solution is requested is a more common scenario than requesting the CAE solution after each design change.202318572

[0013] Thus, current approaches to design changes in CAD models are inefficient. For example, current solutions are often incapable of handling the kinds of significant geometric variation that is common in the early and middle stages of design (and increasingly in later stages due to generative mechanisms and the like). Additionally, or alternatively, current approaches can typically only handle one kind of variation at a time, precluding the kinds of drastic alterations that are common in modem design systems and methods.

[0014] In accordance with various embodiments described herein, a CAE computing system can support simulations for designs at various stages of the design process. In particular, the system can compute a volumetric mesh or volume mesh model that can be used in simulations. Volumetric mesh model, volume mesh, solid mesh, and variations thereof can be used interchangeably herein without limitation, unless otherwise specified. For example, the system can obtain an initial model of various mechanical or physical objects. The initial model might define a boundary representation (B-rep) or other CAD model that is not suited for simulations such as finite element analysis. Thus, the system can compute and generate a volumetric or solid mesh of the initial model of the object, so as to define a surface and interior structure of the object that can be used in a finite element analysis or otherwise simulated. The initial model can be updated or changed iteratively, so as to define a design model. In an example, when a user of the system makes a design change to, or updates, the model of the object, the system can morph the volume mesh of the model, so as to define a morphed volume or volumetric mesh model. [[Inventors, can you prove a specific example (perhaps with reference to a drawing) of a design change that is reflected in a morphed volume mesh, and an example of a simulation that can be performed more efficiently during the design phase using the morphed volume mesh rather than reconstructing the volume mesh?]]

[0015] Thus, rather than reconstructing the volume mesh each time a user wants to see a new simulation, the morphed volume mesh is maintained in memory of the system so as to define a simulatable digital twin of the design model. The system can morph the volume mesh corresponding to each design change or update to the design model. In some examples, when a user applies a change to a CAD (design) model, for instance by actuating an apply or save option via a user interface of the computing system, a corresponding update to a volume mesh model is triggered. In particular, for example, the system can retrieve a volume mesh from a tree, and update and save the retrieved volume mesh in accordance with the update that is made to the associated CAD model.

[0016] By way of example, a CAD system collects and stores CAD operations (such as creating a sketch, extruding a profile, drilling a hole, or joining two bodies, etc.) in a feature tree. The feature202318572 tree can define a visual representation of the design process in CAD software, so as to organize and display the sequence of operations or features used to create a 3D design model. A feature can include creating a hole, adding a fillet, extruding a shape, or the like, among other things. The feature tree can show the order in which these operations are applied, and how they relate to each other. The feature tree can enable an engineer or CAD software user to modify and edit their designs. For example, if a user wants to change the dimensions of a hole, the user can locate the corresponding feature in the tree and make the necessary adjustments. The changes can then propagate through the model, updating all dependent features.[00171 In accordance with various embodiments, the system keeps track of the mesh model and morphs the mesh model each time a new CAD operation is performed. By keeping track of the mesh model and morphing it each time a new CAD operation is performed, generating a complicated mesh model from scratch is avoided. Rather, the mesh model is updated each time an update or change is made to the associated design (CAD) model. Thus, a mesh model can be updated incrementally. Such updates often define relatively small or local changes to the current valid mesh model, as each mesh update corresponds to a single CAD operation performed on the geometry of the design model since the previous mesh update. By way of further example, and without limitation, the design model can define a parametric surface, a constructive solid geometry (CSG) model, surface mesh regions, or the like. Thus, embodiments can define a greedy approach, in which changes to a volumetric mesh occur in small increments. For example, the volume mesh might only change each time it is morphed to account for a single design change per change or iteration.

[0018] As described above, the system can access the morphed volume mesh to perform simulations of the object represented by the design model, using the morphed volume mesh corresponding to the design model. In various examples, the behavior of interest for a design can be simulated, using the associated morphed volume mesh, at any, for instance every, point along the path of the design. The system can also store the volumetric mesh model updates alongside CAD information such as, for example, the geometric operations used to define and change the shape throughout the design process. Such CAD information can enable smooth undo and redo, and can enable comparison of alternates across different model branches or history entries in a model branch. This is because, for example, the CAD feature tree information stored in a CAD system can be sufficient to fully reconstruct the model geometry step-by-step as it was designed by the user. By storing snapshots or differences between mesh models along with the CAD feature tree information,202318572 in accordance with various embodiments, the system or a user can step forward or backward to different design states, not only in the CAD geometry but in the mesh model as well.

[0019] It is recognized herein that the greedy approach described herein might trigger unneeded local changes to a volume mesh in situations where there are a series of updates to a CAD model that are better suited for addressing in the aggregate with a single regional update. To address these potential situations, the system defines an design update aggregator configured to monitor updates that are made to the design model. Based on the monitoring, the update aggregator can determine when a volume mesh morph can cover multiple updates while reducing the complexity final volume mesh without reducing the accuracy of the volume mesh.[0(120] By way of example, an error threshold or term can be defined based on the design model and the precision of the CAD system. In some cases, an operation is merged with another, so as to define an aggregated set, when the difference (error) in merging the operations as compared to not merging the operations is less than the error threshold. By way of further example, users might change same the setting of a given feature multiple times. For example, the length of an extrusion is first changed to 5 mm and it is followed by, or after a few design updates, another change to 5.5 mm. Each of those changes might not trigger volume mesh updates or morphing because the update aggregator can determine that aggregate the corresponding volume mesh updates related to the change in the extrusion.

[0021] In particular, the update aggregator can monitor a maximum number of chronological update steps, which can be predetermined or set by a user, to determine whether a single volume mesh morph can cover those number of chronological updates. In some examples, the maximum number of chronological updates that can be aggregated is set to three, although it will be understood that the system can aggregate additional or an alternative number of updates, and all such numbers of updates that can be aggregated are contemplated as being within the scope of this disclosure. In various examples, the system performs such aggregation during slow times for the processing hardware of the system, for instance between CAD updates or changes, or when simulation results are being viewed by the user. When the system determines that volume mesh can be morphed so as to include multiple aggregated updates to the design model, the update aggregator can tag the aggregated updates and add the new aggregation updates to the feature tree. Such an aggregated update to the volume mesh model can, in some cases, prevent breaking the history of the volume mesh model while updating it to a more efficient form. Breaking the history of the model can result in an inability to get back to a particular state. For example, if two operations are squashed into one202318572 mesh update, and the user wants to go back to the state of the model inside that squashed commit, but that model snapshot does not exist. Thus, in some cases, two updates (or more) that are squashed into one might not actually communicate. In particular, for example, one update might be to the far left edge of the model and the other update might be to the far right edge, such that the two updates do not affect each other. In such a case, squashing those two updates does not result in a negative effect, because there is no difference in which one of them gets done first.

[0022] Referring now to FIG. 1, the CAE computing system described herein can perform various operations, such as example operations 100. At 102, the CAE computing system can obtain and display an initial model (e.g., CAD model) representative of a physical object, during a design phase of the physical object. The physical object can define an outer surface and an interior structure opposite the outer surface. At 104, the system can generate a volume mesh model from the initial model. The volume mesh model can define a representation of the interior structure of the physical object. During the design phase, at 106, the system can make and display a first design update to the initial model, so as to define a first design update to the initial model. The design updates can be responsive to a user making a change to the model via a user interface of the system. At 108, in response to the first design update, the system can perform a first update to the volume mesh model, so as to generate a morphed volume mesh model. At 110, the system can save the morphed volume mesh model in memory. The process can return to 106 when the user makes further design update to the design or CAD model. For example, during the design phase, the system can make a plurality of consecutive design updates to the first design model, so as to define an updated design model. At 108, after each design update of the plurality of consecutive design updates, the system can perform a respective mesh update to the morphed volume mesh model corresponding to the respective design update, so as to iteratively generate an updated morphed volume mesh model. At 110, the system can save the respective updated morphed volume mesh model in memory.

[0023] Still referring to FIG. 1, at any time during the design phase, the system can retrieve the updated morphed volume mesh model from memory, so as to define a retrieved current morphed volume mesh model, and perform a simulation of the physical object using the retrieved current morphed volume mesh model (at 112). In some examples, the system can determine whether a subset of the plurality of consecutive design updates can be aggregated into a single mesh update of the morphed volume mesh model. When the subset can be aggregated, the system can tag the design updates in the subset as aggregated design updates, and add the aggregated design updates to a202318572 feature tree stored in the memory. It will be understood that the operations 100 can also include the various operations of the update aggregator that address the shortcoming situations described herein.

[0024] Referring also to FIG. 2, the CAE computing system can display a design model 202, which can define an initial model. The system can generate a volume mesh model 204 from the design model 202 (at 104). At 106, a user, and thus the system, can make a design update to the design model 202, so as to generate or define an updated design model 206. In particular, for example, the system can add a new feature, for instance a hole 203, to the design model 204, so as to define the updated design model 206 that includes the new feature (e.g., hole 203). At 108, in response to the design update, in particular- the addition of the hole 203, the system can perform an update to the volume mesh model 204, so as to generate a morphed volume mesh model 208 that includes the new feature (e.g., hole 203). In generating the morphed volume mesh model 208, the system only changes the area of volume mesh model 204 at the hole 203. Thus, the morphed volume mesh model 208 is the same as the volume mesh model 204 except for the adjustment corresponding to the new feature (hole 203). In contrast, traditional remeshing generates the volume mesh model 208, at 201, from the updated design model 206, and thus from scratch.

[0025] FIG. 3 illustrates an example of a computing environment that can include the simulation system within which embodiments of the present disclosure may be implemented. A computing environment 300 includes a computer system 310 that may include a communication mechanism such as a system bus 321 or other communication mechanism for communicating information within the computer system 310. The computer system 310 further includes one or more processors 320 coupled with the system bus 321 for processing the information.

[0026] The processors 320 may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as described herein is a device for executing machine-readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and / or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may include any type of suitable processing unit including, but not limited202318572 to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 320 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling rcad / writc operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor may be capable of supporting any of a variety of instruction sets. A processor may be coupled (electrically and / or as comprising executable components) with any other processor enabling interaction and / or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0027] The system bus 321 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computer- executable code), signaling, etc.) between various components of the computer system 310. The system bus 321 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The system bus 321 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCI-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

[0028] Continuing with reference to FIG. 3, the computer system 310 may also include a system memory 330 coupled to the system bus 321 for storing information and instructions to be executed by processors 320. The system memory 330 may include computer readable storage media in the form of volatile and / or nonvolatile memory, such as read only memory (ROM) 331 and / or random access memory (RAM) 332. The RAM 332 may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The ROM 331 may include other static storage device(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 330 may be used for storing temporary variables or other202318572 intermediate information during the execution of instructions by the processors 320. A basic input / output system 333 (BIOS) containing the basic routines that help to transfer information between elements within computer system 310, such as during start-up, may be stored in the ROM 331. RAM 332 may contain data and / or program modules that are immediately accessible to and / or presently being operated on by the processors 320. System memory 330 may additionally include, for example, operating system 334, application programs 335, and other program modules 336. Application programs 335 may also include a user portal for development of the application program, allowing input parameters to be entered and modified as necessary.[00291 The operating system 334 may be loaded into the memory 330 and may provide an interface between other application software executing on the computer system 310 and hardware resources of the computer system 310. More specifically, the operating system 334 may include a set of computer-executable instructions for managing hardware resources of the computer system 310 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the operating system 334 may control execution of one or more of the program modules depicted as being stored in the data storage 340. The operating system 334 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

[0030] The computer system 310 may also include a disk / media controller 343 coupled to the system bus 321 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 341 and / or a removable media drive 342 (e.g., floppy disk drive, compact disc drive, tape drive, flash drive, and / or solid state drive). Storage devices 340 may be added to the computer system 310 using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire). Storage devices 341, 342 may be external to the computer system 310.

[0031] The computer system 310 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 320 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 330. Such instructions may be read into the system memory 330 from another computer readable medium of storage 340, such as the magnetic hard disk 341 or the removable media drive 342. The magnetic hard disk 341 (or solid state drive) and / or removable media drive 342 may contain one or more data stores and data files used by embodiments of the present disclosure. The data store 340 may include, but are not202318572 limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed data stores in which data is stored on more than one node of a computer network, peer-to-peer network data stores, or the like. The data stores may store various types of data such as, for example, skill data, sensor data, or any other data generated in accordance with the embodiments of the disclosure. Data store contents and data files may be encrypted to improve security. The processors 320 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 330. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0032] As stated above, the computer system 310 may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term “computer readable medium” as used herein refers to any medium that participates in providing instructions to the processors 320 for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 341 or removable media drive 342. Non-limiting examples of volatile media include dynamic memory, such as system memory 330. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 321. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications .

[0033] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type202318572 of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0034] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer readable medium instructions.

[0035] The computing environment 300 may further include the computer system 310 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 380. The network interface 370 may enable communication, for example, with other remote devices 380 or systems and / or the storage devices 341, 342 via the network 371. Remote computing device 380 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 310. When used in a networking environment, computer system 310 may include modem 372 for establishing communications over a network 371, such as the Internet. Modem 372 may be connected to system bus 321 via user network interface 370, or via another appropriate mechanism.

[0036] Network 371 may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or any other network or medium capable of facilitating communication between computer system 310 and other computers (e.g., remote computing device 380). The network 371 may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RI-6, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks202318572 may work alone or in communication with each other to facilitate communication in the network 371.

[0037] It should be appreciated that the program modules, applications, computer-executable instructions, code, or the like depicted in FIG. 3 as being stored in the system memory 330 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the computer system 310, the remote device 380, and / or hosted on other computing device(s) accessible via one or more of the network(s) 371, may be provided to support functionality provided by the program modules, applications, or computer-executable code depicted in FIG. 3 and / or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 3 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 3 may be implemented, at least partially, in hardware and / or firmware across any number of devices.

[0038] It should further be appreciated that the computer system 310 may include alternate and / or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the computer system 310 are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted and described as software modules stored in system memory 330, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and / or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the202318572 functionality and may not be representative of the structure of software, hardware, and / or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and / or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as sub-modules of other modules.

[0039] Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and / or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase “based on,” or variants thereof, should be interpreted as “based at least in part on.”

[0040] Although embodiments have been described in language specific to structural features and / or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments do not include, certain features, elements, and / or steps. Thus, such conditional language is not generally intended to imply that features, elements, and / or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and / or steps are included or are to be performed in any particular embodiment.

Claims

202318572CLAIMSWhat is claimed is:

1. A computer-implemented method, the method comprising: displaying an initial model representative of a physical object, during a design phase of the physical object, the physical object defining an outer surface and an interior structure opposite the outer surface; generating a volume mesh model from the initial model, the volume mesh model defining a representation of the interior structure of the physical object; during the design phase, making a first design update to the initial model, so as to define a first design model representative of the physical object; in response to the first design update, performing a first update to the volume mesh model, so as to generate a morphed volume mesh model; and saving the morphed volume mesh model in memory.

2. The method as recited in claim 1, the method further comprising: during the design phase, making a plurality of consecutive design updates to the first design model, so as to define an updated design model; and after each design update of the plurality of consecutive design updates, performing a respective mesh update to the morphed volume mesh model corresponding to the respective design update, so as to iteratively generate an updated morphed volume mesh model.

3. The method as recited in claim 2, the method further comprising: after each mesh update, saving the respective updated morphed volume mesh model in memory.

4. The method as recited in claim 3, the method further comprising: at any time during the design phase, retrieving the updated morphed volume mesh model from memory, so as to define a retrieved current morphed volume mesh model; and performing a simulation of the physical object using the retrieved current morphed volume mesh model.

5. The method as recited in claim 2, the method further comprising:202318572 determining whether a subset of the plurality of consecutive design updates can be aggregated into a single mesh update of the morphed volume mesh model; when the subset can be aggregated, tagging the design updates in the subset as aggregated design updates; and adding the aggregated design updates to a feature tree stored in the memory.

6. A computer-aided engineering (CAE) computing system, the CAE computing system comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the computing system to: display an initial model representative of a physical object, during a design phase of the physical object, the physical object defining an outer surface and an interior structure opposite the outer surface; generate a volume mesh model from the initial model, the volume mesh model defining a representation of the interior structure of the physical object; during the design phase, make a first design update to the initial model, so as to define a first design model representative of the physical object; in response to the first design update, perform a first update to the volume mesh model, so as to generate a morphed volume mesh model; and save the morphed volume mesh model in memory.

7. The system as recited in claim 6, the memory further storing instructions that, when executed by the processor, cause the system to: during the design phase, make a plurality of consecutive design updates to the first design model, so as to define an updated design model; and after each design update of the plurality of consecutive design updates, perform a respective mesh update to the morphed volume mesh model corresponding to the respective design update, so as to iteratively generate an updated morphed volume mesh model.

8. The system as recited in claim 7, the memory further storing instructions that, when executed by the processor, cause the system to:202318572 after each mesh update, save the respective updated morphed volume mesh model in memory.

9. The system as recited in claim 8, the memory further storing instructions that, when executed by the processor, cause the system to: at any time during the design phase, retrieve the updated morphed volume mesh model from memory, so as to define a retrieved current morphed volume mesh model; and perform a simulation of the physical object using the retrieved current morphed volume mesh model.

10. The system as recited in claim 6, the memory further storing instructions that, when executed by the processor, cause the system to: determine whether a subset of the plurality of consecutive design updates can be aggregated into a single mesh update of the morphed volume mesh model; when the subset can be aggregated, tag the design updates in the subset as aggregated design updates; and add the aggregated design updates to a feature tree stored in the memory.

Citation Information

Patent Citations

  • Device, method and program for supporting design work of object

    JP2010067159A

  • Structural analysis system, structural analysis program and structural analysis method

    JP2013037437A

  • Design-phase reduced order models for computer-aided engineering workflows with standard mesh generators

    WO2023229785A1