Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Latest Threads
Inertial relief in Mystra...
Forum: MYSTRAN
Last Post: Maxime56
10-31-2024, 11:23 PM
» Replies: 2
» Views: 165
Composite orientation
Forum: MYSTRAN
Last Post: Admin
08-06-2024, 11:50 AM
» Replies: 2
» Views: 583
Concern about RBE3
Forum: MYSTRAN
Last Post: Admin
01-25-2024, 11:12 PM
» Replies: 2
» Views: 2,728
Abaqus/CCX to MYSTRAN/Nas...
Forum: MYSTRAN
Last Post: Admin
01-25-2024, 01:52 PM
» Replies: 0
» Views: 1,450
15.1.0 Update
Forum: MYSTRAN
Last Post: borges
12-19-2023, 02:50 PM
» Replies: 0
» Views: 1,451
15.0 Released - Major Upd...
Forum: MYSTRAN
Last Post: borges
12-19-2023, 02:46 PM
» Replies: 1
» Views: 2,282
New User facing issues
Forum: MYSTRAN
Last Post: Admin
12-12-2023, 06:11 AM
» Replies: 1
» Views: 2,122
Femap model hard crash
Forum: MYSTRAN
Last Post: borges
12-02-2023, 08:41 PM
» Replies: 0
» Views: 1,610
Converting MSC Nastran In...
Forum: ComLab and NASTRAN-95
Last Post: ceanwang
03-28-2023, 09:47 PM
» Replies: 1
» Views: 4,743
ComLab (an improved NASTR...
Forum: ComLab and NASTRAN-95
Last Post: Admin
12-13-2022, 04:55 AM
» Replies: 2
» Views: 9,246

 
  Inertial relief in Mystran
Posted by: Maxime56 - 10-29-2024, 03:05 AM - Forum: MYSTRAN - Replies (2)

I am currently evaluating Mystran and am particularly interested in understanding whether it offers an "inertial relief" feature similar to that in Nastran. I have cases with unrestrained structures under applied loads. Could you let me know if Mystran supports this functionality or if there are alternative methods to achieve a similar effect?

Print this item

  Composite orientation
Posted by: trilbytim - 08-03-2024, 12:30 PM - Forum: MYSTRAN - Replies (2)

I've been trying to modify the Mystran writer in FreeCAD to write composite cases with orthotropic material and composite laminate cards. I've been referring to the MSC Nastran "Quick" Reference Guide (all 3417 pages of it!). I'm calculating orientation angle relative to the element reference direction as described in the guide. I think I now have this working. I'll share the code when I get it less hacky, eventually I want to read a ply book from a spreadsheet, at the moment I'm hard coding everything just to test it.

It creates a .bdf file which does solve (hooray!), however the results aren't right (boohoo!). I've attached a very simple test file (.txt extension added to allow it's upload to this forum, remove to use). You can see from the PCOMP card (line 41 onwards) that I have the ply orientations all set to 45 degrees. Since this is unbalanced (there are no -45 plies) then there should be strong bend-twist coupling, so the deformed shape should show some twist, but it doesn't. Also if you manually change the values of the plies to all 0 or all 90 and re run then there is nothing like enough difference in the deflection. The difference in modulus between the two directions is about 20x, so the deflection should be an order of magnitude lower for the 0 degree case than the 90 degree case. However they're coming out very similar.

Something clearly isn't being applied correctly. I'm not sure if this is the element orientations, the PCOMP card or the MAT8 card. Any ideas, I'm a bit stumped?



Attached Files
.txt   FEMMeshGmsh.bdf.txt (Size: 1.74 KB / Downloads: 0)
Print this item

  Abaqus/CCX to MYSTRAN/Nastran Converter
Posted by: Admin - 01-25-2024, 01:52 PM - Forum: MYSTRAN - No Replies

pyNastran has an Abaqus to Nastran converter (so it works with CalculiX and MYSTRAN as well). In the event that you don't want to install pyNastran and just want something simple and quick...see this link (courtesy of Bruno).

ABAQUS to Nastran converter:
https://bor.gs/inp2nas/

Print this item

  Concern about RBE3
Posted by: Victor - 01-25-2024, 03:12 AM - Forum: MYSTRAN - Replies (2)

I'm trying to implement my own RBE3 according to the Mystran manual and I've noticed something that looks like a familiar type of wrong behavior. I'm not really sure if it is wrong or not or if Mystran also behaves this way. I haven't used Mystran before but I'd like see what other people think of it before setting up Mystran and learning how to define a model.

In my implementation, when I apply a moment load about the x axis, it causes the correct moment about x but also another moment about the y axis as shown in the attached picture. Note that the independent nodes are on an inclined face, not in a plane normal to the applied moment.

If you've used RBE3 before, would you expect this beam to bend as well as twist?

I'm suspicious of this because CalculiX has a similar issue with its moment loads on beams which are internally converted to MPCs similar to an RBE3.



Attached Files Thumbnail(s)
   
Print this item

  15.1.0 Update
Posted by: borges - 12-19-2023, 02:50 PM - Forum: MYSTRAN - No Replies

This minor update adds a drilling stiffness for our 5-dof shells (QUAD4s and TRIA2s), the parameter K6ROT.

We separated this from 15.0 so people could have a "clean" release without this new feature, since verification efforts are still ongoing.

You can get the Windows and Linux binaries at https://github.com/MYSTRANsolver/MYSTRAN...tag/15.1.0 !

Print this item

  15.0 Released - Major Update
Posted by: Admin - 12-19-2023, 02:14 PM - Forum: MYSTRAN - Replies (1)

15.0 has just released. This is a significant update done by Bruno and mostly consists of memory bug fixes. Bruno is also making a major effort to continue to improve MYSTRAN in the coming months. The details for 15.0 are here (https://github.com/MYSTRANsolver/MYSTRAN/pull/9) and a quick summary is as follows:

All models in our current benchmark set now run without any illegal memory operations. So do other models that used to cause trouble, like cshear.bdf (part of the build verification suite) and large_shelled_beam.bdf (user-reported, I think). That doesn't mean results are necessarily correct. Not all bugs are memory bugs! But this update means that many models that used to trigger nondeterministic behaviour and/or crashes now run to completion. This way, we can actually get the results to verify they're correct, and also work on new features unencumbered by crashes.


------- SOME DETAILS --------

 - ELMOFF was comparing QUAD4 areas to an uninitialized EPS1, causing it to think positive areas were negative. The fix: initialize EPS1 to be EPSIL(1) as everywhere else does.

- GPWG had some debug prints that tried to write the value of ITABLE before it was set. The fix: move the initialization of ITABLE a couple lines up.

- ANY_U_P_OUTPUT, a variable with all assignments and uses commented out, appeared on an IF statement, thus sometimes being read even though it was never set. The fix: comment it out of the IF statement as well.

- there was a faulty conditional in the SuperLU version we were using, causing crashes when the global stiffness matrix was singular. The fix: so we changed to a more recent state of their repository since the fix was recent.
 
- a small oversight in indexes used to print CSHEAR engineering forces in WRITE_ELEM_ENGR_FORCE caused a buffer to be read past the part that actually held values. The fix: make the indexes consistent with the initialized part.

- OP2 code in WRITE_ELEM_STRESSES forgot to set a value called STRESS_CODE, used to indicate what's about to be written. The fix: put in a placeholder value for now -- there's other placeholder values in that same subroutine anyway.

- a missing ELSE was causing a fatal error to be issued for valid models containing CSHEAR cards with a nonzero OCID. The fix: added the ELSE.

- the subroutine GET_KE_OFFSET was communicating the wrong shape of BUSH element parameters (KEO_BUSH) to a matrix operation (MATPUT). The fix: communicate the correct shape.

- a post-deallocation subroutine was being called for the matrix I2_GMN regardless of whether it had been just deallocated or not, triggering a bad read. The fix: move the call into the conditional for whether I2_GMN was just deallocated.

- the SCNUM vector, containing subcase numbers, was being allocated with the wrong size, resulting in an overflow when it was written to. In MODES solutions, the "subcases" are the number of requested eigenvectors. The fix: set LSUB, which determines the maximum number of subcases in the solution, as soon was we see the EIGR bulk data card "chosen" by the METHOD case control card during LOADB. This way, all subsequent (i.e. after LINK0) allocations of SCNUM will be the correct size. There are no writes to SCNUM that could overflow before, since we set the size before the limit is even communicated to the rest of the program.

- same as above, but for EIGRL cards and the OGROUT vector. The fix: same as above, but setting LSUB as soon as we see the right EIGRL card during LOADB.

- a debug write was reading from an uninitialized variable depending on the requested data. The fix: initialize it just like in similar requests.

- okay, so, when a BUSH element has negative OCID (or the continuation card is absent), that means we use the GA-GB line as the x-axis for computing offsets. However, when GA and GB coincide, that line can't be computed, but an attempt was being made to compute them anyway, resulting in some nasty memory bugs. The fix: detect zero-length BUSH elements with negative OCID and mark them as non-offset, thus avoiding the problematic computations.

Print this item

  New User facing issues
Posted by: avi7 - 12-12-2023, 04:41 AM - Forum: MYSTRAN - Replies (1)

As stated above I'm a very new user. Just installed and started using MYSTRAN since yesterday. I have a very simple static analysis case that I wanted to run as a trial. Here's the error I'm getting:

Code:
LINK  3 BEGIN
dgstrf() error returns INFO= 2101
L\U MB 6.750    total MB needed 7.648
*ERROR  9903: SUPERLU SPARSE SOLVER HAS FAILED WITH INFO =         2101 IN SUBR SYM_MAT_DECOMP_SUPRLU CALLED BY SUBR LINK3
CHECK F06 OUTPUT FILE FOR        1 FATAL MESSAGE(S)
CHECK ERR OUTPUT FILE FOR        2 WARNING MESSAGE(S)
Processing terminated. Check for error messages in output file:
Test.F06
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

The error in .F06 is basically the same:
Code:
>> LINK  3 BEGIN

*ERROR  9903: SUPERLU SPARSE SOLVER HAS FAILED WITH INFO =         2101 IN SUBR SYM_MAT_DECOMP_SUPRLU CALLED BY SUBR LINK3

Please tell me if there's something I need to change. The test case is very simple.

Print this item

  Femap model hard crash
Posted by: borges - 12-02-2023, 08:41 PM - Forum: MYSTRAN - No Replies

[Posting here too for archival purposes]

While working on K6ROT, I decided to run a simple Femap 2x2 flat plate model on MYSTRAN.

This triggers a nondeterministic crash: half of the runs yield a segfault, the other half finish with a fatal error when calling the SuperLU matrix factorization subroutine.

Of course, these decks were auto-generated by Femap, so they're nowhere near hand-crafted quality. Still, no deck, no matter how corrupt, should trigger an illegal memory access.

Attached are two version of the deck: the one exported from Femap as-is, and another with some slight changes to make it more affable to MYSTRAN (to no avail).

Something in this deck is causing MYSTRAN to pass bad data to SuperLU. I'm looking into what, how, and a fix -- but any input is appreciated.

Thanks!



Attached Files
.txt   plate_upforce.txt (Size: 3.98 KB / Downloads: 0)
.txt   plate_upforce_changed.txt (Size: 3.98 KB / Downloads: 0)
Print this item

  Converting MSC Nastran Input Deck to NASTRAN-95
Posted by: fontanj - 12-18-2022, 01:11 AM - Forum: ComLab and NASTRAN-95 - Replies (1)

Hi All,

Does anyone have experience converting an MSC or NX Nastran input deck to a format NASTRAN-95 can read?

Here are some of the things I've done and I think it has got me most of the way there:
-insert lines from "INCLUDE"-ed files
-added an "ID" card at the top
-changed SOL 101 to SOL 1
-replaced CBEAM and PBEAM cards with CBAR and PBAR cards (luckily my model doesn't use advanced CBEAM functionality)
-replaced CBUSH and PBUSH with a set of CELAS1 and PELAS elements
-made sure my coordsys ID numbers on the CQUAD4 and CTRIA3 elements are < 1,000,000 (NASTRAN-95 manual specifies this)
-converted all my line continuations to labeled line continuations with a unique label for each one
-changed the names of my RBE2 and RBE3 elements to CRBE2 and CRBE3

Now the CRBE3 elements seem to be giving me trouble. I am getting singular columns in the stiffness matrix, and for  of my RBE3 reference gridpoints, it says "EXTERNAL GRID PT. .... NOT CONNECTED".

The only way these grid points are intended to be connected to the model is through the RBE3 elements. They are used to distribute a point-force (applied at the RBE3 reference grid point) to other nodes. Does NASTRAN-95 not allow this?

Thanks,
Josh

Print this item

  Mystran and Intel One API 2022
Posted by: realbabilu - 11-09-2022, 01:27 AM - Forum: MYSTRAN - Replies (7)

Hi everyone,

I just new at mystran this year.
For information Intel One API now is free for everyone. Including the Math Kernel Library ,and Vtune
The c++ compiler for compiling SuperLu and fortran compiler for compiling Mystran can be downloaded at https://www.intel.com/content/www/us/en/...nents.html
The MKL can be downloaded at https://www.intel.com/content/www/us/en/...nload.html
alternatively OpenBlas also can be used https://github.com/xianyi/OpenBLAS/relea...21-x64.zip
The Intel compiler required free Visual Studio Community https://visualstudio.microsoft.com/vs/community/
I still learn to create makefile using Cmake for VS and the GCC equations.com. so i jumped without CMAKE

A. USING Visual Studio Windows
Steps :
1. Compile SuperLu.Lib in SRC superlu with c_fortran_dgsvv.c with

Code:
icl -c *.c /O3 /Qpar
with modified Slu_cnames.h for creating obj, then
Code:
xilib /out:superlu.lib *.obj
    compile with optimization like /QaxCORE-AVX2 for intel or /QxCORE-AVX2 for AMD may improve the speed, and /Qpar for parallel run
2. Create the StandardConsole / Quickwin Fortran project
3. Drag all fortran subroutine excluding the "Source\Modules\LAPACK\Unresolved_Externals_Problem" since we will use Openblas / MKL AND  *.H files in include folder
    to the Solution Explorer - Source Files
4. Edit GET_MYSTRAN_DIR.f90
   
Code:
CALL GETENV ( 'MYSTRAN_directory', MYSTRAN_DIR )
to 
Code:
CALL get_environment_variable  ( 'MYSTRAN_directory', MYSTRAN_DIR )
    Hope this call get_environment_variable is used in the next mystran, since it used also in gcc.
5. For mkl --> in Solution --> right click Properties » Configuration properties » Fortran  » Use Intel MKL » Sequential or Parallel  --> if /Qpar then Parallel
    For OpenBlas drag Openblas.dll.a and with all *.h to the Solution Explorer - Source Files
    compile with optimization like /QaxCORE-AVX2 for Intel or /QxCORE-AVX2 for AMD may improve the speed
6. For big problems, it could catch stack overflow, move all stack to heap.
  in Solution --> Properties » Fortran » Configuration properties » Optimization » Heap Arrays » 0
7. You will get the exe file.

B. Using command line Intel compiler x64 enviroment
a. Get mystran latest source code put in d:\mystran --> d:\mystran\mystran-main\
a. Get superLu latest, put on SRC folder with FORTRAN d_fortran_dgssv.c  and modified SLU_Cnames.h on SuperLu folder d:\mystran\mystran-main\superlu
b. Get into CMD command lines intel x64 Compiler
c. Get 2 Batch file to run in d:\mystran
    compile_mystran_superlu_with_mkl_AVX2_Parallel.bat https://controlc.com/f266943f
    mystran.rsp  https://controlc.com/32578204
d. Get mystran.exe inside x64/Release


Questions
1. SuperLu-MT cant be used here, right?
2. Can i get the built MingW GCC makefile? that compiled in msys or mingw, so i can changed to be compiled in the equations mingw compiler

NOTE: Modified SLU_Cnames.h inside SRC SuperLU dir for Visual Fortran
Code:
/* Fortran interface */
#define c_bridge_dgssv_ C_BRIDGE_DGSSV
#define c_fortran_sgssv_ C_FORTRAN_SGSSV
#define c_fortran_dgssv_ C_FORTRAN_DGSSV
#define c_fortran_cgssv_ C_FORTRAN_CGSSV
#define c_fortran_zgssv_ C_FORTRAN_ZGSSV

Print this item