Hello, I performed model reduction using SOL103 DMIGPCH format. EIGRL method GRAV or ACCEL loads, Point Loads are applied on the reduced model, Analysis is performed using SOL101. From the f06 file, OUTPUT from Weight check matches to the physical model. OLOAD resultant, SPC force resultant, displacements from the GRAV loads shows zero. What could be the reason? for your info: I performed the same process OP4 format, very thing works out well. Thanks, Prasad.

Model reduction using SOL103, DMIG PCH Format

prasad.guduguntla.external over 7 years ago

Hello,

I performed model reduction using SOL103 DMIGPCH format.

EIGRL method

GRAV or ACCEL loads, Point Loads are applied on the reduced model, Analysis is performed using SOL101.

From the f06 file, OUTPUT from Weight check matches to the physical model.
OLOAD resultant, SPC force resultant, displacements from the GRAV loads shows zero. What could be the reason?

for your info:

I performed the same process OP4 format, very thing works out well.

Thanks,

Prasad.

0 Don.Graff over 7 years ago

Hi Prasad,

I see you haven't had a reply to your question yet, so I'll try to help. In general, I suggest doing a sample first to test out this process, and if there are issues, to contact technical support so we can assist. Having a sample you can send us to run start to finish really helps in the debugging stage.

The first thing to point out is it is necessary to apply the GRAV loading during the creation of the external SE. For the residual structure, GRAV loading gets applied prior to the upstream mass being included. This approach can be problematic, as the upstream subcase needs to be 'aligned' with the downstream subcase for the upstream loads to combine correctly with the downstream loads.

Creating the external SE using the op4 or op2 method seems to work well for GRAV type loading. When using the pch format of storing the reduced matrices, remember you must add the P2G=PAX case control command (along with the M2GG/K2GG commands). This applies the upstream loading due to the GRAV effects.

Regards,

Don

P.S. This all assumes you are using the EXTSEOUT method of creating the external SE, and that you are using the .asm and .pch files for the assembly run.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 prasad.guduguntla.external over 7 years ago

Hi Don,

Thanks for your reply.

My requirement is to deliver the SE with out any loads included. So that the loads could be applied during the assembly run. The method you suggested to include the loads during the creation of SE, I already tried it before and it works.

I found the solution to my problem.

(As mentioned previously, i applied the GRAV loads on the condensed model and i don't see any result in terms of OLOAD and SPC FORCE resultant.)

During the Assembly run, In the BULK data first I defined the Load card and then *.asm, *.pch files.. This leads to the zero values in OLOAD and SPC resultant output.

In the assembly run, modified the order of cards and it works . --> After the condensed includes, i defined the load card.

To my knowledge, Nastran considers all the BULK data entries…irrespective of order of cards.

Is there any defined order to include the cards during the usage of condensed models?

Thanks,

Prasad.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Don.Graff over 7 years ago

This is a special situation, and it does work for the DMIGPCH method of storing the reduced matrices, but it doesn't work for the DMIGOP2 method of storing the reduced matrices. The reason it works for the pch method is the .pch file MUST be last in the assembly run, since it has a BEGIN SUPER definition. This is why if you have multiple external SE, you would include all the .asm files first, then all the .pch files.

Since you put the GRAV loading after the .pch include, it is applying the GRAV loading on these reduced matrices. This likely only works for the DMIGPCH method, though I haven't tested the op4 method... I did test the DMIGOP2 method and it didn't work.

Another consideration- the recovery of upstream results... I had tested this in the past, and while the upstream internal displacements were good, the upstream internal stresses were not. As long as you aren't expecting upstream stress data recovery, then this ought to be fine.

FYI- the reason the OLOAD, etc was null when the GRAV was above the .pch include is the upstream mass isn't yet include in the assembly run, as the time the GRAV loading is being considered... think of it as being for the Residual only, not the Assembly. If there were Residual mass, then that portion only would get the GRAV loading. The Residual is the portion of the model that is physical (SE 0) prior to assembly of any upstream SE.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel