Local coordinate system not working for points load or for point BC and for gravity load

I have question why local coordinate system not working for points load or for poits BC and for gravity load?

Local CSYS assignment internally transform the coordinate system of the nodes used for the boundary condition or load definition. It can be used with concentrated forces abd BCs, but not with distributed loads such as gravity.

If it doesn’t seem to be working for some reason, make sure the local CSYS is not only created first, but also assigned to the BC/load definition (instead of the default Global).

It doesn’t work when applying a BC via rigid body constraint though (due to CalculiX’s bug/limitation): Potential Bug Applying Radial Displacement to Rigid Surface

1 Like

I might be a bit late to the discussion, but in my opinion, local coordinate systems (cosy) do not work for point loads too. (as a new user, unfortunately I can’t upload my model here yet…).
I do understand that local coordinate systems can’t be used for BCs, since calculix doesn’t allow for it.
I can image the same limitation applies to point loads from a calculix point of view. However, a workaround seems quite easy to me (does not work for BCs on points):
When a local coordinate system is used for point loads, the forces can be transformed to the global cosy prior to calculation and used for the job-generation.
In my opinion, local coordinate systems for loads are mainly used for the ease of load definition. As an example, if I want a load to be perpendicular to some geometry. If the loads are converted to the global cosy, the numbers aren’t as nice and obvious anymore, but as long as the displayed force vector in PrePoMax uses the global forces, this would directly be a way to check the orientation of the resulting load.

Edit: When I say point load, I meant a “concentrated-force” that I applied on a reference point which is connected to a face of a part by “Distributing Coupling”.

I hope using a google drive link works for sharing the pmx-file:

That’s the problem then. It should work without coupling. These constraints have some limitations, but you can define orientations for them using keywords. See this part of the CalculiX documentation: https://www.dhondt.de/ccx_2.23.pdf#subsection.7.41

You have to set access to Anyone with the link before copying the link.

Thanks a lot for your fast answer!
I set access to Anyone now, sorry about that:

Concerning your answer: If I want to apply a load to a single node not part of the meshed body, I have to couple it somehow to the geometry? Ideally without stiffening the structure (like using RBE3-Elements in Nastran). And to my understanding this is done by “Distributing Coupling” in PrePoMax/Calculix.

P.S.: Sorry if this might be a very basic question: I’m completely new to PrePoMax and Calculix and currently evaluating, if I can use it as a substitute for commercial software like Ansys, Abaqus etc.

Yes, rigid body and kinematic coupling constraints are more robust alternatives (concentrated forces should work at least with rigid body reference nodes: Potential Bug Applying Radial Displacement to Rigid Surface - #4 by Matej), but they make the surface rigid. Here’s a summary of the 3 coupling types: Different coupling constraints and their limitations - Uncategorized - CalculiX (official versions are on www.calculix.de, the official GitHub repository is at https://github.com/Dhondtguido/CalculiX).

There is *DISTRIBUTING COUPLING too - it needs rather tedious keyword edits, though and I don’t think it can work with LCS.

Of course, you could always define the force components in such a way that the resultant force acts in the desired directions.

If you submit your analysis, there are errors such as:

 *ERROR in cloaddistributing: a transformation
        is not allowed in the reference node
        of a *distributing definition;
        reference node:        67757

confirming that CalculiX doesn’t support this workflow.

It might be good to ask on the CalculiX forum where the devs are active too: https://calculix.discourse.group/

Thanks a lot for the link with the summary of the 3 coupling types. To my understanding, I have 2 options if I don’t want to add additional stiffness (rigid surfaces):

  • *COUPLING followed by *DISTRIBUTING
  • *DISTRIBUTING COUPLING

However, both do not allow for local CoSys to be used, no matter if forces or boundary conditions are to be applied.

I will ask the CalculiX-forum about the topic. Nevertheless, I think a simple transformation of forces defined in local CoSys to forces in global coordinates would be a relatively easy work-around for forces (not for BCs)?

Yeah, it should be possible for the preprocessor (PrePoMax) to provide a workaround, maybe even for BCs. However, it would be good to ask for this improvement on the CalculiX side. Feature requests can be posted here, but should be discussed on the forum first: Issues · Dhondtguido/CalculiX · GitHub

I have never try it but according to manual orientation is a Coupling parameter and *orientation itself could be toghether work with a *Distribution card.

Something like :

*DISTRIBUTION,NAME=DI1
,0.,0.,0.,0.,0.,1.
EALL_ELEMENTS,0.,0.,0.,0.,0.,1.
*ORIENTATION,NAME=OR1,SYSTEM=CYLINDRICAL
DI1
*SURFACE,NAME=NSet_KINEMATIC,TYPE=NODE
NSet_KINEMATIC
*COUPLING,REFNODE=52,SURFACE=NSet_KINEMATIC,CONSTRAINT NAME=RootCouple,ORIENTATION=OR1
*KINEMATIC
1,3

Did someone ever tried *distribution succesfully?

I added *TRANSFORM to the ref node of *DISTRIBUTING COUPLING in the documentation example distcoup.inp and there’s at least no error. It affects the reaction forces too so it seems to work.

If you want to give it a try, here’s the syntax:

*ELEMENT, TYPE=DCOUP3D, ELSET=distr_coupl_name
element number, reference node number
*DISTRIBUTING COUPLING, ELSET=distr_coupl_name
node or node set, weight
...

Defining weights will be the trickiest part, but see the discussion here: RBE3 implementation - #13 by FEAnalyst

Alternatively, you can indeed try adding orientations for *COUPLING with *DISTRIBUTING:

The *DISTRIBUTING card must be immediately preceded by a *COUPLING keyword card, specifying the reference node and the element surface. If no ORIENTATION was specified on the *COUPLING card, the degrees of freedom apply to the global rectangular system, if an ORIENTATION was used, they apply to the local system. For a *DISTRIBUTING constraint the local system cannot be cylindrical.

I have an example of defining orientations for couplings (just kinematic ones) here: https://www.youtube.com/watch?v=pS-OEiUN488

Just wanted to update you guys that I did make an entry to the CalculiX discourse:

However, the feedback so far is limited…

In general, I want to avoid any scripting, since I’m evaluating if PrePoMax is a viable alternative to commercial programs. And for people in our team new to FEM, too much manual effort / scripting is an entry hurdle as well as a risk in my opinion. Especially since FE-calculations would only be a tool for us and not our main expertise.

Let’s wait for the feedback on the CalculiX forum. But you can also submit a GitHub report so that it’s not forgotten/lost on the forum: Issues · Dhondtguido/CalculiX · GitHub

We have some other doubts regarding couplings too (particularly related to their usage with shells) and I will ask Guido Dhondt (author of CalculiX) directly if we don’t get any news from the dev team on the forum.

Scripting shouldn’t be needed here. You may only need some keyword edits, but CalculiX keywords not supported by PrePoMax can be added through the built-in Keyword Editor. The syntax is very user-friendly. The same workflow is commonly used in Abaqus.

1 Like