Centroidal vs. bilinear data on various element types

[Matthew U]

Hey Steve,

Sorry to bug you again. I have noticed some unique ways which pynastran treats different element types in terms of centroidal vs. bilinear results and wanted to understand if it is by design.

I noticed in the documentation that you meantioned ctria3 elements are always centroidal. But I have also noticed through running some trades that ctria6 elements seem to always be bilinear. Is there a reason for this? Even if I do not request corner data in by op2 file, the ctria6 results still show up as 'type=RealPlateBilinearForceArray'. Are there any other unique cases of centroidal vs. bilinear data that I have not caught yet?

Thanks for your help,

Matt

[Steven Doyle]

Matt,

I definitely don't know all Nastran's eccentricities, but I guess starting off, the NX/MSC CQUAD4-33 (PSHELL centroidal) and the NX/MSC CQUAD4-144 ( PSHELL bilinear) use the same formulation.  It's just a different way of writing the data.  The CTRIA3-74 has a constant strain, so there's only 1 result per element.  There are two sets of higher order elements (CTRIA6/R, CQUAD8/R and CQUAD/CQUAD9).  For years I only knew about the first set and those  have N//2 + 1 results (so 3+1 for a CTRIA6/CTRIAR).  I believe the second set is related to NX solution 400 and those also have only 1 output location.  That's about the point you start seeing differences between NX and MSC in terms of element numbers.

As to your question, yes it is by design that there are two classes for the same type element (PSHELL).  If the full results were recoverable, then I would have no problem with it being less transparent, but you can only go one way because you don't have the gauss point results.  Basically, you need to understand your data in order to get the right answer.

NX recently added a new solid output format that doesn't include the centroid, 9 principal direction components (3 vectors) and I believe also leave off mid/max/mid principal stresses/strains. As far as I can tell that's a  runtime optimization and I'm on board with it.  Those classes can convert between each other.

--
You received this message because you are subscribed to the Google Groups "pyNastran Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynastran-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pynastran-discuss/732e3201-34e5-4bcf-893c-61deb8209a4cn%40googlegroups.com.