Solver for Mystran
Moderator: bernd
Forum rules
and Helpful information for the FEM forum
and Helpful information for the FEM forum
Re: Solver for Mystran
I started to post on Mystran forum too. They migth know some stuff better than we do. Even if some of them reading here anyway ...
bernd
bernd
Re: Solver for Mystran
You can reach the author of pyNastran at Elmer discord server. It has a pyNastran channel. Here is a link, not the direct one. https://discord.gg/AVCUvuzsqp
Or its github.
Or its github.
-
- Posts: 118
- Joined: Fri Apr 09, 2021 3:26 am
Re: Solver for Mystran
That model is broken, not mystran.
Try a different one.
Try a different one.
Re: Solver for Mystran
what does mean broken? What exactly is wrong with this model? Is the pyNastran already wrong or ist the bdf solver input wrong? Are the elements somehow wrong (the node order?) or is something other wrong?aerospaceweeb wrote: ↑Sat Jul 24, 2021 2:27 pm That model is broken, not mystran.
Try a different one.
I could try to set up a very small modell with tetra10 elements (or even just one tetra10 element) if this would be easier to tackle down?
Or do you have some simple tetra10 example which runs fine in Mystran. Such example I could try to remodel and find the error.
cheers bernd
-
- Posts: 118
- Joined: Fri Apr 09, 2021 3:26 am
Re: Solver for Mystran
Bernd,
Sorry for the brief response, I was talking with Steve and Bill about it, and they weren't 100% sure what was wrong yet. Now we're pretty sure that the tet element is "inverted" if that makes any kind of sense.
We know that because we tried opening it in FeMap, the enterprise FEM pre/post software and it didn't work.
It looks like the nodes are in a wrong order, and the bug is in pynastran, not mystran. We checked that using pynastrans gui.
The file that you have says
But it should be in the order: 40, 10, 19, 20, 196, 106, 168, 171, 107, 66; like the image below would have it.
The best way I've seen it explained is like this.
"the first 3 points define the normal of the element and must point towards the 4th node. Then the base midside nodes and then finally the midside nodes towards the top."
Sorry for the brief response, I was talking with Steve and Bill about it, and they weren't 100% sure what was wrong yet. Now we're pretty sure that the tet element is "inverted" if that makes any kind of sense.
We know that because we tried opening it in FeMap, the enterprise FEM pre/post software and it didn't work.
It looks like the nodes are in a wrong order, and the bug is in pynastran, not mystran. We checked that using pynastrans gui.
The file that you have says
Code: Select all
CTETRA 149 1 40 19 10 20 168 106
196 171 66 107
"the first 3 points define the normal of the element and must point towards the 4th node. Then the base midside nodes and then finally the midside nodes towards the top."
-
- Posts: 118
- Joined: Fri Apr 09, 2021 3:26 am
Re: Solver for Mystran
Also, for anyones usage, I've attached here the zip file of the mystran test models from release 12.1, which is the last stack of models that I had on hand.
We'd very much appreciate more models to add to the stack, so if anyone reading this at any point in the future makes any mystran models and runs them, send us/me the model! We'd love to have it.
We'd very much appreciate more models to add to the stack, so if anyone reading this at any point in the future makes any mystran models and runs them, send us/me the model! We'd love to have it.
- Attachments
-
- Mystran_Test_Models.zip
- (112.49 KiB) Downloaded 36 times
-
- Posts: 118
- Joined: Fri Apr 09, 2021 3:26 am
Re: Solver for Mystran
I've just realized that the FreeCAD Tet format is the opposite of what it is in nastran. That's unfortunate, but good to know. I hadn't realized.
https://wiki.freecadweb.org/FEM_Mesh FreeCAD appears to be opposite of Abaqus as well as nastran. I'm curious how it got to be this way.
https://abaqus-docs.mit.edu/2017/Englis ... 3delem.htm
https://wiki.freecadweb.org/FEM_Mesh FreeCAD appears to be opposite of Abaqus as well as nastran. I'm curious how it got to be this way.
https://abaqus-docs.mit.edu/2017/Englis ... 3delem.htm
Re: Solver for Mystran
AFAIK it does not matter is if is upside down. More important is the node order of the faces. FreeCAD uses right hand side thumb shows to face normaland your fingers shows the direction. (if the thumb shows to your nose it is counterclock) Face 1 for FreeCAD is N1, N2, N3 but for the Tet in Nastran ride hand side thumb to face normal it is N1, N3, N2, Thus the node order is different ... Damn I missed this. I had a view and came up FreeCAD an Nastran uses same node order but they do not.aerospaceweeb wrote: ↑Sat Jul 24, 2021 9:57 pm I've just realized that the FreeCAD Tet format is the opposite of what it is in nastran. That's unfortunate, but good to know. I hadn't realized.
https://wiki.freecadweb.org/FEM_Mesh
FreeCAD_Tet_Format.PNG
FreeCAD appears to be opposite of Abaqus as well as nastran. I'm curious how it got to be this way.
https://abaqus-docs.mit.edu/2017/Englis ... 3delem.htm
Abaqus_Tet_Format.PNG
BTW. FreeCAD mesh data structure is based on SMESH from Salome. SMESH used MED data structure. FEM_Element_Types It is a pity the link we have used for years is broken ... broken I found this: https://www.salome-platform.org/user-section/about/med
Re: Solver for Mystran
my be interesting to read ... Here I saved the transision from SMESH Med FreeCAD to Abaqus Calculix: FEM_Mesh_CalculiX This we have been used for years now.
-
- Posts: 118
- Joined: Fri Apr 09, 2021 3:26 am
Re: Solver for Mystran
I see. It all makes sense now.
I didn't know Salome uses inverse normals that way.
One issue this causes is that positive pressure on the element needs to be represented with a negative sign with respect to the element face normal vector. It's my personal theory that, historically, they wanted the hydrostatic components to be positive when the pressures were applied to the element following the right hand rule; thus counterintuitively making for compression, which is usually denoted as "negative stress" be created by "positive" pressure.
Fascinating stuff.
I didn't know Salome uses inverse normals that way.
One issue this causes is that positive pressure on the element needs to be represented with a negative sign with respect to the element face normal vector. It's my personal theory that, historically, they wanted the hydrostatic components to be positive when the pressures were applied to the element following the right hand rule; thus counterintuitively making for compression, which is usually denoted as "negative stress" be created by "positive" pressure.
Fascinating stuff.