Method and apparatus for automated underhood thermal modeling - Patents.com
By integrating response surface models and transient heat models with underhood fluid models, the simulation of thermal conditions under a vehicle hood is enhanced, allowing for accurate temperature simulations and reducing development costs.
Patent Information
- Application Number
- JP2020174105
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-09-03
- Filing Date
- 2020-10-15
- Publication Date
- 2025-05-14
- Estimated Expiration
- 2040-10-15
AI Technical Summary
Conventional techniques for simulating thermal conditions under a vehicle hood do not effectively incorporate response surface models and underhood fluid nodes, limiting their ability to accurately model complex thermal dynamics.
Integration of response surface models and transient heat models with underhood fluid models, allowing for the simulation of fluid flow and heat transfer in a three-dimensional representation of the underhood environment.
This approach enables accurate simulation of vehicle temperature development over long-term operating cycles, reducing the need for physical prototypes and lowering development costs.
Smart Images

Figure 0007676125000006 
Figure 0007676125000007 
Figure 0007676125000008
Abstract
Description
[Technical field]
[0001] Claiming priority This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 62 / 915,686, filed on October 16, 2019, and entitled “METHOD AND APPARATUS FOR AUTOMATIC UNDERHOOD THERMAL MODELING,” the entire contents of which are incorporated herein by reference.
[0002] The present description relates to computer simulation of physical processes, such as thermal modeling of physical fluid flows. [Background technology]
[0003] High Reynolds number flows have been simulated by generating discrete solutions to the Navier-Stokes differential equations by performing high-precision floating-point arithmetic on variables representing macroscopic physical quantities (e.g., density, temperature, flow velocity) at each of many discrete spatial locations. Another approach replaces the differential equations with what are commonly known as lattice gas (or cellular) automata, in which the macroscopic level of simulation provided by solving the Navier-Stokes equations is replaced by a microscopic level model that performs operations on particles moving between sites on a lattice.
[0004] Some fluid simulations include simulating thermal conditions under the hood of a vehicle. Conventional techniques for simulating under-hood thermal conditions include either running a coupled computational fluid dynamics and thermal model at one operating point or running a coupled computational fluid dynamics and thermal model at several operating points, but do not incorporate both a response surface model and under-hood (hereinafter "under-hood") fluid nodes. Summary of the Invention
[0005] Presented below is an approach useful for thermal simulation that involves the integration of a response surface model and a transient thermal model with an underhood fluid model implemented inside the transient thermal model.
[0006] When applying the underhood fluid model to related problems, the underhood components (underhood components) The "Near Wall Temperature" of the underhood air temperature follows the same trend as the upstream air temperature; the underhood air temperature does not deviate significantly from the upstream air temperature; the underhood airflow after cooling is well mixed or well-sectioned; the underhood air temperature is relatively uniform or well-sectioned by region; and for underhood components, the radiative / conductive incident heat rates (radiation / conduction incident heat rate) Several assumptions are made, such as that heat transfer to the underhood components is dominated by radiation / conduction from other hot components, and that the underhood airflow is non-zero. As a result, a lumped heat capacity that assumes a non-zero airflow for the entire driving cycle is used in the calculation. (lumped thermal capacity) may have an assigned heat transfer coefficient (HTC).
[0007] According to one aspect, a computer-implemented method includes receiving, by a computer processing system, digital data of a three-dimensional representation of a modeling of a fluid source and a fluid sink and a plurality of fluid nodes, executing a transient thermal model including an underhood fluid model of the plurality of fluid nodes, and running a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes.
[0008] The following are some of the features as disclosed herein that fall within the scope of the above-mentioned aspects.
[0009] Underhood Fluid Model (underhood fluid model)is the upstream air node (upstream air node) , a cooling package node, and one or more underhood fluid nodes. The method includes determining air temperatures upstream and downstream of the cooling package, and an air mass flow rate through the cooling package. (air mass flow rate) Response surface model to provide predictions of (Response Surface Models) It can run a cooling package to waste heat (cooling package heat rejection) from the prediction.
[0010] Running a simulation to simulate fluid flow includes calculating waste heat and transferring the waste heat by the cooling package to the underhood fluid nodes.
[0011] When the vehicle powertrain is modeled in the off state, the cooling package convects heat to the underhood node using a lumped thermal capacity initialized with a pre-calculated value. The air temperature and air mass flow determine the air temperature and mass flow coming into the upstream air node from the fluid source. Components have temperatures calculated throughout the simulation and are initialized to specific heat transfer coefficients (HTCs) and near wall temperatures (NWTs), and the near wall temperatures for components in the underhood are set to the underhood fluid node temperatures.
[0012] The vehicle powertrain is modeled in either an on-state or an off-state. When multiple cycles with the vehicle powertrain in the off-state are used in the method, the method further includes applying multiple thermal concentration capacities at different initialization temperatures.
[0013] According to a further aspect, a computer system includes one or more processors and a memory storing a computer program including computer instructions that, when executed by the one or more processors, cause the one or more processors to receive digital data of a three-dimensional representation of a modeling of a fluid source and a fluid sink and a plurality of fluid nodes, execute a transient thermal model including an underhood fluid model of the plurality of fluid nodes, and execute a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes.
[0014] The following are some of the features as disclosed herein that fall within the scope of the above-mentioned aspects.
[0015] The underhood fluid model includes a plurality of nodes, the nodes being an upstream air node, a cooling package node, and one or more underhood fluid nodes. The system further includes instructions for causing the one or more processors to execute a response surface model to provide predictions of air temperatures upstream and downstream of the cooling package and air mass flow rate through the cooling package, and to calculate cooling package waste heat from the predictions.
[0016] Running a simulation to simulate fluid flow includes instructions for causing one or more processors to calculate waste heat and transfer the waste heat by the cooling package to the underhood fluid node. When the vehicle powertrain is modeled in an off state, the cooling package convects heat to the underhood node using a lumped heat capacity initialized with a pre-calculated value. Air temperature and air mass flow determine the air temperature and mass flow coming from the fluid source into the upstream air node. Components have temperatures calculated throughout the simulation and are initialized to specific heat transfer coefficients (HTC) and near-wall temperatures (NWT), and the near-wall temperatures for the components are set to the underhood fluid node temperatures.
[0017] The vehicle powertrain is modeled either in the on-state or the off-state. When multiple cycles with the vehicle powertrain in the off-state are used in the method, the method includes multiple heat concentration volumes with different initialization temperatures. amount(thermal lumped capacities) applying the
[0018] According to a further aspect, a computer program product stored on a non-transitory computer readable medium includes computer instructions for causing a system having one or more processors and a memory to receive digital data of a three-dimensional representation of a modeling of a fluid source and a fluid sink and a plurality of fluid nodes, execute a transient thermal model including an underhood fluid model of the plurality of fluid nodes, and run a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes.
[0019] The following are some of the features as disclosed herein that fall within the scope of the above-mentioned aspects.
[0020] The computer program product further includes instructions for causing the one or more processors to execute a response surface model to provide predictions of air temperatures upstream and downstream of the cooling package, and air mass flow rate through the cooling package, and to calculate cooling package waste heat from the predictions.
[0021] One or more of the aspects described above may include one or more of the following features.
[0022] Aspects allow for the simulation of vehicle temperature evolution over long-term drive cycle testing. During the vehicle development process, drive cycle test data is one of the most informative types of data from a thermal perspective for overall vehicle performance. However, performing actual drive cycle testing requires building prototypes, which can be costly, and takes a significant amount of time, which can delay the introduction of new designs. The underhood fluid model methodology disclosed below provides an accurate methodology for simulating vehicle thermal performance through long-term drive cycle testing. This underhood fluid model methodology can enable engineers to start drive cycle testing before prototyping and integrate drive cycle testing into larger studies such as multidisciplinary optimization. [Brief description of the drawings]
[0023] [Figure 1] FIG. 1 illustrates a system for simulation of fluid flow, including a process for determining underhood conditions over a drive cycle test, where the example simulation uses a turbulent boundary layer model for compressible flow. [Diagram 2] 13 is a flowchart showing operations for formulating a lattice Boltzmann model simulation using the determined underhood conditions and turbulent boundary layer model. [Diagram 3] 11 is a flowchart showing a simulation operation using the lattice Boltzmann model. [Figure 4] FIG. 1 illustrates velocity components of two LBM models (prior art). [Diagram 5] FIG. 1 illustrates velocity components of two LBM models (prior art). [Figure 6] 1 is a flow chart of a procedure for determining underhood conditions followed by a physical process simulation system. [Figure 7] FIG. 1 is a perspective view of a microblock (prior art). [Figure 8A] FIG. 1 is a diagram of a lattice structure (prior art). [Figure 8B] FIG. 1 is a diagram of a lattice structure (prior art). [Figure 9] FIG. 1 illustrates a variable resolution technique (prior art). [Figure 10] FIG. 1 illustrates a variable resolution technique (prior art). [Figure 11] FIG. 1 shows the area affected by facets on a surface (prior art). [Figure 12] FIG. 1 illustrates an automated process for determining underhood conditions that can be used in various applications such as fluid simulation. [Figure 13] 13 is a flow chart illustrating an embodiment of the process shown in FIG. 12. [Figure 14] FIG. [Figure 15] FIG. 2 illustrates the heat flow between underhood fluid nodes based on air distribution within a vehicle. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0024] In an LBM-based physical process simulation system, the fluid flow is modeled on discrete velocities c i The distribution function value f, evaluated on the set i The dynamics of the distribution function is governed by the following equation, where f i (0) is known as the equilibrium distribution function and is defined as:
[0025]
number
[0026] The right hand side of the first equation is the "collision operator" mentioned above, which describes the change in the distribution function due to collisions between fluid pockets. The particular form of the collision operator used here follows Bhatnagar, Gross and Krook (BGK). It forces the distribution function to a prescribed value given by the second equation, which is its "equilibrium" form:
[0027] The BGK operator is a distribution function that distributes the collisions over {f eq This is constructed according to a physical argument that the eigenvalue approaches a well-defined local equilibrium given by {x,v2,t}:
number
[0028] From this simulation, traditional fluid variables such as mass ρ and fluid velocity u are obtained as simple sums. The LBM model is efficiently implemented on scalable computational platforms and can run with high robustness for time-unsteady flows and complex boundary conditions.
[0029] The standard technique for deriving the macroscopic equations of motion for fluid systems from the Boltzmann equations is the Chapman-Enskog method, in which successive approximations of the full Boltzmann equations are taken.
[0030] In fluid systems, small density disturbances travel at the speed of sound. In gas systems, the speed of sound is largely determined by temperature. The importance of compressible effects in a flow is measured by the ratio of the characteristic velocity to the speed of sound, known as the Mach number.
[0031] 1, system 10 is described including underhood fluid model 55. Underhood model 55 is an automated process for determining underhood conditions. A detailed description of underhood model 55 is provided in FIGS. 12-15.
[0032] The system 10 in this implementation is based on a client-server or cloud-based architecture and includes a server system 12 implemented as a massively parallel processing computing system 12 (standalone or cloud-based), and a client system 14, coupled via a network 13. The server system 12 includes a memory 18, a bus system 11, an interface 20 (e.g., a user interface / network interface / display or monitor interface, etc.), and a processing device 24. Within the memory 18 are a mesh preparation engine 32 and a simulation engine 34.
[0033] 1 shows the mesh preparation engine 32 in memory 18, the mesh preparation engine can be a third-party application running on a different system than the server 12. Whether the mesh preparation engine 32 runs in memory 18 or on a different system than the server 12, the mesh preparation engine 32 receives a mesh definition 30 provided by a user, the mesh preparation engine 32 prepares a mesh according to the physical object being modeled for simulation by the simulation engine 34, and transmits (and / or stores) the prepared mesh to the simulation engine 34. The simulation engine 34 includes a collision interaction module 34a, a boundary module 34b, and an advection particle collision interaction module 34c. The system 10 accesses a data repository 38 that stores 2D and / or 3D meshes (Cartesian and / or curvilinear), coordinate systems, and libraries.
[0034] 2, a process 40 for simulating fluid flow around a representation of a physical object is shown. In the example to be described herein, the physical object is a collection of components that reside under the hood of a vehicle. However, the use of under the hood components is merely exemplary, as the physical object can be of any shape or function that emits heat during operation.
[0035] The process 40 receives (42) a mesh (or grid) for a simulated physical object, the underhood system, for example, from the client system 14 or retrieves it from the data repository 38. In other embodiments, either an external system or the server 12 generates a mesh for the simulated physical object based on user input.
[0036] Process 40 also determines (43) the underhood conditions, either by invoking an automated process 55 for determining underhood conditions, or by having the calculated underhood conditions provided from another system / process that executed the automated process 55. That is, in some embodiments, either an external system or server 12 executes the automated process 55 for determining underhood conditions and provides those determined underhood conditions as inputs to simulation process 40.
[0037] The process pre-computes 44 geometric quantities from the obtained mesh and performs a dynamic lattice Boltzmann model simulation 46 using the pre-computed geometric quantities corresponding to the obtained mesh. The lattice Boltzmann model simulation includes simulating 46a the evolution of the particle distribution, performs 46b boundary layer processing when the flow hits a physical surface, and performs 46c advection of the particles to the next cell in the LBM mesh.
[0038] Referring now to Figure 3, a simulation process 46 simulates the evolution of particle distributions according to the lattice Boltzmann equation (LBE). Process 46 (see Figure 2) performs collision operations 46a (and collects a set of distributions coming from adjacent mesh locations from the collision operations), evaluates the flow at the physical boundary according to boundary modeling 46b, and advects particles 46c to the next cell in the LBM space.
[0039] The automated process for fluid flow simulation performed by the simulation engine 34 is described in U.S. patent application Ser. No. 11 / 463,673 (now issued as U.S. Pat. No. 7,558,714), entitled COMPUTER SIMULATION OF PHYSICAL PROCESS, which is incorporated by reference herein in its entirety.
[0040] In Figures 4, 5, and 7-11, each of these figures is labeled Prior Art because these figures appear in the above-referenced patents. However, these figures do not take into account any modifications that may be made to the flow simulations that use the underhood process as they appear in the above-referenced patents, because the underhood process, as described herein, is not described in the above-referenced patents.
[0041] 4, the first model (2D-1) 100 is a two-dimensional model that includes 21 velocities. Of these 21 velocities, one (105) represents a particle that is not moving, three sets of four velocities represent particles moving in the positive or negative direction along either the x or y axis of the lattice at either the normalized speed (r) (110-113), twice the normalized speed (2r) (120-123), or three times the normalized speed (3r) (130-133), and two sets of four velocities represent particles moving with the normalized speed (r) (140-143), or twice the normalized speed (2r) (150-153), relative to both the x and y lattice axes.
[0042] As also shown in Figure 5, the second model (3D-1) 200 is a three-dimensional model that includes 39 velocities, each velocity represented by one of the arrows in Figure 5. Of these 39 velocities, one represents a particle that is not moving, three sets of six represent particles moving at either a normalized speed (r), twice the normalized speed (2r), or three times the normalized speed (3r) in either the positive or negative direction along the x, y, or z axes of the lattice, eight represent particles moving at a normalized speed (r) relative to all three of the x, y, and z lattice axes, and twelve represent particles moving at twice the normalized speed (2r) relative to two of the x, y, and z lattice axes.
[0043] More complex models may also be used, such as the 3D-2 model, which contains 101 velocities, and the 2D-2 model, which contains 37 velocities. The velocities are more specifically described by their components along each axis as documented in Tables 1 and 2, respectively.
[0044] For the three-dimensional model 3D-2, of the 101 velocities, one represents particles that are not moving (group 1), three sets of six represent particles moving at either the normalized speed (r), twice the normalized speed (2r), or three times the normalized speed (3r) in either the positive or negative direction along the x, y, or z axis of the lattice (groups 2, 4, and 7), and three sets of eight represent particles moving at the normalized speed (r), twice the normalized speed (2r), or three times the normalized speed (3r) for all three of the x, y, and z lattice axes. 12 represent particles moving with a normalized speed (r) along two of the x, y, and z lattice axes (groups 3, 8, and 10), 12 represent particles moving with twice the normalized speed (2r) along two of the x, y, and z lattice axes (group 6), 24 represent particles moving with a normalized speed (r) along two of the x, y, and z lattice axes and twice the normalized speed (2r) along the remaining axes and no motion along the remaining axes (group 5), and 24 represent particles moving with a normalized speed (r) along two of the x, y, and z lattice axes and three times the normalized speed (3r) along the remaining axes (group 9).
[0045] For the two-dimensional model 2D-2, of the 37 velocities, one represents particles that are not moving (group 1); three sets of four velocities represent particles moving at normalized speed (r), twice the normalized speed (2r), or three times the normalized speed (3r) in either the positive or negative direction along either the x or y axis of the lattice (groups 2, 4, and 7); two sets of four velocities represent particles moving at normalized speed (r) or twice the normalized speed (2r) relative to both the x and y lattice axes; three velocities represent particles moving at normalized speed (r) relative to one of the x and y lattice axes and twice the normalized speed (2r) relative to the other axis; and eight velocities represent particles moving at normalized speed (r) relative to one of the x and y lattice axes and three times the normalized speed (3r) relative to the other axis.
[0046] The LBM models described above provide a particular class of efficient and robust discrete velocity kinetic models for the numerical simulation of flows in both two and three dimensions. This type of model contains discrete velocities and a particular set of weights associated with those velocities. The velocities correspond to Cartesian grid points in velocity space, which facilitates accurate and efficient implementation of discrete velocity models, in particular the type known as Lattice Boltzmann models. Using such models, flows can be simulated with high fidelity.
[0047] Referring to FIG. 6, a physical process simulation system operates according to a procedure 300 for simulating a physical process such as a fluid flow. Prior to the simulation, determined underhood conditions are received (301) and a simulation space is modeled as a collection of voxels (step 302). Typically, the simulation space is generated using a computer-aided-design (CAD) program. For example, a CAD program could be used to map the underhood components of a vehicle. The data created by the CAD program is then processed to add a grid structure with an appropriate resolution to describe the objects and surfaces in the simulation space.
[0048] The grid resolution may be selected based on the Reynolds number of the system being simulated, which is related to the viscosity of the flow (v), the characteristic length of an object in the flow (L), and the characteristic velocity of the flow (u): Re=uL / v. Formula (I-3)
[0049] The characteristic length of an object represents a large-scale feature of the object. For example, if the flow around a component in an underhood environment is being simulated, the height of the component could be considered to be the characteristic length. When the flow around a small region of the object is of interest, the resolution of the simulation can be increased or an area of increased resolution can be employed around the region of interest. As the grid resolution increases, the size of the voxels decreases.
[0050] The state space is f i It is expressed as (x,t), where f i represents the number of elements or particles per unit volume in state i (i.e., the density of particles in state i) at the lattice site described by the three-dimensional vector x at time t. For a known time increment, the number of particles is simply f i The combination of all states of the lattice sites is denoted as f(x).
[0051] The number of states is determined by the number of possible velocity vectors in each energy level. A velocity vector consists of integer linear velocities in a space with three dimensions: x, y, and z. In case of multi-species simulations, the number of states is increased.
[0052] Each state i represents a different velocity vector at a particular energy level (i.e., energy level 0, 1, or 2). The velocity of each state c i is specified using its "speed" in each of the three dimensions as follows: c i =(c i,x ,c i,y ,c i,z Formula (I-4)
[0053] The energy level 0 state represents a particle that is stopped and not moving in any dimension, i.e. c stopped =(0,0,0). Energy level 1 states represent particles that have a speed of ±1 in one of the three dimensions and a speed of 0 in the other two. Energy level 2 states represent particles that either have a speed of ±1 in all three dimensions, or a speed of ±2 in one of the three dimensions and a speed of 0 in the other two.
[0054] Generating all possible permutations of the three energy levels gives a total of 39 possible states (1 energy 0 state, 6 energy 1 states, 8 energy 3 states, 6 energy 4 states, 12 energy 8 states, and 6 energy 9 states).
[0055] Each voxel (i.e., each lattice site) is represented by a state vector f(x). The state vector completely specifies the status of the voxel and contains 39 items. The 39 items correspond to one energy 0 state, six energy 1 states, eight energy 3 states, six energy 4 states, twelve energy 8 states, and six energy 9 states. Using this set of velocities, the system can create Maxwell-Boltzmann statistics for the achieved equilibrium state vector.
[0056] During a simulation, when the process encounters a location within the mesh that corresponds to the surface of a physical object or device, the process performs the functions described above by evaluating under a turbulent boundary layer model that decomposes the pressure gradient into boundary layer flow velocities, as described above.
[0057] Referring now to FIG. 7, an microblock is shown. For processing efficiency, voxels are grouped in 2x2x2 volumes called microblocks. The microblocks are organized to allow parallel processing of the voxels and to minimize overhead associated with data structures. A shorthand notation for the voxels in a microblock is N i (n), where n denotes the relative position of the lattice site within the small block, n∈{0,1,2,...,7}.
[0058] 8A and 8B, a surface S (FIG. 8A) is defined in a simulation space (FIG. 8B) by a facet F α It is represented as a collection of: S={F α} Formula (I-5) where α is a subscript that counts a particular facet. Facets are not limited to voxel boundaries, but are typically sized to be an order of magnitude smaller than the size of the voxels adjacent to the facet, so that the facet affects a relatively small number of voxels. For the purposes of implementing surface dynamics, properties are attached to the facets. Specifically, each facet F α is the unit normal (nα ), surface area (A α ), center position (x α ), and the facet distribution function (f i (α)).
[0059] 9, different levels of resolution can be used in different regions of the simulation space to improve processing efficiency. Typically, the region 650 around the object 655 is the most important and is therefore simulated using the highest resolution. Because viscous effects decrease with distance from the object, reduced levels of resolution (i.e., enlarged voxel volumes) are employed to simulate regions 660, 665 spaced at increased distances from the object 655.
[0060] 10, a lower level of resolution may be used to simulate regions 770 around less influential features of the object 775, while the highest level of resolution is used to simulate regions 780 around the most influential features (e.g., the leading and trailing surfaces) of the object 775. Regions 785 away from the center are simulated using the lowest level of resolution and the largest voxels.
[0061] Identifying voxels affected by facets Referring again to FIG. 6, once the simulation space is modeled (step 302), voxels that are influenced by one or more facets are identified (step 304). A voxel can be influenced by a facet in a number of ways. First, a voxel that is intersected by one or more facets is influenced in that the voxel has a reduced volume relative to a voxel that is not intersected. This occurs because the facet, and the material that lies beneath the surface represented by the facet, occupies a portion of the voxel. A proportion factor P f(x) indicates the portion of the voxel that is not affected by the facet (i.e., the portion that may be occupied by the fluid or other material whose flow is being simulated). For voxels that are not intersected, P f (x) is equal to 1.
[0062] Voxels that interact with one or more facets by transmitting particles to the facets or receiving particles from the facets are also identified as voxels influenced by the facets. Every voxel intersected by a facet will contain at least one state that receives particles from the facet and at least one state that transmits particles to the facet. In most cases, further voxels will also contain such states.
[0063] Referring to FIG. 11, a non-zero velocity vector c i For each state i with facet F α is the velocity vector c i and the unit normal of the facet n α The magnitude of the vector dot product with (|c i n i |), and the surface area of the facet A α A parallelepiped G with a base defined by iα , which receives particles from or transmits particles to the region defined by the parallelepiped G iα Volume V iα is equal to: V iα =|c i n α |A α Formula (I-6)
[0064] Facet F α is the velocity vector of the state in the facet (|c i n i |<0), the particle is forced to a volume V iα When the velocity vector of the state points away from the facet, (|c i n i|>0), the particle is transferred to the region. As will be explained below, this formula is iα must be modified when occupying a portion of the surface, a condition that may occur in the vicinity of non-convex features such as interior corners.
[0065] Facet F α Parallelepiped G iα may overlap parts or all of multiple voxels. The number of voxels or parts thereof depends on the size of the facet relative to the size of the voxel, the energy of the state, and the orientation of the facet with respect to the lattice structure. The number of affected voxels increases with the size of the facet. Thus, the size of the facet is typically chosen to be on the order of, or smaller than, the size of the voxels located near the facet, as described above.
[0066] parallelepiped G iα The part of voxel N(x) that does not overlap with V iα (x). Using this term, voxel N(x) and facet F α The flux Γ of particles in state i moving between iα (x) is the number of voxels (N i (x)) to the density of particles in state i in voxel (V iα (x)) multiplied by the volume of the overlapping area: Gamma iα (x)=N i (x)V iα (x). Formula (I-7)
[0067] parallelepiped G iα When is intersected by one or more facets, the following conditions are true: V iα =ΣV α (x) + ΣV iα (β) Formula (I-8) Here, the first summation is G iα describes all overlapping voxels, and the second term is G iαDescribe all facets that intersect with the parallelepiped G iα When is not intersected by another facet, this expression simplifies to: V iα =ΣV iα (x). Formula (I-9)
[0068] Running the Simulation Once voxels affected by one or more facets are identified (step 304), a timer is initialized to begin the simulation (step 306). During each time increment of the simulation, the motion of particles from voxel to voxel is simulated by an advection phase (steps 308-316) that accounts for particle interaction with the surface facets. Next, a collision phase (step 318) simulates particle interaction within each voxel. The timer is then incremented (step 320). If the incremented timer does not indicate that the simulation is complete (step 322), the advection and collision phases (steps 308-320) are repeated. If the incremented timer indicates that the simulation is complete (step 322), the results of the simulation are stored and / or displayed (step 324).
[0069] Underhood Fluid Model 12, there is shown a process 800 for providing an underhood fluid model (UHFM) 812. The underhood fluid model 812 has components including source (fluid) nodes, sink (fluid) nodes, and lumped heat capacities (or capacities or capacitances, as appropriate), as shown in FIG.
[0070] The drive cycle profile 802 is used as an input to a response surface model 804. The response surface model 804 predicts the boundary conditions for the drive cycle thermal model. A script 806 analyzes the drive cycle and the predicted boundary conditions from the response surface model 804 and generates 808 a drive cycle transient thermal model using the predicted boundary conditions.
[0071] The script 806 uses predictions of air temperature, flow rate, HTC (heat transfer coefficient), NWT (near-wall temperature), and calculated Q (heat), as described below, from predicted boundary conditions provided by the response surface model 804. The initialization of the transient thermal model 808 is based on the predictions and follows the law of conservation of mass.
[0072] The UHFM or Underhood Fluid Model 812 handles two basic situations - powertrain on and powertrain off.
[0073] As shown in FIG. 12, the underhood fluid model 812 (UHFM) can be a component of a larger model, such as a response surface informed transient thermal model (RITThM) 810. The (UHFM) 812 requires modeling of fluid sources, fluid sinks, and multiple fluid nodes (for the example vehicle, three fluid nodes are used), as well as heat concentration capacity. These components are subsumed within the response surface informed transient thermal model 810. In this example, the three fluid nodes are an upstream air node, a radiator air node, and an underhood fluid node. However, embodiments are not limited to one underhood fluid node, and can incorporate several underhood fluid nodes depending on the underhood air temperature distribution (i.e., whether the air temperature distribution is well mixed, e.g., somewhat uniform, versus whether the air temperature distribution is segmented, e.g., uniform only within a zone or segment and not uniform between or within the zones).
[0074] A response surface model 804 is used to predict the air temperatures upstream and downstream of the cooling package (under-hood air-on / air-off temperatures) and the air mass flow rate through the cooling package. Based on this information, the cooling package waste heat is calculated. As used herein, a cooling package consists of one or more heat exchangers, e.g., a radiator, an air conditioner condenser, a transmission fluid cooler, etc.
[0075] All of this information is then passed to a response surface-informed transient thermal model 810, such as the PowerTHERM model (Dassault Systemes Simulia Corp.), and used to initialize an underhood fluid model 812. The underhood fluid model 812 is used to model the waste heat into the airflow and the convective heat transfer into the underhood. The response surface-informed transient thermal model is not coupled to a computational fluid dynamics (CFD) simulation.
[0076] The cooling package is used as a model element to have the exact air temperature when the vehicle is in the "on" state and to reject heat into the air to obtain the final air temperature at the vehicle off state, which air at the final air temperature moves into the underhood. The radiator is generally the last heat exchanger before the vehicle underhood and the dominant source of heat injected into the air stream, hence, as used herein, it is referred to as the "radiator air node." This is the case in most passenger cars.
[0077] However, an equally valid approach would be to take the air temperature in front of the entire cooling package in the "on" state, calculate the total heat rejected from all sources, and then determine the air temperature in the "off" state. Here, the starting point is chosen to be in front of the radiator because the "on" temperature of the radiator air can be well characterized by the surrogate model used to predict the transient thermal simulation boundary conditions.
[0078] The connectivity of the fluid nodes in the underhood fluid model 812 is as follows: the "air on" temperature and air mass flow rate define the air temperature applied at the upstream air node, while the air mass flow rate is applied at the advection link between the fluid source and the upstream air node. The upstream air node is connected to the radiator air node by an advection link. The radiator air node is connected to the underhood fluid node by an advection link. If multiple underhood fluid nodes are used, some fluid nodes may (but do not necessarily) not be directly connected to the radiator air node, but rather connected between each other by an advection link. In the case of multiple underhood fluid nodes, then the node influencing the portion closest to the cooling package will be connected to the radiator air node (i.e., the "cooling package air node"). Those underhood fluid nodes influencing portions further downstream may be connected to nodes influencing portions further upstream, and are not necessarily directly connected to the radiator air node by an advection link. To maintain mass conservation, the sum of all outgoing mass flows is equal to the mass flow going from the underhood air node to the fluid sink.
[0079] The underhood fluid model 812 is used to model two basic situations in everyday vehicle operation: powertrain on and powertrain off. The powertrain on basic situation includes a vehicle in motion or a vehicle stopped with the powertrain on (i.e., hot soak). The powertrain off basic situation is a specific type of hot soak situation known as a "key-off" hot soak.
[0080] 13, for the case where the vehicle powertrain is on, the underhood fluid model 812 functions as follows: As described above, the air mass flow rate and air temperature are set at the upstream air node, and an advection link between the upstream air node and the fluid source is provided (902). The air mass flow rate and air temperature are communicated through an advection link to the radiator air node (904). Based on the calculated waste heat value or curve, a certain heat quantity is imposed on the flow (906) (i.e., modeling the waste heat of heat from the cooling package), and the heated flow is communicated by the advection link to the underhood fluid node (908) and hence to the underhood components (described further below).
[0081] For the situation where the vehicle powertrain is off (i.e., key-off hot soak), the upstream air temperature and mass flow are again set in the manner described for the powertrain-on situation (922). At the radiator air node, no heat is charged (the radiator does not physically reject heat), and heat is simply transferred to the underhood fluid node (924). Even though no heat is rejected from the radiator, the radiator behaves like a thermal capacitor during the powertrain-off period. A lumped thermal capacity is calculated (926), and the calculated lumped thermal capacity is used to model natural heat convection during the powertrain-off situation (928).
[0082] By recognizing the difference in the mechanisms for imparting heat to the underhood between these two situations, it is possible to incorporate a switch 930 into the underhood fluid model 812. The boundary conditions used to incorporate this so-called "switch" 930 are as follows:
[0083] When the powertrain is on (932), the radiator is rejecting heat, which is calculated by the following formula (935):
number
[0084] In the powertrain off case (936), the radiator is hot and heat is convected into the underhood through a lumped volume whose initial temperature is assumed to be the final air-off temperature before the vehicle is shut off, and HTC is calculated by the following equation:
[0085]
number
[0086] Based on the HTC of the lumped capacity, the heat release rate can be calculated as follows (938):
number
[0087] Switch 930 is implemented in the following manner: while the powertrain is on, the radiator air node rejects heat into the flow and is the dominant convection heat source into the underhood. This means that at the points in the drive cycle where the powertrain is on, the HTC boundary condition of the lumped capacitance is assumed to be zero, and therefore, regardless of the initial temperature of the lumped capacitance, the lumped element capacitance will not convect heat to other components. However, when the powertrain is off, the radiator does not reject heat into the flow through it, and therefore the imposed thermal boundary condition (i.e., the radiator rejects heat) is forced to zero, and the HTC of the lumped capacitance is based on the equations presented above.
[0088] All components in the model (vehicle geometry 814) shown in Figure 12 are initialized with HTC and NWT values or HTC and NWT curves based on the simulated driving cycle and how often the convective boundary conditions need to be updated. By default, all non-underhood components use the convective boundary conditions (HTC / NWT) predicted by the response surface model (RSM) or surrogate model.
[0089] For components that lie within the underhood region (see the underhood fluid node, radiator air node, and upstream air node components in FIG. 15), the NWT boundary conditions are set at the underhood fluid node, thus implementing the underhood fluid model 812 in the transient thermal simulation. The transient thermal simulation is performed with the underhood fluid model 812 implemented to model the thermal behavior of the vehicle during the course of a drive cycle test.
[0090] Building a Transient Thermal Model The transient thermal model 810 (FIG. 12) uses response surface model (RSM) characterization predictions as a proxy for coupling the flow model to the thermal model. A description of RSMs can be found in AI Khuri and JA Cornell. Response Surfaces: Design and Analyses. Marce l Dekker, 1996. This is accomplished in several discrete steps. Using surrogate models instead of flow-based solvers, PowerFLOW (Dassault Systemes Simulia Corp.) and PowerCOOL (Dassault Systemes Simulia Corp.), only works if the characteristic times of their simulations are significantly smaller than the time-accurate models they will be used to update. In the case of the velocity fields in PowerCOOL and PowerFLOW, this is a valid assumption since the characteristic times for these quantities are one or more orders of magnitude smaller than the time step size in the transient thermal simulation.
[0091] Building the transient thermal model 810, which contains the underhood fluid model 812, involves creating the RSM using "design of experiments" or design space exploration. "Design of experiments" is a methodology used to build response surface models. In this process, after defining the design space or performance envelope, the software selects simulation points to obtain data that is used to build the RSM. The goal of this type of exploration is to characterize the specific objective functions of interest. CFD and thermal-coupled simulations are used to characterize these objective functions (also known as "response variables").
[0092] The objective function is the total vehicle C D , or component-averaged HTC and NWT. For this model, the objective functions are those parameters required to perform a transient thermal simulation. Once the objective function is determined, the input variables and their ranges are determined. The set of input variables and ranges is known as the performance envelope. This procedure proceeds carefully to ensure that any drive cycle desired to be simulated can be defined in terms of the outlined input variables and the operating points of the drive cycle are contained within the performance envelope.
[0093] Once the performance envelope is defined, simulation points within the performance envelope are selected in a controlled manner (design of experiments). This can be done through tools involving space-filling algorithms. Once the CFD and thermal-coupled simulations are completed, objective function values are extracted from the simulation results. Model generation tools are used to generate a response surface model (surrogate model) that predicts the objective function at any operating point within the performance envelope. Additional CFD and thermal simulations are run to update the RSM until the predictions are satisfactory.
[0094] Once the "Design of Experiments" phase is complete, the RSM is incorporated into the procedures outlined above in Figures 12 and 14. If the drive cycle desired to be simulated has operating points defined consistently with the performance envelope, the RSM can be polled to obtain the transient thermal simulation boundary conditions. Once polled and correctly formatted, these boundary conditions can be incorporated into the transient thermal simulation to simulate the drive cycle.
[0095] 14, the flow of this process is shown. Starting with the definition of a drive cycle profile (950), parameters are output from the profile and used as input to a response surface model (RSM) (952). From the response surface model (RSM), a second set of parameters is provided as input to generate a transient objective function history (response variables) (954).
[0096] Transient Thermal Model The transient thermal model 810 (FIG. 12) runs over the drive cycle test time, continually updating the convective boundary conditions for the underhood and non-underhood components. Recall that the non-underhood components simply use the NWT and HTC predicted by the RSM model. For the underhood components, the HTC predicted by the RSM is used, while the NWT is set by the underhood fluid model 812, which in turn heats up at the rate predicted by the RSM.
[0097] Underhood fluid node network During a transient thermal simulation, the underhood fluid model 812 accounts for the two most basic conditions of vehicle operation: powertrain on and off. To account for both conditions, the underhood fluid model 812 could include, and depending on the implementation, consist of, the following components, connected in the manner described below:
[0098] The underhood fluid model 812 includes a fluid source, a fluid sink, one or more fluid nodes, and in key-off situations, one or more heat condensing capacitances. In driving cycles that do not encompass a key-off region, a heat condensing capacitance is not required. This means that it may or may not be included in the underhood fluid model. The fluid nodes are ordered to match the flow behavior found in a real vehicle underhood environment. The upstream air nodes are first, followed by the radiator air nodes, and finally the underhood air nodes.
[0099] All fluid nodes are connected through advection links. Fluid sources are connected to upstream air nodes by advection links, and fluid sinks are connected to underhood air nodes by advection links. Fluid sinks are used to maintain mass continuity within the simulation. These nodes have the material properties of air and a fixed volume. Therefore, each node has thermal mass and inertia. The temperature of each node changes as it exchanges mass with other fluid nodes and heat with each part depending on the convection HTC of the part. The amount of heat in the exchange is in turn governed by the nodal temperature, which can also be thought of as the near-wall temperature on any components connected to the node.
[0100] The mechanism of how the underhood fluid model 812 operates between the two basic situations outlined above can be explained as follows: For the powertrain on situation, the fluid temperature and flow rate coming from the fluid source to the upstream air node are set by the boundary conditions (i.e., initialization parameters) imported from the RSM prediction (see Figures 12 and 14). The fluid is conveyed by an advection link to the radiator air node. At the radiator air node, a heat value is imposed on the fluid. This is the heat calculated by the prediction made by the RSM, and it models the heat rejected from the radiator into the passing airflow going to the underhood. The fluid is then conveyed from the radiator air node to the underhood fluid node, where the heat is convected to the underhood components.
[0101] For the powertrain off situation, the underhood fluid model 812 mechanism works as follows. In this situation, the fluid coming from the fluid source to the upstream air node is again set to the predicted flow rate and temperature. It is conveyed to the radiator air node by an advection link. From the vehicle operation perspective, when the powertrain is off, the radiator is not actively rejecting heat into the through air stream (no coolant is being pumped). In this situation, the heat generation rate imposed at the radiator air node is forced to zero. Additional heat is rejected into the air stream by connection to a lumped capacitance. The lumped capacitance is connected to the underhood air node via setting the NWT of the lumped capacitance to the underhood fluid node.
[0102] A lumped capacity is, by definition, an "empty" part with no geometry that can be assigned the exact same boundary conditions and properties as is done in a configuration shape represented by some geometry. Since a lumped capacity is used to represent a high temperature radiator, mass, volume, and material properties are assigned based on the radiator design. HTC values (one of the convection boundary conditions is required) are calculated based on the predicted boundary conditions from the RSM and are imported into the transient thermal model 810. The NWT values of the lumped capacity are set to the underhood fluid node. This provision models the physics seen in the heat exchanger during key-off operation as a thermal mass that continues to reject heat into the underhood environment. For the powertrain on situation, the radiator is an active assigned heat source and its thermal inertia is modeled and may not require a separate lumped capacity for the powertrain off situation. The initial temperature of the lumped capacity is assumed to be the air-off temperature of the final radiator air node. This means that each separate stop area in the drive cycle test requires a separate lumped volume.
[0103] Based on the above description of the underhood fluid node mechanics, a switch mechanism can be implemented for use in modeling the cooling package waste heat to the underhood fluid node.
[0104] 15, a diagram useful for understanding the underhood fluid model UHFM812 is shown. The diagram shows representations of the underhood fluid nodes, the radiator air nodes, and the upstream air nodes as dots, and shows the calculations for when ram air is present and the powertrain is on. Also shown are the calculations when there is no ram air or the engine is not running. UHFM812 offers several advantages over existing approaches, such as allowing UHFM812 to simulate multiple vehicle powertrain operating modes at lower computational, as well as monetary and time costs.
[0105] The dots in FIG. 15 are a visual representation of nodes. The nodes represent heat transfer between components in the underhood environment and provide a representation of volumes of fluid that would normally be simulated using many thousands or more volume elements with many degrees of freedom. Therefore, the nodes are a reduced order model of heat transfer. These nodes do not need to have degrees of freedom, but rather are tightly constrained computational constructs. The nodes are selected based on the upstream ambient conditions, the cooling package nodes, one heat source, and the advection in and out are known quantities. The underhood nodes can be more complex, but are selected based on knowing a fixed amount of energy in the mass flow going into and out of the cooling package nodes, with the remaining heat transfer calculated.
[0106] UHFM812 eliminates the need to couple thermal and CFD models and therefore requires fewer computational resources, resulting in faster turnaround times. Simulations can be run in a shorter amount of time than other traditional methodologies.
[0107] For thermal simulation of a standard vehicle configuration, a thermal simulation input or temperature distribution is used in which the cooling package is located upstream of the powertrain and airflow is directed from the cooling package to the underhood compartment of the vehicle.
[0108] The following boundary conditions are used to initialize the thermal simulation. These are the average air temperatures (T amb , T coolant , T oil , T exh , T rad air-on , T rad air-off , T toac air-on , T toac air-off ) Also included is the total / average air mass flow (m coolant , m oil , m rad,air , m to ac air , m front grill ) In addition, any information that can determine the overall vehicle and / or powertrain operation. Vehicle Speed / Fan Speed (V mag ,ω fan ).
[0109] Other parameters include engine RPM and water pump RPM, as well as one or more of heat exchanger flow rates and transient thermal simulation results. Zoned or relatively uniform near-wall temperatures, where the number of zones corresponds to the number of underhood fluid nodes used to set the near-wall temperatures for a particular zone of the component.
[0110] The subject matter and functional operations described herein may be implemented in the form of digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware (including the structures disclosed herein and their structural equivalents), or one or more combinations thereof. The subject matter described herein may be implemented as one or more computer programs (i.e., one or more modules of computer program instructions encoded on a tangible non-transitory program carrier for execution by or for controlling the operation of a data processing apparatus). The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or one or more combinations thereof.
[0111] The term "data processing apparatus" refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. An apparatus can also be or further include special purpose logic circuitry (e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)). In addition to hardware, an apparatus can optionally include code that creates an execution environment for a computer program (e.g., code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof).
[0112] A computer program, which may also be referred to or described as a program, software, software application, module, software module, script, or code, may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may correspond to a file in a file system, but need not. A program may be stored within a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple cooperating files (e.g., files that store one or more modules, subprograms, or portions of code)). A computer program may be deployed such that the program is executed on one computer, or on multiple computers located at one site or distributed across multiple sites and interconnected by a data communications network.
[0113] The processes and logic flows described herein may be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry (e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)).
[0114] A computer suitable for executing a computer program can be based on a general-purpose or dedicated microprocessor or both, or any other type of central processing unit. In general, the central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for executing or executing instructions, and one or more memory devices for storing instructions and data. In general, a computer also includes one or more mass storage devices (e.g., magnetic, magneto-optical, or optical disks) for storing data, or is operatively coupled to receive data from or transmit data to them, or both, although a computer may not have such devices. Furthermore, a computer may be incorporated within another device (e.g., a mobile phone, a personal digital assistant (PDA), a portable audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few).
[0115] Suitable computer-readable media for storing computer program instructions and data include, by way of example, all forms of non-volatile memory on media and memory devices, including semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated within, special purpose logic circuitry.
[0116] To provide for interaction with a user, embodiments of the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and pointing device (e.g., a mouse or trackball) by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user, for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form, including acoustic, speech, or tactile input. Additionally, a computer may interact with a user by sending documents to and receiving documents from a device used by the user, for example, by sending a web page to a web browser on the user's device in response to a request received from the web browser.
[0117] An embodiment of the subject matter described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or includes middleware components (e.g., an application server), or includes front-end components (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of one or more of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN) and a wide area network (WAN) (e.g., the Internet).
[0118] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data (e.g., HTML pages) to a user device acting as a client (e.g., for purposes of displaying data to a user interacting with the user device and receiving user input from the user). Data generated at the user device (e.g., results of user interaction) can be received at the server from the user device.
[0119] Although the present specification includes many specific implementation details, these should not be interpreted as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to certain embodiments of a particular invention. Some features described in the context of separate embodiments herein can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as functioning in a particular combination, and even initially claimed as such, one or more features from the claimed combination may, in some cases, be deleted from the combination, and the claimed combination may relate to a subcombination, or a variation of a subcombination.
[0120] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring such operations to be performed in the particular order or sequence shown, or that all of the illustrated operations be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the program components and systems described above may generally be integrated together in a single software product or packaged into multiple software products.
[0121] Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. By way of example, the processes depicted in the appended figures do not necessarily require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. [Explanation of symbols]
[0122] 10. System 11 Bus System 12 Server Systems 13 Network 14 Client Systems 18 Memory 20 Interface 24 Processing Device 30 Mesh definition 32 Mesh Preparation Engines 34 Simulation Engine 34a Collision Interaction Module 34b Boundary Module 34c Advection-Particle Collision Interaction Module 38 Data Repositories 55, 812 Underhood Fluid Model 802 Drive Cycle Profile 804 Response Surface Model 810 Transient Thermal Model Considering Response Surface Information 814 Vehicle Geometry 930 Switch
Claims
1. 1. A computer-implemented method comprising: receiving, by a computer processing system, digital data of a three-dimensional representation of a model of a fluid source and a fluid sink and a plurality of fluid nodes; running a transient thermal model including an underhood fluid model of the plurality of fluid nodes; running a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes; switching calculations between waste heat from heat sources and convection heat from heat concentrating volumes according to a state of the underhood fluid model while running the transient thermal model; 4. A computer-implemented method comprising:
2. The method of claim 1 , wherein the underhood fluid model includes a plurality of fluid nodes: an upstream air node, a cooling package node, and one or more underhood fluid nodes.
3. executing a response surface model to provide predictions of air temperatures upstream and downstream of the cooling package node and air mass flow rate through the cooling package node; Calculating cooling package waste heat from said prediction; The method of claim 2 , further comprising:
4. Running a simulation to simulate a fluid flow, Calculating the waste heat; and transferring waste heat from said cooling package node to at least one of said one or more underhood fluid nodes; The method of claim 2 , comprising:
5. 3. The method of claim 2, wherein when a vehicle powertrain is modeled in an off state, the cooling package node convects heat to at least one of the one or more underhood fluid nodes with the heat concentrating capacity initialized with a pre-calculated value.
6. The method of claim 3 , wherein the air temperature and the air mass flow rate determine an air temperature and mass flow rate coming from the fluid source into the upstream air node.
7. 7. The method of claim 6, wherein the one or more underhood fluid nodes have temperatures calculated through the simulation initialized to a particular heat transfer coefficient (HTC) and near-wall temperature (NWT), and the near-wall temperature for the underhood fluid node is set to the underhood fluid node temperature.
8. The method of claim 1 , wherein the vehicle powertrain is modeled in either an on-state or an off-state.
9. When multiple cycles with the vehicle powertrain off are used in the method, the method further comprises: Applying multiple heat concentration capacities with different initialization temperatures The method of claim 1 further comprising:
10. 1. A computer system comprising: one or more processors; A memory storing a computer program configured with computer instructions, which when executed by the one or more processors, cause the one or more processors to: receiving digital data of a three-dimensional representation of a model of a fluid source and a fluid sink and a plurality of fluid nodes; running a transient thermal model including an underhood fluid model of the plurality of fluid nodes; running a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes; while executing the transient thermal model, switching the calculation between waste heat from heat sources and convection heat from heat concentrating volumes according to the state of the underhood fluid model; Memory and A computer system comprising:
11. The system of claim 10 , wherein the plurality of fluid nodes includes an upstream air node, a cooling package node, and one or more underhood fluid nodes.
12. the one or more processors; running a response surface model to provide predictions of air temperatures upstream and downstream of said cooling package node and air mass flow rate through said cooling package node; Calculating cooling package waste heat from the prediction; The system of claim 11 further comprising computer instructions for:
13. Running a simulation to simulate fluid flow includes: Calculate the waste heat, transferring waste heat from said cooling package node to said one or more underhood fluid nodes; The system of claim 11 comprising computer instructions for:
14. 14. The system of claim 13, wherein when a vehicle powertrain is modeled in an off state, the cooling package node convects heat to the one or more underhood fluid nodes with the heat concentrating capacity initialized with a pre-calculated value.
15. The system of claim 12 , wherein the air temperature and the air mass flow rate determine an air temperature and mass flow rate coming from the fluid source into the upstream air node.
16. 12. The system of claim 11, wherein the one or more underhood fluid nodes have temperatures calculated through the simulation initialized to a particular heat transfer coefficient (HTC) and near-wall temperature (NWT), and the near-wall temperature for the one or more underhood fluid nodes is set to the underhood fluid node temperature.
17. The system of claim 10 , wherein the vehicle powertrain is modeled in either an on-state or an off-state.
18. When multiple cycles during which the vehicle powertrain is off are used in the computer instructions, the computer instructions further comprising: The system of claim 10 , further comprising applying a plurality of heat concentration volumes of different initialization temperatures.
19. 1. A computer program product stored on a non-transitory computer readable medium, the computer program product providing a system comprising one or more processors and a memory, the system comprising: receiving digital data of a three-dimensional representation of a model of a fluid source and a fluid sink and a plurality of fluid nodes; running a transient thermal model including an underhood fluid model of the plurality of fluid nodes; running a simulation to simulate fluid flow from the fluid source to the fluid sink through each of the plurality of fluid nodes; While running the transient thermal model, the calculation switches between waste heat from heat sources and convection heat from heat-concentrating volumes according to the state of the underhood fluid model. A computer program product comprising computer instructions for:
20. the underhood fluid model includes a plurality of fluid nodes, the fluid nodes being an upstream air node, a cooling package node, and one or more underhood fluid nodes; the one or more processors; running a response surface model to provide predictions of air temperatures upstream and downstream of said cooling package node and air mass flow rate through said cooling package node; Calculating cooling package waste heat from the prediction; 20. The computer program product of claim 19, further comprising instructions for:
Citation Information
Patent Citations
A novel design method for the lower tube box and its corundum lining of a quench waste heat boiler.
CN102260520A
CAD device and CAD / CAE system using the same
JP2004213297A
Method for fast transient thermal analysis to simulate a vehicle drive cycle
US20180018413A1
Generalized fluid system simulation program
US6748349B1
A device for and a method of performing a coupled simulation of a physical structure described by several separate models
WO2008034499A1