Stuck? 
support@mecway.com
support@mecway.com
Mecway
FEA
Bridge between Mecway and Code-Aster
Hi all,
I have been long time looking for a nice GUI for Code-Aster. I have been using Salome-Meca, but always find it too tedious to use. In the first half of this year I established the working principle of a bridge between Mecway as pre-/post processor and Code-Aster as a solver. That structure proved to work. After that I didn’t have time to spent on it until last week. My son is programming a lot with Claude Code, and this week he didn’t have time to use it because of his homework 😊. So I was allowed to spent his weekly limit. Unfortunately, it worked out quite well and I decided to unlock more of Code-Aster than I normally use. As a result, the MecwayAsterBridge grew quiet large in capabilities. You can find it here: https://github.com/trednuK/MecwayAsterBridge
I have added a lot of validation checks and documentation. However, since it is build by AI, it still needs human verification to find edge cases which only appear in daily use.
Enjoy using it and please let me know if you have any suggestions or find some bugs.
Kind regards,
Kundert
I have been long time looking for a nice GUI for Code-Aster. I have been using Salome-Meca, but always find it too tedious to use. In the first half of this year I established the working principle of a bridge between Mecway as pre-/post processor and Code-Aster as a solver. That structure proved to work. After that I didn’t have time to spent on it until last week. My son is programming a lot with Claude Code, and this week he didn’t have time to use it because of his homework 😊. So I was allowed to spent his weekly limit. Unfortunately, it worked out quite well and I decided to unlock more of Code-Aster than I normally use. As a result, the MecwayAsterBridge grew quiet large in capabilities. You can find it here: https://github.com/trednuK/MecwayAsterBridge
I have added a lot of validation checks and documentation. However, since it is build by AI, it still needs human verification to find edge cases which only appear in daily use.
Enjoy using it and please let me know if you have any suggestions or find some bugs.
Kind regards,
Kundert
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
â•‘ â•‘
â•‘ â•‘
â•‘ Erreur de syntaxe dans AFFE_CHAR_MECA â•‘
â•‘ â•‘
â•‘ At least one argument of ('TOUT', 'GROUP_MA', â•‘
â•‘ 'GROUP_NO', 'NOEUD') must be defined â•‘
â•‘ â•‘
║ Exception détaillée ci-dessous. ║
I did wonder if it is something to do with defining points or surfaces and played around but got now where. Is there something obvious I'm doing wrong? I have attached a sample of a simple model that i have got stuck on
1:11AM
@Fatmac , I just remove the CCX custom card and apply the restrain to the defined face group (it was applied to the same faces but selected directly) and then works ok.
thanks Sergio - that appears to be all that was wrong -that has open the door to more fun!
I am not sure about TIE with shells. I will look it up for you, but give me some time.
In the meanwhile, you could try using normal Code-Aster commands via #Aster-keywords (you can read about it in the help-documents of the bridge). Not sure if that will help, and did not test it myself up to now.
Please refer to the below link. I have not pushed it to my main brach as yet.
@KundertdeWit, I am not an expert with Github (just a basic user) we can possibly merge all our changes at some point, I see that you have updated your repository once already, my fork of yours has had a few changes today.
https://github.com/mishal0488/MecwayAsterBridge/tree/dev
I did the same :-), I was reading your post just now. I checked if my changes cover yours, which is not the case. I will add this to the next release, which will be available tonight I think
Release 2026.2 is available just now, with some other improvements, including Mecway 34.
Could you also check the frequency analysis again (in another forum thread), regarding the orientation of beams.
Thanks for your work and kind regards,
Kundert
I have added some issues/feature request in the Github page, related to add some buttons in the convergence window to access directly to Code_Aster comm, mail and med result files.
This new bridge is incredible, the way bc and results are translated directly is amazing.
I may not make any modification and changes for a while since my workload is currently high.
Many thanks for your valuable input.
It has been added to version 2026.4, which is available now
@Mishal: the functionality has been added, but a bit differently than you did it. Please check if this indeed does what it should do.
Has some extra functionality and bug fixing.
Secondly—and please don’t take this as an attempt to discourage you or diminish the value of what you’ve built so far—I’d like to raise a few points and ask about your vision for the future of this project.
In my view, MecwayAsterBridge will always be constrained by the number of commands and analysis types available in Mecway, unless a dedicated interface is developed to cover all the variables supported by the solver.
I believe it would be worthwhile—if Victor agrees—for Mecway to offer a specific "Mecway/CodeAster" product line, focused exclusively on the Code_Aster solver. I emphasize "exclusively" because I’m not a fan of the direction taken in recent versions, which integrate multiple solvers (Mystran, FeMaster, CCX, OpenRAdiosss, the native solver, and now potentially Code_Aster) into a single GUI. I feel this has slowed down the development of the core product lines and complicated the user experience, without providing any clear, tangible benefits at last for me. I believe that bottlenecks still exist in each of the solvers—whether it be the internal nonlinear analysis or the handling of beams and shells in CCX—which prevent complete workflows from being carried out within a single solver.
Furthermore, if a simulation can already be run within Mecway, what is the purpose of developing a "bridge"? While it might be useful as a verification tool, it cannot truly compensate for the limitations of Mecway’s native solver. At best, you might be able to run a calculation, but you wouldn't be able to leverage new features that the Mecway GUI isn't designed to support.
Is Code_Aster free for commercial use? And would that significantly limit the potential use cases or the future of this bridge?
In any case, thank you once again for creating this tool; I’d be very interested to hear your thoughts—and Victor’s—on this.
Thanks again for the bridge!
I really like how Mecway has evolved over the years. It has provided an accessible platform for engineering analysis that would previously have been out of reach for many of us.
I agree that duplicating functionality is not necessarily productive. However, I believe the drive to introduce additional functionality largely stems from the limitations of the available open-source solvers.
I have personally explored almost every avenue to achieve comprehensive nonlinear beam functionality, including the MUMPS-enabled version of OpenRadioss and the Code_Aster bridge, but neither has provided a satisfactory solution. My latest approach has been to develop and compile my own CalculiX (CCX) distribution, which I hope will eventually be incorporated into the main development branch (It seems this may be the case in the near future). The objective is to provide comprehensive beam functionality while retaining compatibility with the rest of CCX.
For me, achieving this would potentially make CCX the most versatile and robust solver available within Mecway.
Ultimately, I think Mecway's internal solver, CCX and OpenRadioss complement one another very well. Each has its own strengths and limitations, and together they provide a powerful combination of analysis capabilities that can legitimately be applied to real-world engineering problems.
I think that today, even if the integration is not native, Mecway (with all his particularities) is the best preprocessor for Code_Aster available in the market, open source or comercial. What if other code hero take as example and create a similar approuch for other solvers such as Elmer, OpenSees? Then Mecway could become a more general preprocessor and the improvements be guided for that, creating tools for making that integrations easiers than today.
Mecway as is today give us the freedom to choice the solver that we want to use, and this has a great value for freelancers or small companies.
In my view, FEMaster is the most promising solver. Its development speed and the level of maturity it has achieved in such a short time are remarkable. Given its compatibility with the Abaqus format, which is already largely supported by Mecway, I believe it is a very strong candidate.
The main points to clarify before committing support and providing a platform for its development are the developer's long-term commitment to the project and their intention to keep it open source.
Creating a comunity can take a lot of time, and maybe in the meantime the developers would lost the wills to follow the project, but if they are open other can follow it.