Convert total force output to a local coordinate system

Feature Requests
1

Hello everyone!

There is a known limitation in CalculiX output request when using Global=No and Totals=Yes for nodal values, because the total force is not calculated in the local coordinate system even if a *TRANSFORM card is applied. The reference post can be found here.

image
image845×207 43.6 KB

I would like to request a post-processing tool that could convert the total forces to some coordinate system to address this limitation in the solver. If possible, the tool could automatically select the CSYS used in the nodes (or node set) selected for the history output.

A workaround is possible by extracting the *.dat results to an Excel file and sum the individual forces for each node.

Best regards,
Lucas.

2

I think you can already do that.

First, transform the field output to a user-defined coordinate system using Results → Field Outputs → Create → Coordinate System Transform.

Then, use history output with a filter to get the sum of values Results → History Outputs → Create → From Field Output and select the filter Sum.

3

If that works for you does it solve the Feature Request: Using *TRANSFORM for any node in the model?

1 Like
4

HI Lucas,
Be aware we recently found a bug in ccx when extracting the overall external force from a set of nodes of a shell when there is a contact involved. This directly affects the riveted strip problem.

1 Like
5

Matej, it worked perfectly! I was not aware that results could be changed to any coordinate system in post-processing.

This is very handy and solves the other issue of assigning *TRANSFORM for any type of nodes as well, since the results can be changed to any coordinate system the user wants.

I just add that I needed to change the filter to be applied in rows instead of columns (default), just a simple misunderstanding from my side.

Both feature requests can be closed, thank you for explaining how to do it properly.

I was not aware of this. Thank you, Anys! When I analyze riveted joints, sometimes I glue parts using *TIE (not tied contact) to avoid undesired relative motions. I’ll check if this issue happens for this card as well.

6

Nice.!!!.
Field output is erased if re-runing and one needs to do again the sequence. Field output and History output . Is that intended.?

7

I think that since they are generated from the results, it makes sense to delete them if one rerun the analysis?

8

Yes, that was my reasoning also. They are post-processing commands. But it would be handy to somehow keep them if the same problem is run multiple times.

9

I think so. Just keep them there and updating the results.

10

I can check if the .frd file with the same name is being opened and then copy these user-created outputs from old to new results. But some of them are created based on selection, and if geometry changes, the selections will become invalid…

11

Thanks Matej for paying attention to this.
I think this could be something to improve in general in Prepomax. When someone changes the name of a named selection , the boundary conditions and load broke. It can easily be fixed reopening and reassigning to the new name but I think it should not be too hard to internally do it.
Would that be something similar to what you are suggesting?.
Mecway for example, allows to create some user custom functions that can be later imported to be reused in other models. For example ,I have more than 90 custom formulas for different analysis. Signed von Misses, Signed Tresca, Triaxiality, J4 Skewness_angle, Jacobians, Lode Angle……All them can be imported , rehused and outputs don’t break when re-running.

12

Currently, the name changes are not propagated. In the beginning, the reason was the internal data structure was not created to be able to do that. But later I felt it helps to determine what is being affected if the names are accidentally changed.

That is a nice feature. I could incorporate it somehow using the command history.