Extracting reaction forces individually for several supports in one document

[farhad_motaharifar94]

Hi everyone,

I’m working on a static analysis in Inventor Nastran 2025 and need to extract the reaction forces from multiple supports. I want to get the individual reaction forces for each support all at once, rather than manually checking each one by pressing the right click..

I also read the answer for the same subject in (https://forums.autodesk.com/t5/inventor-forum/stress-environment-extracting-reactions/m-p/12741461), mentioning that generating a report in Inventor Nastran includes support reaction forces. I tried this, but the report only provides a single resultant force in all directions, rather than separate values for each support.

Is there a way to extract the individual reaction forces for all supports at once? Any guidance or workaround would be greatly appreciated!

Thanks in advance!

[John_Holtz · Accepted solution]

Hi @farhad_motaharifar94 

Just to clarify for other readers, the article you mentioned is for Inventor Stress Analysis (ISA). The report generated by ISA will list the individual reaction forces at N constraints. I agree that the report generated for Inventor Nastran only gives the overall total from all N constraints.

If there are only a few supports and few subcases or timesteps, you can right-click on each constraint and write down the results by hand.

If there are many supports or subcases/timesteps or analyses, the manual approach can be tedious (and prone to errors). The third-party app FNO Reader would be the way to get the reaction from each node, sum all the nodes on the support, and output the value for each support, each subcase/timestep. The example "Graph Result from specific locations versus Time (or Step)" in the documentation (pages 8 & 9) describes how to do it. (Steps 12 and 13 in particular is where you specify which supports to output.)

John

[farhad_motaharifar94]

Hi @John_Holtz .

Thank you for your detailed explanation! I appreciate the clarification regarding the difference between Inventor Stress Analysis (ISA) and Inventor Nastran in terms of reaction force reporting.

The FNO Reader method you suggested seems like a much better alternative to manually checking each constraint. However, it still involves multiple steps to extract the reaction forces, and for reaction moments, the process becomes even more complex.

Given that reaction moments are essential for weld calculations, it would be very useful if Inventor Nastran had a built-in feature that allows users to simply right-click on a support and directly obtain reaction forces and moments about the centroid of the constrained edge or surface. Additionally, if the generated report in Inventor Nastran could include reaction forces and moments for each support, similar to how ISA does, it would greatly improve usability for all users working with structural analyses.

Is there any possibility of having these features added in future updates? I believe this would be a valuable enhancement for many users.

Thanks again for your help!

[farhad_motaharifar94]

One more thing—I tested the proposed approach on a cantilever beam and noticed a significant discrepancy in the extracted node coordinates. The coordinates in the extracted data are 10^12 times larger than those in the meshed model.

I double-checked the units settings, and the length unit was correctly set to mm, so I’m unsure what might be causing this issue. It seems to be purely a scaling problem, as I compared Node 1’s position:

• In the meshed model: (2.87, 18.06, 25)

• In the extracted data: (2.87E+12, 1.81E+13, 2.5E+13)

What could be causing this discrepancy when extracting the grid point coordinates?

For your reference, I've attached the beam model and the extracted data from FNO Reader.

[John_Holtz]

Hi @farhad_motaharifar94 

The coordinates are okay in the grid file ("Grids-NAS.csv") but wrong when merged into the reaction force results ("Reactions Forces-TBL.csv").

How did you get the coordinates into the reaction force spreadsheet?

John

[farhad_motaharifar94]

Hi @John_Holtz .

I followed the steps exactly as explained in the FNO Reader help, under Graph Result from Specific Locations vs. Time (or Step).

When extracting the grid coordinates in Text format, they appear correct, regardless of the chosen separator (comma, semicolon, or tab). However, in CSV format, I noticed the following:

• If I use a semicolon (;) to separate the grid points, the extracted values become excessively large (on the order of E+12) but remain in separate columns.

• If I use a comma (,) or a tab as the separator, the extracted values are correct, but they appear in a single column in Excel.

To resolve this, I tried manually separating the values in Excel using Text to Columns (under the Data tab). However, as soon as I did this, the grid point values were converted back to large numbers like before.

I'm unsure whether this issue is related to Excel or something else.

For your reference, I’ve attached the grid points extracted in both CSV (separated by tab) and Text formats, showing the correct values.

[John_Holtz]

Yes, the issue is related to how Excel is interpreting the data (and maybe how your Windows is setup to show the decimal symbol, and maybe FNO Reader). When you enter a formula in Excel such as =10/3, is the result shown as "3,3333" or as "3.3333"?

It looks like your Excel is ignoring the decimal symbol "." in the numbers in the text file. Excel is not reading "2.874087741836E+0" as 2.874, but instead it is reading it as "2874087741836E+0" which is 2.874E12.

If you can find this dialog in your Windows Region settings, what symbol is used for the Decimal symbol, Digit grouping symbol, and List separator? (I expect FNO Reader will output the correct decimal symbol, which Excel should also be reading, but maybe not.)

If your decimal symbol is a comma, you could open the any of the text files with Notepad and do a global search and replace to replace the "." with a ",". Then Excel should read the file properly. Or maybe there is a setting in Excel that tells it to use a different character for the decimal symbol.

John