I write Abaqus UMAT subroutines as a graduate student in computational mechanics. These are complex multi-physics simulation models using Abaqus Fortran subroutines (UMAT ~ mechanical behavior, UMATHT ~ heat/diffusion and a lot more) that simulate how different material systems fail under high temperature or manufacturing processes.

However, the entire process has been quite challenging, 80-90% of time is actually spent on how make Abaqus CAE simulate a physics you already know on paper or what are the correct subroutines and variables you should use. Huge time is also spent on diving deep into the .sta .msg files to figure out and debug why a simulation failed. The software or current tooling (IDE ~ which is VS Code etc built for software engineering, not computational physics or mechanics) doesn't tell you why the simulation run into a segmentation error, or warn you when your damage variable being 1 (fully damaged) will lead to a zero division error. Silent mistakes or errors propagate through your simulation silently, and the physics is completely wrong (or worse, physics make sense, but wrong nonetheless). The documentation is terse and complex, haven't changed for a decade, offering basic linear elastic examples only.

The entire way computational engineers approach their work is with a touch/sense of secrecy. Codes are hidden behind NDAs and various policies. Although, this makes sense from a national security standpoint. It slows down and stifle innovation in the field. Codes are not shared like the way software engineers do, repositories are private, .odb files are hidden, Less resources for tutorials on complex multi-physics simulations. This is why Dr. Fei Fei Li in her recent post on world models, identifying the "simulate" part of the world model taxonomy (the other two is a planner and a renderer) as the linchpin of a world model (read here https://x.com/drfeifei/status/2062247238143996275) with orders of magnitude of less available data available to effectively train world models.

On occasions, engineers classify some of these problems as a "skill issue", which I believe is a wrong mindset to have. However, having prior experience building software and webapps, I know how important the tooling and community is to the entire software ecosystem (think open-source projects on Github, Modules/Packages you can easily pip install, and tutorials from legends like Karpathy and a lot more).

With the Jacobi Physics IDE, I am building that tooling and ecosystem for physics simulation. Due to my current knowledge of Abaqus, that is what I start with. But eventually, following feedback and engagement from users, this will expand to cover multiple physics solvers out there (COMSOL, NASTRAN, LS-DYNA....I want to hear more from you guys in the comment) that enable users and researchers to write subroutines and user-defined material behavior for their own unique simulations.

I will love to hear from you guys, download the IDE at https://jacobee.netlify.app/. Thanks.

I totally resonate with what you are doing. I use a VS code extension when coding abaqus subroutines and the most feature I can get out of it is syntax highlighting. I will love to see how far this goes! Goodluck.

*repositories are private, .odb files are hidden locally on computers...

Very true, those subroutine documentation haven't changed like forever, it's even more than a decade, maybe two decades. Downloading...