External superelements / model reduction questions 3

[isponmo]

Dear eng-tip community,

I have a couple of questions regarding external superelements originated from condensating a full FE model via EXTSEOUT command.

The condensed models I typically work with (or generate) are obtained using dynamic reduction (CMS). Therefore, using SOL103 for the reduction run. The formats I get for the matrices are typically op4 or dmig (dmigpch). The files I get are a .pch, .asm and .op4 (the latter not for dmig case).

My questions are the following:
1 - I have observed that, in the assembly run, I can include gravity cards (GRAV) and these will be recognised when dmig matrices are used, leading to correct results. However, when op4 matrices are used instead, grav cards are not recognised. Since the mass information is actually included in the mass matrix also in op4 case, what is the reason for this limitation? Is there an easy workaround without having to use dmap alters?
2 - In some occassions, I have received condensed models in dmig format which do not follow the two file convention (.pch+.asm). Instead, the asm file is not provided and the bulk partition ("BEGIN SUPER") is removed from the .pch file. I guess that, by doing this, the reduced model is not a superelement anymore and simply becomes part of the residual structure. This makes the run file cleaner as you don't need so many includes and you don't have to worry that the *.pch files are at the end of the bulk section. Is there any problem or limitation associated with using this approach? or is it perfectly valid? (pleases note that I don't use multiple images of the same superelement, and I don't need to mirror it or change its position or orientation)
3 - Is there a way to improve the precission of the reduced matrices in DMIG format?

Thanks a lot for your help!

 

[dmapguru]

Before answering your questions, let me lay out some definitions. When you define the EXTSEOUT case control command in a file, the model on which this will act is not an external superelement; it will be used to generate one. As an aside, this model may itself contain superelements (internal or external or both), but the model being run with the EXTSEOUT command is not the external superelement, the data it generates (the boundary matrices, and if you requested CMS, the generalised DOF) are the external superelement.

Now DMIG matrices are a special case when considering external superelements. DMIGs are bulk data entries just like any others, and were available way before the invention of the BEGIN SUPER type superlements, and so they may be “included” anywhere in the bulk data part of the input file for Nastran. As your question 2 broached, you may choose to place the DMIG inside a BEGIN SUPER block (what you refer to as the two file convention (.pch+.asm)), or in the residual structure block. Depending on your choice, they are handled in different ways, always finally being added to the other matrices from elements.

On Q1:
The design intent of Nastran was always to treat the GRAV entry as a load. For the residual structure and superelements alike, if you define a GRAV load and there is mass present, loads will be generated based on the mass distribution. So, if you define a GRAV load in the model with the EXTSEOUT command, and use the DMIGPCH option, the external superelement will be generated with an additional matrix called PAX, which is the reduced load vector for the GRAV loading. At assembly time, if you define a GRAV load for the residual, and you place the external superelement DMIG matrices in a BEGIN SUPER block, along with the P2G=PAX case control entry, the PAX boundary loads will be added to the load vector for the residual structure. For this case, the GRAV load on the residual structure will only use the mass of the residual structure to compute the loads for the residual, i.e. GRAV loads are computed prior to assembling the mass of the upstream superelement.

Now if you place the DMIG matrices in the residual structure block, they are now not considered as external superelements matrices, just DMIGs added to the model, so the mass is added to the residual structure mass prior to computing the GRAV loads for the residual.

I understand the case for wanting to generate loads from the assembled mass in the case of an external superelement, especially if you are not the person who creates the external superelement. Possible solutions are:

1. Generate the external superelement with GRAV loading.
2. Use the BEGIN SUPER block and define a GRAV load within this block. Loads should be generated for the boundary mass.
3. Define a model with only the boundary attachment points of the external superelement present and run this job with EXTSEOUT with the DMIG option and a LOAD= request. You should get the PAX matrix generated for the boundary points.
4. Use DMAP alters. They do exist. If you want to try this route, reply here and I will see if I can find them and post them.

On Q2:
Basically, the BEGIN SUPER approach or injection into the residual structure is a matter of preference, neither is better or worse.

On Q3:
Not without DMAP alters. I have heard of alters that generate 2 sets of DMIGs, one with a shifted set of data to improve the precision of the data. I have not seen these alters myself.

DG

 

[isponmo]

Dear dmapguru,

Thank you very much for your very detailed answer, it is really useful!!

I will take the opportunity to ask a related question: for condensed models in OP4 format, which are included in the subsequent runs with the ASSIGN command (so, contrary to the DMIG case, here the K, M matrices of the superelement are not provided via bulk data entries), is there a way to apply the GRAV load without having to include the GRAV during the condensation run? I ask this because, typically, if somebody sends me an external superelement in OP4 format, it does not include information about any loads.

Thanks once again!

 

[dmapguru]

The short answer is no, not without DMAP alters.

The external superelement path does not assemble the upstream mass until after the loads are generated, i.e. the GRAV loads are based on the J set mass. With alters, you can add the upstream mass, compute the loads, then reset the mass to J set (so the upstream mass doesn't double up). There is a little more to it than this, but not much.

 

[isponmo]

Dear dmapguru,

Once again, thank you for your reply. It is clear now!

It is shame there is no easier way than dealing with DMAP alters.

Kind regards