Superelement f06 output - epsilon, spcforce resultant 1

[tomsing]

From a superelement newbie - what should I be looking for in the f06 file for a superelement creation run, and an assembly run? Just looking at linear static for the moment. If it matters, I'm currently playing around with the PCH output format. Unfortunately, the SE users manual doesn't seem to go into much detail here. Appreciate any help!

A couple of specific questions:

1. The SE creation run is giving me epsilon and external work for [K_OO], for each of the LSEQ load sets. What does that represent?

In a standard run, Nastran "inverts" [K_LL], solves for displacement,

{d_LL} = [K_LL]^-1 * {P_LL}

then calculates residual load

{r} = {P_LL} - [K_LL] * {d_LL}

Then epsilon is the work done by the residual load divided by the work done by the applied load,

e = {r} dot {d_LL} / {P_LL} dot {d_LL}

Basically a scalar measure of the numerical error in "inverting" K and solving for d.

So, for the creation run, is it "inverting" [K_OO] and solving for displacements? A SE isn't required to be constrained in rigid body motion, right? Nor is it required to have any load applied to it. So it seems like it couldn't be doing that, and would be doing something different than it does for a "standard" run. But certainly there's a need to determine how precise the "inversion" is, to clue me in if there's a problem with my SE, and I assume that's what epsilon represents here as well.

Related, is it reasonable to use the same criteria for acceptability for epsilon here as for standard analysis? Should it be lower, since it's going to get rolled into the larger assembly matrix, which will presumably magnify errors?

2. The SE assembly run isn't writing an SPCFORCE RESULTANT output block for the f06. I have SPCFORCE(PLOT) = ALL in the master case control section. I understand why it wouldn't be in the SE creation output, because, again, we're not solving the system, so there's no SPC forces to sum up. But why not in the assembly run?

--Tom

 

[dmapguru]

Koo is the stiffness matrix partitioned to the omitted DOF (o for omitted). The factorization is used to compute matrix Got using the off-diagonal partition of Kaa (Koa). I am surprised you can't find reference to this in the SE guide, it should be under the static condensation section. Which SE guide are you using?

For the SPCF output, do you have any active SPC's in the assembly run? Are you applying balanced loads so there is no SPCF?
DG

 

[tomsing]

Using the NX Nastran SE users guide (and NX Nastran V12). It doesn't go into epsilon at all. I'm pretty sure the epsilon calc predates 2001 and is common to all flavors of Nastran, and the NX guide started off as the MSC guide, so I'd be surprised if it's in MSC's, either.

I understand what Koo is, I get how the boundary transformation is computed. What I don't understand is where epsilon comes from.

Normally, we have P = Kd. There's some numerical error in solving for d, so let's call our solution d'. We find d' from d' = K^-1 P, then plug that d' back in to check our work, P' = Kd'. Then we have the difference between the actual and "check" force to get the residual force, r = P - P'. Epsilon is the work ratio between that residual force and the actual force, using the approximate displacement, e = r dot d' / P dot d'.

In the SE creation run, we're finding Got using Koo * Got = Kot, So Got = Koo^-1 * Kot. There's some numerical error in this, too, so let's say that gives us Got'. I suppose you could check your result by computing Kot' = Koo * Got', and get some residual Kot - Kot', but I don't know how you'd reduce that to a scalar to compute an epsilon that would depend on the load case. So that's apparently not what it's doing.

What does depend on the load case is, you have Pt = Ptbar + Got^T * Po. Since we're using Got', let's write that as Pt' = Ptbar + Got'^T * Po. Okay, but we don't have a "known" Pt to compare Pt' to to get a residual, and we don't have anything to dot it with to get down to a scalar.

So, I'm stuck.

As for the SPC force resultant table in the assembly run, I'll get back to you on Monday whether I have SPCs active. Pretty sure there are. Even if I had a balanced set of loads, I should still get a resultant table showing 0 resultant force, though, right?

--Tom

 

[dmapguru]

You appear to be mixing the solution for the static boundary transformation GOT which comes from Kot applied to Koo^-1 and solutions for loads applied to interior points which comes from Po applied to Koo^-1. You will certainly have the former, but the latter is optional.

I don't know what NX is doing, but MSC Nastran will compute epsilon values for the solutions Koo^-1.Po - it will not output epsilon values for the solutions Got = koo^-1.Kot. This is because the solution is computed by two different modules. That is not to say an epsilon could not be computed for the latter case, it could, it just isn't. In both cases, the O x O matrix Koo is factorized to Loo (I assume it's symmetric) and a right-hand side (RHS of loads or pseudo loads) applied to the factorized matrix.

For the optional case of Koo^-1.Po, the loads in Po are the loads you defined with one or more load entries like FORCE, GRAV, PLOADi etc. There will be as many vectors in Po as there are loads cases (SUBCASEs) you defined in the case control, and you will get an epsilon for each load. You may have the case where no loads are applied to interior DOF. Matrix Koo is a partition of Kff, so the boundary points in Kff (i.e. those associated with Ktt) are fixed when Koo is factorized to Loo. That means any loads applied via Po will yield the same displacement solution (and same epsilon) as a run involving no superelement generation at all where you fix the GRID points you placed on the SE boundary with SPC entries and apply the loads to the same points as those applied with Po. This would be a static SOL 101 run with no superelements, and you appear to understand what epsilon means in this case. It would be no different in the SE case with the points you placed on SPC entries being placed on ASET entries instead and the same load applied via Po.

For the mandatory case of Koo^-1.Kot, Kot is now a pseudo load, the RHS applied to the Loo factors. Physically this is equivalent to fixing all the boundary DOF except one and then moving that boundary DOF with a unit displacement; this occurs for each boundary DOF in turn. Once again, you can satisfy yourself this is the case by running a SOL 101 with no superelement in sight. Define an SPC set that fixes all DOF on the boundary. Define as many SUBCASEs in the job as you have boundary DOF (not points, DOF) so 6* the number of GRID points on the boundary, where each SUBCASE points to a n SPCD (enforced displacement) for each of the boundary points in turn. If you did this, you'd see an epsilon for each SUBCASE (as the solve is being carried out by the module that computes epsilon in this case).

So you see, the epsilon computation is just a residual to a linear solve. MSC Nastran does no care where the RHS comes from, it just applied it to the LHS (the Loo factors in this case).

The SE guide for MSC Nastran covers all the bits I mentioned above, perhaps without the equivalent SOL 101 jobs. Discussion of epsilon and external work (which is just strain energy or half the compliance) can be found in the Linear Static Analysis User's Guide, or take a look at the SSG3 module in the DMAP Programmer's Guide (this is the module that performs static solution for SOL 101). You can also output the residual load vectors if you set PARAM,IRES,1.
DG

 

[tomsing]

so the boundary points in Kff (i.e. those associated with Ktt) are fixed when Koo is factorized to Loo

I think this is getting at what I was missing. I found the MSC superelements guide at simcompanion.hexagon.com/customers/s/article/superelement-user-s-guide-doc9185; it's significantly more detailed than the NX manual, looks to have been significantly revised since it forked. Just for future reference for the next person looking for this topic, the relevant section is Static Condensation Process.

So, just to summarize, you apply the internal constraints to get down to the F set of DOFs, which are split into the internal (O set) and external (T set) DOFs. Then the boundary transformation matrix Got = -Koo^-1 * Kot relates the internal DOFs to the external DOFs. You then use that to write Pt = (Kttbar + Kto * Got) * ut = Ktt * ut, and now you've got a stiffness relationship between the external DOF load and displacement, which is what goes to your assembly run. Then, your assembly run is going to give you the displacements on those external DOFs.

In order to get the displacements on the internal DOFs, that's going to come from the superposition of the displacements from the internal loads with the external DOFs fixed, and the displacements induced by the boundary displacements with 0 internal load. That fixed boundary solution can be computed during the creation run, uo(fixed) = Koo^-1 * Po, while the "free" boundary solution (I'd say enforced displacement boundary solution) uo(free) = Got * ut has to be done after the assembly run. During the creation run, once we have uo(fixed), we can calculate a residual internal force, r = Po - Koo * uo(fixed), and epsilon = r dot uo(fixed) / Po dot uo(fixed).

I think I was getting hung up not realizing that partitioning the SE stiffness matrix is essentially the same as imposing fixed BCs on the boundary DOFs, so assuming there's not some other mechanism in the SE, the problem should be solvable (that is, the "constrained" stiffness matrix Koo is invertible; no pivot ratio problems), even if there are no internal BCs.

As for the SPC force resultant table, I did not have any SPCs active in the assembly run. Add those in, and the resultant table shows up.

Thanks for the help!