I have not looked very deep into FEMaster, it seems really powerful. The benefit is the use of shells and proper beams which CCX does not have. However CCX has 28 years of development in it, with a very established user base. Why not push CCX development to fill the gaps that it currently has?
Myself and p.viguier have been working on beam elements for CCX. There seems to be willingness to have it incoporated into the official CCX build in the future.
Thanks for your questions about why Code-Aster and why the bridge with Mecway. I like these kind of discussions.
Why Code-Aster: I don’t like the idea to be reliant of expensive, commercial tools for my daily work. It has something to do with a sence of freedom. Since I finished my studies in 2010 I have been looking for open source or affordable alternatives for CAD, FEA and Symbolic math or hand calculations. For FEA I found out that Code-Aster is the only open source solver which has: - All element types I would need (spring, RBE, beam – including Timoshenko –, shell, solid, contact) and much more - A thorough documentation, just like commercial solvers - (Documented) validation of all of its capabilities - An active and industrial user community (developing in a nice way recently with Open source software | Simvia) - Active development backed-up by an industrial company (EDF) - GNU-GPL v3 allows commercial usage
Why the bridge with Mecway: Code-Aster has been build as a tool for FEA based on scripting with python. A GUI (AsterStudy) has been developed together with the Salome-platform. Mainly focussing upon meshing (Salome-Meca). Because of its focus on scripting, it is a very strong tool for iterative (scientific) studies. However, its GUI os AsterStudy is completely different from what I am used to from my work with commercial pre- postprocessors like Femap or Mentat. It mainly focusses on creating a correct .comm file. Most of its documentation has long been available in French only, which complicates it even more. However, the documentation created by Jean-Pierre Aubry and Moonish engineering enabled me to find my way through it. Just like others are mentioning, I want to be able to do beam-analysis with FEA. Orientation of beams is quite difficult without a graphical interface showing the actual cros-section. My search for such a tool brought me to Mecway. However, Mecway lacks the industrial user community and thorough validation. It also only supports Euler beams. That's where I started to think about a bridge between Mecway and Code-Aster, using the strong points of both tools.
How will it go further: The emergence of agentic AI enabled me to rapidly develop this bridge. My aim is to have a usable tool which enables me to use Mecway for preprocessing (without having to develop and maintain a pre- postprocessor GUI myself) and Code-Aster as a trustworthy solver. I cannot promise anything about long-time support of course. It depends upon how much time I indeed will use this program in my daily work. I will at least keep it working with the latest Mecway version fort he coming time.
Thanks again for your contribution. I love your aproach and predisposition to comment with others about it.
It's very nice to know you are mostly interested to fill the actual limitations when using beams.
Mecway use Euler beam theory intended for slender, uniform, isotropic beams. Mecway supports arbitrary cross-sections through the definition of their geometric properties.
Available GUI Parameter
A Cross-sectional area IY Second moment of area about local Y IZ Second moment of area about local Z JX Saint-Venant torsion constant P Perimeter
The elements include:
- Axial stiffness. - Torsional stiffness. - Bending stiffness about the two principal axes. - Rotational degrees of freedom at the nodes.
MEcwayBridge to Code_Aster formulation contribution.
POU_D_E Euler–Bernoulli Slender beams; Actual Mecway Formulation. POU_D_T Timoshenko Includes transverse shear deformation. POU_D_TG Timoshenko with warping .Accounts for cross-section warping POU_D_TGM Timoshenko, warping, multifiber. Nonlinear material behavior across section fibers BARRE Axial bar Axial deformation only.
Potential additional modeling capabilities for:
- Shear-flexible beams. - Beams with significant cross-section warping. - Multifiber sections with nonlinear material behavior.
Mecway new requirements to explode these new capabilities:
Timoshenko: Euler properties + AY, AZ Timoshenko with warping: Timoshenko properties + EY, EZ, JG, and additional geometric-stiffness IYR2 and IZR2
MecwaySectionProps can compute those extra values but, they still need to be added as custom cards ¿isn't it?. Is there any example file using a Timoshenko with warping user beam? How could we visualize beam orientations for those elaborated sections? User beams are now modeled as rectangles.
Comments
I have not looked very deep into FEMaster, it seems really powerful. The benefit is the use of shells and proper beams which CCX does not have. However CCX has 28 years of development in it, with a very established user base. Why not push CCX development to fill the gaps that it currently has?
Myself and p.viguier have been working on beam elements for CCX. There seems to be willingness to have it incoporated into the official CCX build in the future.
Thanks for your questions about why Code-Aster and why the bridge with Mecway. I like these kind of discussions.
Why Code-Aster:
I don’t like the idea to be reliant of expensive, commercial tools for my daily work. It has something to do with a sence of freedom. Since I finished my studies in 2010 I have been looking for open source or affordable alternatives for CAD, FEA and Symbolic math or hand calculations. For FEA I found out that Code-Aster is the only open source solver which has:
- All element types I would need (spring, RBE, beam – including Timoshenko –, shell, solid, contact) and much more
- A thorough documentation, just like commercial solvers
- (Documented) validation of all of its capabilities
- An active and industrial user community (developing in a nice way recently with Open source software | Simvia)
- Active development backed-up by an industrial company (EDF)
- GNU-GPL v3 allows commercial usage
Why the bridge with Mecway:
Code-Aster has been build as a tool for FEA based on scripting with python. A GUI (AsterStudy) has been developed together with the Salome-platform. Mainly focussing upon meshing (Salome-Meca). Because of its focus on scripting, it is a very strong tool for iterative (scientific) studies. However, its GUI os AsterStudy is completely different from what I am used to from my work with commercial pre- postprocessors like Femap or Mentat. It mainly focusses on creating a correct .comm file. Most of its documentation has long been available in French only, which complicates it even more. However, the documentation created by Jean-Pierre Aubry and Moonish engineering enabled me to find my way through it.
Just like others are mentioning, I want to be able to do beam-analysis with FEA. Orientation of beams is quite difficult without a graphical interface showing the actual cros-section. My search for such a tool brought me to Mecway. However, Mecway lacks the industrial user community and thorough validation. It also only supports Euler beams. That's where I started to think about a bridge between Mecway and Code-Aster, using the strong points of both tools.
How will it go further:
The emergence of agentic AI enabled me to rapidly develop this bridge. My aim is to have a usable tool which enables me to use Mecway for preprocessing (without having to develop and maintain a pre- postprocessor GUI myself) and Code-Aster as a trustworthy solver.
I cannot promise anything about long-time support of course. It depends upon how much time I indeed will use this program in my daily work. I will at least keep it working with the latest Mecway version fort he coming time.
For beam analysis I have recently created: MecwaySectionProps
For advanced postprocessing you can make use of AsterStudy-Results in Salome-meca or a standalone Paraview.
Thanks again for your contribution. I love your aproach and predisposition to comment with others about it.
It's very nice to know you are mostly interested to fill the actual limitations when using beams.
Mecway use Euler beam theory intended for slender, uniform, isotropic beams.
Mecway supports arbitrary cross-sections through the definition of their geometric properties.
Available GUI Parameter
A Cross-sectional area
IY Second moment of area about local Y
IZ Second moment of area about local Z
JX Saint-Venant torsion constant
P Perimeter
The elements include:
- Axial stiffness.
- Torsional stiffness.
- Bending stiffness about the two principal axes.
- Rotational degrees of freedom at the nodes.
Limitation: Beam formulation neglects transverse shear deformation.
MEcwayBridge to Code_Aster formulation contribution.
POU_D_E Euler–Bernoulli Slender beams; Actual Mecway Formulation.
POU_D_T Timoshenko Includes transverse shear deformation.
POU_D_TG Timoshenko with warping .Accounts for cross-section warping
POU_D_TGM Timoshenko, warping, multifiber. Nonlinear material behavior across section fibers
BARRE Axial bar Axial deformation only.
Potential additional modeling capabilities for:
- Shear-flexible beams.
- Beams with significant cross-section warping.
- Multifiber sections with nonlinear material behavior.
Mecway new requirements to explode these new capabilities:
Timoshenko: Euler properties + AY, AZ
Timoshenko with warping: Timoshenko properties + EY, EZ, JG, and additional geometric-stiffness IYR2 and IZR2
MecwaySectionProps can compute those extra values but, they still need to be added as custom cards ¿isn't it?. Is there any example file using a Timoshenko with warping user beam?
How could we visualize beam orientations for those elaborated sections? User beams are now modeled as rectangles.
Best Regards