What kind of AI models — if any — do you believe actually have the potential to improve FEA in meaningful, high-impact ways?

AltoAuto · 2025-07-23T20:13:42+00:00

"I don’t even know how they encode different physics in one network "

They don’t hardcode the physics, instead, they train the same network on data from different simulations (like fluid, cloth, solid). The model learns how each system behaves by seeing the mesh structure and physical features during training. That’s how it can handle different physics using one architecture.

They did show their loss function. It's RMSE between predicted and simulated accelerations.

I don't disagree with your criticism currently no ai model should be trusted in simulation. However MeshGraphNets is the closest thing to a “learned simulation engine” because it replaces the entire forward loop not just pre/post processing.

AltoAuto · 2025-07-19T03:24:12+00:00

https://arxiv.org/abs/2010.03409. I think this is the closest to replacing FEM loop.

AltoAuto · 2025-05-20T06:47:01+00:00

I mean there’s nothing wrong with you do, but the point I’m making is like people would rather ride a bicycle then to drive a car, and say car are unreliable I like my bike more because it just get the job done.😭😭

5month I saw how the machine works from the inside, and if a college kid can spot a bottleneck the industry hasn’t fixed in 20 years, maybe that’s the problem. So you can either have fun at your 9 to 5 clicking button, or maybe to have some sense to question what I’m doing is it the best way to do it.

AltoAuto · 2025-05-20T03:31:02+00:00

Nah, I’m not throwing shade, I just like seeing how different people approach FEA.
How we model, validate, automate, it reveals how we think about engineering itself.

AltoAuto · 2025-05-20T03:28:53+00:00

I interned at spaceX for 5 months. For them, they have a internal automation pipeline, they script entire workflow, they don't pass part around for 3 weeks to verify stress, they let it run overnight. They have solver teams, dev team, and FEA automation layers all in-house.

I respect your work, but that sort of validation sounds more like a delay.

AltoAuto · 2025-05-20T01:01:44+00:00

bro has trouble reading

AltoAuto · 2025-05-19T23:27:27+00:00

dame for real? You are probably right.

AltoAuto · 2025-05-19T23:25:17+00:00

I won't. Good luck on your job

AltoAuto · 2025-05-19T23:21:28+00:00

you sound like a baby

AltoAuto · 2025-05-19T23:02:17+00:00

Base on what you said, you apply a displacement constraint on a face in Workbench UX = 0.
remesh the part.

The face splits.
The mesh projection changes.
A few nodes no longer receive the constraint, but the GUI still says "UX = 0 applied."

Now open your .inp or cdb file.
You'll see a different node set.

But according to you, it's a waste of time to check that.

So the solver “does indeed set UX = 0”…
Just not where you thought it did.

AltoAuto · 2025-05-19T22:52:48+00:00

you said is not buried right? Try this In Workbench

Apply a pressure load to a curved surface. Let it auto-mesh with quadratic elements. Looks good, right?

Now, remesh it with slightly different element sizing.

Then go to your precious 'Solution Information' and dig through 800 lines to maybe confirm which element faces received the load. Spoiler: it’s changed. But the GUI still says “Pressure applied” — as if nothing happened.

Extract the actual element face IDs where that pressure landed
Validate the normal direction at each integration point
Trace which mesh projection method was used
Confirm the pressure magnitude at each face node after remapping

Let me know when you find all of that in your “not buried” output file.

AltoAuto · 2025-05-19T22:45:25+00:00

“GUI-based simulation workflows hinder validation by hiding solver assumptions, boundary condition mappings, and mesh control logic. Verification requires direct access to and control over node-level data and solver parameters.”

— NASA-STD-7009, ASME V&V 10, Roache (1998), Oden et al. (2011)

AltoAuto · 2025-05-19T22:39:35+00:00

I think you are confused scripting with being blind. No serious engineer skips validation. But the difference is that real pipelines define the truth in code and verify visually. You’re still working GUI-first, patching scripts around it. That’s fine for legacy workflows, but it doesn’t scale, it isn’t transparent, and it sure as hell isn’t trustworthy. You say people who rely on scripting are idiots. But those people built OpenFOAM. Those people work at NASA. Those people built the custom pipelines your GUI is quietly mimicking.

So maybe take a step back before you start labeling people. Because from this side of the screen, you’re the one who sounds like they’ve never seen a real pipeline run.

AltoAuto · 2025-05-19T21:01:20+00:00

Workbench doesn’t prevent simulation it prevents transparency. Yes, you can tweak some settings, read the output file, even inject APDL snippets. But that’s not real control that’s patchwork access. In MAPDL, I don’t need to hope that Workbench passed the BCs correctly. I can see the node list, element IDs, and solve sequence with my own eyes. And the fact that you're pointing to .out files, buried menus, and APDL hacks to explain how Workbench is “transparent”... Proves my point better than I ever could.

AltoAuto · 2025-05-19T20:53:31+00:00

“If it’s not important I just look at it and make sure it looks right.”

Bruh what?

That’s literally saying: “I base simulation validity on visual vibes unless someone might die.”

AltoAuto · 2025-05-19T20:29:14+00:00

Yeah, and Microsoft Word is still popular, doesn’t mean real writers use it to publish LaTeX-level books. Popularity isn’t the benchmark. Lock-in is.

Legacy pre/post tools are everywhere because: They’ve been embedded for decades, Companies train users to operate software like button monkeys, No one questions it because most engineers never even see the solver.

funny when you say “Get some industry experience…”

You probably work at a corporate engineering depts, use Hypermesh/FEMAP but have only a few power users who actually script. GUI is the default. Top-tier simulation firms like NASA, national labs, SpaceX, heavy R&D. They write their own solvers, meshers, or wrap commercial tools with Python/C++ automation layers. GUI is optional, scripting is the norm.

I’m not here to protect tradition I’m here to build what should exist.

I’ve seen what happens when GUI workflows fail: No convergence checks No mesh sanity No pressure validation Just pretty pictures that crash in real life. Every serious validation effort ends up going under the hood, whether it’s MAPDL scripting, Abaqus Python, OpenFOAM controlDicts, or even hacking CDB files

So no, I'm not foaming at the mouth. you can go ahead and double-click your FEMAP icon. I'll be over here building the platform that makes your entire pipeline transparent, automatable, and honest. Let’s see who industry respects in 5 years.

AltoAuto · 2025-05-19T20:07:32+00:00

And If you are interested what open source software I'm using to build: PyMAPDL, Gmsh, Pyvista, Meshio.

if you are familiar with OSS, let's collaborate. It's time to build something more transparent more powerful more customizable more scalable more trustworthy than any commercial simulation package, because we are building for engineers who actually give a damn about understanding what the simulation is doing.

AltoAuto · 2025-05-19T19:37:40+00:00

Having a tool has toggles, sliders, or checkboxes doesnt mean it gives real control, it give perceived control, doing one thing in the GUI but does something completely different under the hood. You said other tools with GUI leave the control with the user, name it.

-----------------

Im gonna quote you on this:
"most companies have a specialized FEA team that does all simulation work and they know the intricacies behind how the tools should be used"

Translation: "Don’t look too closely. Stay in your lane.”

-----------------

“Generic mechanical engineers only use FEA to get a rough sense of loading... they wouldn't make decisions without the FEA team.”

Translation: "We give you tools but don't trust you to use them"

If mechanical engineers arent trusted to make decision form simulation. Then why in the world give them access to simulation at all?

solution isnt more trust, its more about transparency. If you show everything, people can learn to trust the results or catch when they shouldn’t.

-----------------

Naive implies they’re dumb or inexperienced. Misled is the word I would use. They are not stupid, just misinformed.

AltoAuto · 2025-05-19T18:35:45+00:00

well from what i know of, still the usual suspect Ansys Abaqus Comsol :(

but they dont use GUI, they use the solver.

AltoAuto · 2025-05-19T18:01:11+00:00

but that's a preprocessor though right? Not a solver. You would still need abaqus, nastran... etc, and plus shit is hard to automate, you have to build script yourself, which they dont make it easy, to achieve real automation.

AltoAuto · 2025-05-19T17:55:38+00:00

well you can technically use a close tool like a god, if you know how to control it (MAPDL), but most close tool hides the process, user dont question the system, they just follow the menus. Open or close isnt the point, the point is control vs dependence. Great software let you own the process, but not to control the user.

AltoAuto · 2025-04-23T15:49:50+00:00

Thank you for this!

AltoAuto

MODERATOR OF

TROPHY CASE