mystransolver / mystran Goto Github PK

It's hard to read the card. There should be additional rows in the table and then the lines should be hidden. that would prevent this issue on complex params

Adding this would improve compatibility with MSC Nastran and Abaqus/Calculix. The *Beam Section; PIPE option in Abaqus/Calculix is a TUBE2. The math is also trivial.

I suggest adding topics such as finite-elements, fem, fea in the About section at https://github.com/MYSTRANsolver/MYSTRAN.

are there any example files other than what is in the pdfs?

EMG/EMG6/BSMIN3.f90:119: IF (DEBUG(202) > 0) THEN

i propose a markdown list of the 29 active issue tickets. go through and update it every so often, so we don't spin our wheels. If you really want to work on item 29, that seems fine to me, but it's maybe not the highest priority.

In 2017, MSC added a second line option for the PLOAD2. NX has not added this, but since it's a easy thing to do to improve compatibility, why not?

Per the docs:

192 > 0
Print some summary info for max abs value of GP force balance for each solution vector

There is a difference between DEBUG(192) > 0 and DEBUG(192) > 1:

It should be documented, ideally with a picture

It's unclear what each warning corresponds to and it's also wrong (all but GPFO/GPFORCE supports PLOT). It's used by the op2 writer.
op2_plot_mass_bug.txt

celas1_pelas_dir.txt

Nastran supports SPC cards between cases. Mystran does not.

cquad4_pcomp_center.txt
ctria3_pcomp_center.txt

Stress/strain is though. Mystran indirectly calls out bar strain as not being supported, but not similarly for composite plate forces ("Element engineering ... forces for any defined set of elements").

activates Timoshenko bar

Error messages get really bad otherwise

cquad4_bad_quality.txt

Per the F06

The BUG file has some useful data, but there are no NAN checks

Version 15.1.6
In this example, the offset should double the length of the beam, halving its stiffness and doubling its displacement.

SOL 101
CEND
SUBCASE 1
    DISPLACEMENT(PLOT,PRINT) = ALL
    LOAD = 1
    SPC = 2
BEGIN BULK
PARAM       POST      -1
GRID           1              0.      0.      0.
GRID           2              1.      0.      0.
CBAR           1       1       1       2      0.      1.      0.             +C1
+C1                         -0.5      0.      0.     0.5      0.      0.
PBARL          1       1             BAR
              .1      .1      0.
MAT1           1   1.+11              0.
FORCE          1       2              1.  30000.      0.      0.
SPC            2       1  123456
ENDDATA

But the solution is

                                              (in global coordinate system at each grid)
           GRID     COORD      T1            T2            T3            R1            R2            R3
                     SYS
              1        0  0.0           0.0           0.0           0.0           0.0           0.0         
              2        0  3.000000E-05  0.0           0.0           0.0           0.0           0.0         

Displacement of 3e-5 is what you'd get from the original length (1.0), not the doubled length (2.0) according to u = FL/(EA).

celas1_ground1.txt

CELAS1 cards can attach to an artificial ground by leaving the node/component blank.

OFFT defaults to GGG and allows an alternate interpretation for that vector. It supports G0 and x/v. Note that older versions of NX do not support OFFT.

MSC/NX QRG:

Mystran:

This is very unintended nastran behavior. Comments are $, not C. It should crash gracefully.

F06 is correct

cshear.txt

LK1/L1A/LOADB.f90:654: IF (DEBUG(201) == 0) THEN

A set in Nastran/Mystran works as follows:

SET 1 = 1,2,3,10,THRU,20
DISP = 1

However, that only works for the F06/OP2, but not the NEU file (created by PARAM,POST,-1). This is a huge performance penalty because things are calculated twice.

The following card is problematic. Comments should be filtered prior to parsing cards.

$      pid, mid, group, type
PBARL, 10, 20, , TUBE
$31
,1.0,0.9,0.0

And raises an error

PBARL, 10, 20, , TUBE                                                                                                                                                                                                                                           
 *ERROR  1136: REQUIRED CONTINUATION FOR PBARL            ID = 10               MISSING
 *ERROR  1177: PBARL           10               FOR "TUBE    " CROSS-SECTION: INVALID DIMENSIONS FOR CROSS-SECTION                                                               

bar_tube.txt

#64

it affects bars

UTIL/SPARSE_CRS_TO_FULL.f90:105: IF( DEBUG(205) > 0) CALL DEBUG_CRS_TO_FULL

Minor bug, but date is called out as;
date = (3, 24, 21)

so March 24, 2021.

cbar_stress[(1, 1, 1, 0, 0, '', '')]
type=RealBarStressArray nelements=4
data: [1, ntotal, 15] where 15=[s1a, s2a, s3a, s4a, axial, smaxa, smina, MS_tension, s1b, s2b, s3b, s4b, smaxb, sminb, MS_compression]
data.shape = (4, 4, 15)
element.shape = (4,)
element type: CBAR-34-34
sort1
lsdvmns = [1 2 3 4]; dtype=int32

The code is as follows:

(isubcase, analysis_code, sort_method, count,
 superelement_adaptivity_index, pval_step, table_name_str)

For a modal problem, analysis_code = 2, which will simplify the op2 output

Stresses are weirdly fine though.
BAR-I12.txt

Even something simple like displacement isn't created. The file wasn't opened.

BAR-I12.txt

If it's unused, I shouldn't get an error

$PID MID1 TM MID2 12I/TM**3 MID3 TS/TM MPA
$Z1 Z2
$PCOMP PID  Z0 NSM    SB FT TREF GE LAM
$      MID1 T1 THETA1 SOUT1
$      MID2 T2 THETA2 SOUT2

$PCOMP PID  Z0 NSM  SB FT TREF GE LAM
PCOMP, 91,  ,  0.1
,      20, 0.1, 0.0,  0.
,      20, 0.2, 45.0, 0.
,      20, 0.3, 90.0, 0.
$

Per Mystran Manual

Per the NX QRG

Pressure is the standard way to apply loads to a solid model. There are some additional options for MSC Nastran, so we'll go with the simpler one for now (they're also compatible).

The mystran QRG:

The NX Nastran QRG:

This should be a pretty straightforward recovery given the stresses should be calculated at the integration points exactly. Stresses should then be extrapolated to the nodes. Not having this makes the stresses artificially low.

I don't know what the order of the polynomials is for the different elements (CTETRA, CPENTA, CHEXA) or if it changes based on the number of nodes/integration method, but hopefully wherever the centroidal stress is calculated, there's a pretty straightforward recovery step that can be easily extended.

The following problem can't be analyzed because Mystran lacks the PLOAD1 card.

The card is as follows

Currently we're only handling the case where N is defined. It's very common to use a range as well, which requires a dynamic number of modes as output.

We don't necessarily need to handle all cases, but they shouldn't cause memory issues. It would be very nice to though.

Note that all blank results in 1 mode.

This is held up by the way GPFORCE was implemented.

The OP2 needs to be written in a single block, so the F06 writing would need to be refactored to calculate all the output before the write step vs. calculating each node and then printing. That would help OP2 integration.

this is incomplete, but it's a start

https://github.com/MYSTRANsolver/MYSTRAN/blob/main/dev_docs/post_processing.md

Bar stresses are included, but no header is written. Thus it's really confusing what is going on. It's expected that none of this would be written.

BAR-I12.txt

The manual defines wa, wb here (note that the quality is low in the manual)

and then doesn't use wa, wb (it calls them w1 and w2)

Furthermore, there it is unclear that wa/wb must be defined in the global coordinate system. It should be stated.

Strain energy is super useful. Please add. The frequency stuff is not applicable, but THRESH is super useful to avoid small strain energy output. Either way is fine for v1

Per the NX QRG:

cquad4_pcomp_center.txt

nastran is case insensitive

The mcid option (integer) on the theta/mcid is not supported. The default is theta=0.0. Anyways, the MCID/material coordinate system is the preferred way to specify a coordinate system for an orthotropic (e.g., carbon fiber composite) material.

The math is below:

MICD (material coordinate system)

n = normal
i = x-axis of material coordinate system
jmat = cross(normal, i) # k x i
jmat = jmat / norm(jmat)
imat = cross(jmat, normal)

Theta (element coordinate system)

imat = xyz2 - xyz1
imat = imat / norm(imat)
jmat = cross(normal, imat) # k x i
jmat = jmat / norm(jmat)

The Mystran QRG has:

The MSC Nastran QRG has:

Also for completeness, almost nobody uses the tflag and differential thicknesses

Mass is given in the basic frame vs. the node's local frame. This is inconsistent with MSC/NX Nastran.

The BDF is attached.

op2_plot_mass_bug.txt

Code should crash if a continuation marker isn't found instead of dropping the second line.

Per NX QRG

Per mystran:

The updated error should be:

See: missing_continuation.txt

Unnecessarily writing a special character leading to more difficult parsing for users. Not everyone knows how to work with unicode, even if some people do.

If the input file has it, fine, but it should not be added by Mystran for a grid point forces table.

I propose changing the U double dot to an A (for acceleration). The capital letter is nice because it won't clash with the a-set, Ua. Note that Ug is seen in the picture. Based on context of inertial force (F=ma), it should be pretty obvious.

I'm calling this documentation, but it's file documentation.

EB-ALL-ELEM-TEST-LANCZOS-MODE-2-DPB.txt

This example was from the benchmark tests. This is a regression that was not seen in 15.1, but is seen in 15.1.1 and subsequent versions.

15.1.1

displacements[0]
  isubcase = 0
  type=RealDisplacementArray ntimes=1 nnodes=13, table_name=OUGV1
  data: [t1, t2, t3, r1, r2, r3] shape=[1, 13, 6] dtype=float32
  node_gridtype.shape = (13, 2)
  sort1
  modes = [2]; dtype=int32
  eigns = [359293.219]; dtype=float64
  mode_cycles = [599.411]; dtype=float64

displacements[1]
  isubcase = 1
  type=RealDisplacementArray ntimes=1 nnodes=13, table_name=OUGV1
  data: [t1, t2, t3, r1, r2, r3] shape=[1, 13, 6] dtype=float32
  node_gridtype.shape = (13, 2)
  sort1
  modes = [1]; dtype=int32
  eigns = [175725.922]; dtype=float64
  mode_cycles = [419.197]; dtype=float64

15.1

displacements[1]
  isubcase = 1
  type=RealDisplacementArray ntimes=1 nnodes=13, table_name=OUGV1
  data: [t1, t2, t3, r1, r2, r3] shape=[1, 13, 6] dtype=float32
  node_gridtype.shape = (13, 2)
  sort1
  modes = [1]; dtype=int32
  eigns = [175725.922]; dtype=float64
  mode_cycles = [419.197]; dtype=float64

DEBUG,200,1 is weird. This is useful, so it should also be a PARAM. It's also like 10 seconds to add.

In the RBE3 derivation section:

"Substitute equation 3 into 12" should be "Substitute equation 3 into 13"

Eqn. 11-10 2nd term's dz should be dx

Equation between 11-13 and 11-14 has the same error as 11-10

Eqn. 11-14 2nd line signs of 2nd and 3rd terms are reversed. Should be consistent wtih 11-15.

Eqns. 11-21 to 11-25 use e-bar with an i superscript. I think they shouldn't have the superscript and are the same 3 variables used in equations 11-26 and 11-28 without the i.

I think the first 3 rows of R_di in equation 11-30 should be negated. It looks like they come from the 4th terms in equations 11-15 which have a negative sign. This corrects some opposite sign displacements I was getting when I used the matrices directly.

Apparently there should be 3 separate sums of weights WT, not just one like the manual shows.
https://www.mystran.com/forums/showthread.php?tid=77&pid=287#pid287

In other sections:

p74 says "This is very different than the RBE3 which is a rigid element.". It should say RBE2, not RBE3.

p93 "Specify G1-G8 for a 4 node HEXA" should be 8 node.

p170 Default value for "CID Material coordinate system ID" is "0." but should be an integer without the ".".

p174 Format for RBE3 looks like it requires 3 grid points for WT1, 4 for WT2, and 2 for WT3. It's not clear that this is just an example and you can use different numbers. MSC puts "-etc.-" in some fields to show that.

Frequent use of "grid" instead of "grid point".

op2_plot_mass_bug.txt

This case will generate a mass, but if you comment out one of the (inconsistent) params, it will not.