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

**URL:** <https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040>\
**Category:** General Questions\
**Created:** [October 25, 2025, 10:20pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040 "2025-10-25T22:20:05Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michal](https://avatars.discourse-cdn.com/v4/letter/m/34f0e0/32.png) [@Michal](https://prepomax.discourse.group/u/Michal)\
**Post date:** [October 25, 2025, 10:20pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/1 "2025-10-25T22:20:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [October 25, 2025, 10:30pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/2 "2025-10-25T22:30:49Z")

</div>

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](https://prepomax.discourse.group/t/potential-bug-applying-radial-displacement-to-rigid-surface/2963)

---

<div class="post-metadata">

**Author:** ![RoyZH](https://avatars.discourse-cdn.com/v4/letter/r/c37758/32.png) [@RoyZH](https://prepomax.discourse.group/u/RoyZH)\
**Post date:** [September 14, 2026, 9:30am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/3 "2026-09-14T09:30:11Z")

</div>

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”.

---

<div class="post-metadata">

**Author:** ![RoyZH](https://avatars.discourse-cdn.com/v4/letter/r/c37758/32.png) [@RoyZH](https://prepomax.discourse.group/u/RoyZH)\
**Post date:** [September 14, 2026, 9:46am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/4 "2026-09-14T09:46:57Z")

</div>

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

> **[Google Drive: Sign-in](https://accounts.google.com/v3/signin/identifier?continue=https:%2F%2Fdrive.google.com%2Ffile%2Fd%2F1z1byCynWi9k6WfvUp0gLkJ56ZQxlh9_m%2Fview?usp%3Ddrive_link&followup=https:%2F%2Fdrive.google.com%2Ffile%2Fd%2F1z1byCynWi9k6WfvUp0gLkJ56ZQxlh9_m%2Fview?usp%3Ddrive_link&osid=1&passive=1209600&service=wise&flowName=GlifWebSignIn&flowEntry=ServiceLogin&dsh=S-433513168:1789379218190768)**
>
> Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 9:50am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/5 "2026-09-14T09:50:26Z")

</div>

> [@RoyZH](#):
>
> I meant a “concentrated-force” that I applied on a reference point which is connected to a face of a part by “Distributing Coupling”

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](https://www.dhondt.de/ccx_2.23.pdf#subsection.7.41)

> [@RoyZH](#):
>
> I hope using a google drive link works for sharing the pmx-file:

You have to set access to _Anyone with the link_ before copying the link.

---

<div class="post-metadata">

**Author:** ![RoyZH](https://avatars.discourse-cdn.com/v4/letter/r/c37758/32.png) [@RoyZH](https://prepomax.discourse.group/u/RoyZH)\
**Post date:** [September 14, 2026, 10:00am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/6 "2026-09-14T10:00:53Z")

</div>

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

> **[T-Stoss-Pyramide.pmx](https://drive.google.com/file/d/1z1byCynWi9k6WfvUp0gLkJ56ZQxlh9_m/view?usp=sharing)**
>
> Google Drive file.

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.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 10:12am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/7 "2026-09-14T10:12:12Z")

</div>

> [@RoyZH](#):
>
> 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.

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](https://prepomax.discourse.group/t/potential-bug-applying-radial-displacement-to-rigid-surface/2963/4)), 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).](https://calculix.discourse.group/t/different-coupling-constraints-and-their-limitations/2586)

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.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 10:13am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/8 "2026-09-14T10:13:11Z")

</div>

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

```auto
 *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/](https://calculix.discourse.group/)

---

<div class="post-metadata">

**Author:** ![RoyZH](https://avatars.discourse-cdn.com/v4/letter/r/c37758/32.png) [@RoyZH](https://prepomax.discourse.group/u/RoyZH)\
**Post date:** [September 14, 2026, 11:19am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/9 "2026-09-14T11:19:00Z")

</div>

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)?

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 1:40pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/10 "2026-09-14T13:40:46Z")

</div>

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](https://github.com/Dhondtguido/CalculiX/issues)

---

<div class="post-metadata">

**Author:** ![ANYS](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/anys/32/7737_2.png) [@ANYS](https://prepomax.discourse.group/u/ANYS)\
**Post date:** [September 14, 2026, 2:44pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/11 "2026-09-14T14:44:09Z")

</div>

> [@RoyZH](#):
>
> However, both do not allow for local CoSys to be used, no matter if forces or boundary conditions are to be applied.

I have never try it but according to manual _orientation is a Coupling parameter a_nd \*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?

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 2:58pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/12 "2026-09-14T14:58:50Z")

</div>

> [@RoyZH](#):
>
> However, both do not allow for local CoSys to be used, no matter if forces or boundary conditions are to be applied.

I added `*TRANSFORM` to the ref node of `*DISTRIBUTING COUPLING` in the documentation example [distcoup.inp](https://feacluster.com/CalculiX/ccx_2.18/doc/ccx/input_deck_viewer.php?input_deck=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:

```auto
*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](https://prepomax.discourse.group/t/rbe3-implementation/3596/13)

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 14, 2026, 3:05pm UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/13 "2026-09-14T15:05:22Z")

</div>

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](https://www.youtube.com/watch?v=pS-OEiUN488)

---

<div class="post-metadata">

**Author:** ![RoyZH](https://avatars.discourse-cdn.com/v4/letter/r/c37758/32.png) [@RoyZH](https://prepomax.discourse.group/u/RoyZH)\
**Post date:** [September 16, 2026, 7:11am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/14 "2026-09-16T07:11:02Z")

</div>

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

> **[Coupling constraints: capabilities and local coordinate systems not compatible](https://calculix.discourse.group/t/coupling-constraints-capabilities-and-local-coordinate-systems-not-compatible/4111)**
>
> I’m very new to CalculiX and so far, are only using it via PrePoMax. However, I do have experience with Ansys and NX Nastran. In both of these programs, you can apply loads or BCs on external points/nodes, which are coupled to regions of meshed...

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.

---

<div class="post-metadata">

**Author:** ![FEAnalyst](https://yyz2.discourse-cdn.com/free1/user_avatar/prepomax.discourse.group/feanalyst/32/688_2.png) [@FEAnalyst](https://prepomax.discourse.group/u/FEAnalyst)\
**Post date:** [September 16, 2026, 7:19am UTC](https://prepomax.discourse.group/t/local-coordinate-system-not-working-for-points-load-or-for-point-bc-and-for-gravity-load/3040/15 "2026-09-16T07:19:45Z")

</div>

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](https://github.com/Dhondtguido/CalculiX/issues)

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.
