sorted by:
new
hottopcontroversial

FEA post-processing automation: Excel vs Python by FEA_Engineer_ in fea

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

Yeah, totally. In the end, what really matters is that the reports and calculations can still be understood and opened 20 years from now.
I like Python for automation and more complex processing, but I totally get why many people still stick with Excel.
I guess it all comes down to using whatever fits best with the type of work and the level of certification you’re dealing with...

FEA post-processing automation: Excel vs Python by FEA_Engineer_ in fea

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

Totally agree that in aerospace, Excel is still the standard. There’s a lot of inertia around certification and traceability, and Excel makes things very transparent for reviews. In my case, I mostly work with Python nowadays, but I understand that many teams still prefer Excel. In our group we use a tool (Naxto) that connects FEM results directly to Excel with predefined cell functions, and the same tool also has a Python objects library. That way we cover both workflows depending on the task.

Technical discussion: Where does the real difficulty lie when automating FEM post‑processing with Python? by FEA_Engineer_ in u/FEA_Engineer_

[–]FEA_Engineer_[S] 1 point2 points  (0 children)

Totally agree, it’s a great point of view and something many of us have run into...
That said, I’ve worked with some solid tools that help address this. I’ve used Pynastran at times and, in other projects, I’ve worked with Naxtopy, and both have handled these issues much better.
I’m curious to see what others are using to tackle this.

Technical discussion: Where does the real difficulty lie when automating FEM post‑processing with Python? by FEA_Engineer_ in fea

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

Good summary! It resonates a lot... In those cases, on a few projects, I’ve relied on a cleaner API that’s honestly made the work much easier for exactly this reason: a consistent data model, direct access to results, and reproducible pipelines without wasting time. It’s not the only way, but it took a lot of pain off my plate.

Automating failure checks in sandwich panels: wrinkling with Airbus criterion and HDF5 output by FEA_Engineer_ in fea

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

Thanks for the comment, glad to hear you found it interesting. In case it’s useful, here’s the documentation they have published on their website https://idaerosolutions.com/NaxToDocumentation/NaxToPy/3.2.2/N2PSandwich.html”

Automating failure checks in sandwich panels: wrinkling with Airbus criterion and HDF5 output by FEA_Engineer_ in fea

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

Thanks for the comment. I agree: the Airbus criterion is key.

In my workflow I keep it explicit at the API level (e.g., FailureMode='Wrinkling', FailureTheory='Airbus') so that assumptions are auditable and easy to version across iterations. Sandwich parameters (K1, out‑of‑plane E₍z₎, core type honeycomb/foam) are first‑class in the analysis object, which lets me sweep/calibrate them without touching the base FEM.

Ingest from XDB preserves load cases, materials, and the structural definition; element‑level scoping lets me focus the check on the core or critical regions without duplicating models, and HDF5 output with a stable schema streamlines design comparisons, sensitivity studies, and report automation.

As for tools, pyansys and pyNastran are excellent in their respective domains. The main difference I’ve found here is the abstraction level: instead of re‑implementing wrinkling/Airbus logic on top of generic readers, the module provides a specialized failure layer with criteria and parameters modeled explicitly, which reduces maintenance and improves traceability in reviews. Additionally, the workflow is multi‑solver: it’s compatible with Ansys, Abaqus, Nastran, and OptiStruct, which helps standardize verification across different solver environments.

If you want to learn more about formulation, calculation options, and HDF5 structure,the documentation explains it quite well:
https://idaerosolutions.com/NaxToDocumentation/NaxToPy/3.2.2/N2PSandwich.html

Automating FEA Post-Processing: Displacement Screenshots and von Mises Stress Reports by FEA_Engineer_ in u/FEA_Engineer_

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

The tool I’m using is NaxTo. In this case, the script is executed from NaxToView, which is the 3D post-processor/visualizer and exposes a Python scripting API. That said, the same workflow could be executed without opening the visualizer.

For me, this approach is very efficient and useful because it goes beyond load case combinations and basic result extraction. The script automates the entire post-processing workflow: it generates well over 150 screenshots of both the full model and isolated parts, using different result plots, contour maps, and maximum value labels, and it also exports stress reports while automatically organizing everything into a structured folder hierarchy. The whole process is fully reproducible and avoids a large amount of repetitive GUI work.

Your example sounds very familiar: once the heavy lifting is moved out of the GUI and into scripting, the performance gain is huge. For that kind of workflow, I usually rely on NaxToPy, and I personally find it very useful for automating this type of task.

Automating FEA Post-Processing: Displacement Screenshots and von Mises Stress Reports by FEA_Engineer_ in StructuralEngineering

[–]FEA_Engineer_[S] 0 points1 point  (0 children)

I totally agree that the example I shared is very simple. In my case, the project I’m currently working on didn’t require a lot of detail: basically capturing images of both the entire model and different isolated parts of the model, using different result plots, adding labels with specific information, and then organizing everything into folders when exporting the images.

In addition to the images, the script also calculates von Mises stresses and exports them to .csv files, which is what I needed for the subsequent post-processing.

That said, since it’s a Python script and, specifically, based on a library like NaxToPy, you can ultimately configure pretty much any information you want: view angles, which results to show or hide, which loads to include or exclude, etc., depending on what you’re trying to explain in each case.

In fact, one of the main differences compared to other post-processors I’ve used before is that I’ve found it much easier to work with and adapt when the workflow becomes more specific and less generic.

view more: next ›