umvarma / pynastran

Automatically exported from code.google.com/p/pynastran
1 stars 0 forks source link

The code should at least tolerate GPSTRESS / GPSTRAIN #128

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Apparently Nodal Stesses are not supported (btw - they are very useful!). Still 
the bdf-reader and -writer should tolerate bdfs with existing Output requests 
for Nodal Stresses. Issues after I/O of the attached model are:
- In Subcase 1, GPSTRESS request is replaced by GPSTRAIN
- End of Subcase 2 is not detected properly (explained below, OUTPUT(POST) is 
NOT part of a Subcase!!!)

The logic for Calculation of Element results at GRIDs is:
- output requests can be made for each Subcase, e.g. by GPSTR{AIN|ESS}
- At the end of the Case Control Section (i.e. AFTER the last Subcase) there 
has to be a definition of every output request. This Section is part of the 
Case Control Section and begins with the Keyword OUTPUT(POST). A part of the 
mesh for output request can than be defined by either a SURFACE or a VOLUME

Lars Heinrich
German Aerospace Center (DLR)
Experienced Nastran User

Original issue reported on code.google.com by lars.b.h...@gmail.com on 4 Jul 2013 at 12:47

Attachments:

GoogleCodeExporter commented 9 years ago
Are you having issues with the OP2 or just the BDF?

Also, I'm confused by the statement "At the end of the Case Control Section 
(i.e. AFTER the last Subcase) there has to be a definition of every output 
request.  This Section is part of the Case Control Section and begins with the 
Keyword OUTPUT(POST)."

The GPSTRESS/STRAIN bug is fixed in the v0.6 branch, but I still need to look 
into the OUTPUT(POST) issue.

Original comment by mesheb82 on 7 Jul 2013 at 11:05

GoogleCodeExporter commented 9 years ago
There seems to be an issue with Nastran not writing the GPSTRAIN data to the 
OP2.  It would be nice to support GPSTRAIN, but I'd need a model that makes the 
appropriate F06 and OP2 data section.

If you search for "WRITTEN ON FORTRAN UNIT 12, TRL =" in the F06, you'll see an 
extra block "OGS1" when you use GPSTRESS(PLOT,PRINT,SORT1)=ALL vs 
GPSTRAIN(PLOT,PRINT,SORT1)=ALL.  It appears GPSTRAIN does nothing.

Original comment by mesheb82 on 8 Jul 2013 at 6:45

GoogleCodeExporter commented 9 years ago
@#1:

I'm only referring to the BDF. My problem occurs when reading a bdf and 
directly writing it out again.(BDF.read_bdf(bdf_path, xref=True) and 
BDF.write_bdf(os.path.splitext(bdf_path)[0]+'_2.bdf'))

Trying to resolve confusion: Are you familiar with the logic of the "Case 
Control Section"? It is divided into Subcases. BEFORE the first Subcase, there 
may be statements like "SPC=1" or "DISP=ALL", that apply to all Subcases 
(unless overwritten!). This is not directly related to my issue, but I also 
observed a problem when "STRESS=ALL" was requested in this manner (it was not 
written out again!). Now, coming to my issue: reading and writing the posted 
deck gives me a couple of issues:
- In the linear statics subcase, GPSTRESS is replaced by GPSTRAIN (so far, I 
only worked with GPSTRESS, if GPSTRAIN gives the same thing, everything is 
fine!)
- The (second) linear buckling subcase is messed up, i.e. the definition of the 
SURFACE for calculation of GPSTRESS appears in the Subcase, but it is not part 
of this Subcase. Explanation: The OUTPUT(POST) statement denotes the end of the 
last Subcase and indicates that on the following lines are statements related 
to the GPSTRESS output request(s). The only statements possible are SURFACE or 
VOLUME with corresponing SETs. The corresponding section in the QRG is a bit 
hard to find, just go to the beginning of Parameters and scroll up a bit...

Hope this helps!
Lars

PS: attached is the rewritten bdf with the described issues.

Original comment by lars.b.h...@gmail.com on 20 Aug 2013 at 2:40

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by mesheb82 on 9 Feb 2014 at 9:36