Structural analysis of subsystems 1

[hky20]

Hello!

I am curious about how, in a system, non-local effects from the rest of the system are accounted for when modelling the structural behaviour of an individual subsystem.

Say our system is the transmission system of an aircraft engine, which consists of subsystems like the gearboxes, shafts, bearings, cases, and other miscellaneous support structures. Each of those subsystems would be designed by different teams, and they would need an analysis model of their subsystem, e.g. a FE model, to base their design decisions on. How would the tail bearing housing designer account for loads and displacements from its adjacent subsystems like the LP turbine, LP shaft, rear engine mount, etc. when devising his FE model?

The first method I can think of is to pass subsystem-subsystem interface loads to each subsystem. However, where do those loads come from? Also, what happens if a subsystem is not fully constrained in all DOFs, even if the system as a whole is? Do you just artificially constrain the remaining free DOFs at an arbitrary location in the subsystem model?

The second method I can think of is to use superelements, which I'm less informed about. I presume you can't just generate a single superelement representation for each subsystem and then pass them around individually to be plugged in to the ends of subsystem models, because the attachment nodes are different for each subsystem.

I am also curious about how/if the methods vary between solution types, e.g. static, dynamic, etc.

 

[rb1957]

you're are correct … the whole assembly needs to be accounted for.

Now for your initial design, you don't know what's happening on the other side of your interface, 'cause it hasn't been designed (yet). So make an initial assumption …
for stiffness, I'd assume a finite stiffness in all directions (1E6, 1E7), maybe a lower stiffness in some directions if experience tells you this,
for loads, I'd expect a limited number of cases that you can make simple assumptions.

The key to a successful design is to make these early design assumptions as close (or reasonably conservative) as possible to the final design requirements. Get it wrong and loads increase late in the design … and all seven levels of heck follow.

your first proposal, to treat each in isolation "could" work but would be very iterative, as each sub-system would guess an interface load and both neighbours would correct this guess, etc.
your second proposal would work as a superelement assembles the stiffness of the internal structure to the boundary of each sub-system. So you run the complete system, and then run each sub-system with the interface loads from the complete model. The advantage of this (over assembling each sub-system FEM together) is that the details of the sub-systems are hidden (inside the super-element) protecting commercial proprietary (if that's a concern). But initially you don't have these components modelled, so you have to make some assumptions.

another day in paradise, or is paradise one day closer ?

 

[SWComposites]

You need an integrated FE model to get the interface loads and displacements correct. Each part designer can’t work in their little bubble without dealing with the interfaces (well, they can, but the design will likely be a disaster).

 

[GregLocock]

A million years ago the theory of receptances was developed, which allowed dynamic modellers to model each subsystem and then tie them together into one enormous mess. When FEA came along initially a lot of effort was put into the same idea - I think they were called superelements, but that no longer seems to be the case, as bandwidth is no longer such an issue. Oddly enough in my MBD models I occasionally replace rigid parts by abstracted FE models called flex bodies, which are just linear stiffness and mass matrices for the nodes of interest.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[Ali baba Sx]

Let's take the example of an aircraft engine.

First, as rb1957 has stated you need to make an initial assumption of your whole model stiffness. Most of the time, this work is done by the pre-design team whose job is to roughly design the engine from its specifications and the technological choices it has made. Then from this whole model and how your engine should operate, you derive the load cases (relevant to finely design your engine) at each interface between the sub-systems. Once the first whole model is built, the pre-design team work is done.

Afterward, the whole model is taken care by the integration team. The integration team provides to each sub-system team the load cases to use to improve their design. They do so building precise models of their own. When each team is done, usually they are asked to build a smaller model (in terms of dofs) of their sub-system, that is representative enough, but may "hide" irrelevant detail from the whole engine model point of view. The sub-systems models are then assembled as a new whole engine model by the integration team. At this stage, the integration team can spot problems in the design that appear only once they assemble the whole model (for instance a natural mode is close to the engine rpm). They find a solution talking with the sub-system teams (add some thickness there, remove this, ...) and finally they arrive at a whole model that behaves correctly. From then, the integration team computes the new load cases and a new design loop starts.

This process goes on until convergence is reached. As you can see it is an iterative process.

There are many ways to build a simpler model from a detailed one. One of them is to build a super-element for each subsystems. (Static-)Super-elements propose an exact representation of the sub-system when dealing with static computation. However, when doing dynamics, it is harder to build a representative (dynamic-)super-element. You have to embed dynamic modes into your super-element, but it is hard to know in advance what boundary conditions should be used to compute these modes, and how many of them should be kept.

For the part of your question about the "not fully constrained dofs", let's say only static computation are performed. The whole model has to be fully constrained (to make it simple you have the thrust as the loading, and clamped boundary conditions are set where the engine is mounted on the plane). Then let's talk about a sub-system that is not concern with the mounted boundary conditions. It receives only loads from the integration team. But these loads are balanced, otherwise there is something wrong with your computation on the whole model. And of course, in order to perform a finite element computation on this sub-system you need proper boundary conditions (otherwise there cannot be stiffness inversion). No problem, you just have to select 6 dofs, among the loaded dofs, that define an isostatic boundary condition. These dofs will have no other choice than showcasing the same amount of reaction as the load you wanted to apply to them (because initially your loading is balanced). And of course make sure to check the reaction on these dofs, to spot if there was an error somewhere.

I hope this answer your question