A new developer/preview PrePoMax version v2.1.1 has been released

A new developer/preview version of the PrePoMax contains the following FEM features:

  • added support for the creation of coordinate systems in the FE model view (rectangular, cylindrical)
  • added support for the creation of coordinate systems in the results view (rectangular, cylindrical)
  • added support for the creation of reference points in the results view
  • added support for using coordinate systems at the creation of boundary conditions
  • added support for using coordinate systems at the creation of concentrated loads
  • added support for using coordinate systems at the creation of surface traction loads
  • added support for transforming the field output to another coordinate system (Result → Field Output → Create)
  • bug fixes



Some additional notes:

  • the creation of reference points was changed slightly to be the same as when creating the coordinate systems
  • the creation of the coordinate system requires the definition of three points. The center point, the point towards the first (1) axis (global space coordinates), and the point on the plane between the first and the second (1-2) axis (global space coordinates).
  • since a capability to display text in the 3D view was added, reference points and coordinate systems could get a label beside them. What do you think about it?
  • the coordinate system axes are called 1, 2, and 3 for rectangular and cylindrical systems
  • not all coordinate system configurations were tested, so please test before serious use
  • applying a coordinate system to a BC or a load ads a *Transform keyword. This keyword changes the global coordinate system of the selected nodes to a local system throughout the analysis. So, if another BC or load is assigned to these nodes in a global coordinate system actually a local coordinate system applies. A check for this situation will be added at some point.
  • a lot of code was changed or added in a short time, so expect some issues


Great job… I’ll test it right away (I’ll probably need it in my new project)… ty in andvance…

This is great. I dont know if it is possible to include the wear modes and mechanisms after wear analysis in the next editions

I don’t find clear the definition of axis 1-2-3 for cylindrical coordinates. Maybe is better something like a - r - c (axial - radial - circumferential)

1 Like

I decided to use 1, 2 and 3 since the user interface for BCs and loads is also created using the same notation.

Yeah, it makes sense. The same notation is used in Abaqus.

Is the configuration not radial-circumferential-axial (1-2-3) ?


I think that is more intuitive something like that, but is only my opinion

Currently, 1-2-3 stands for radial-tangential-axial.

So the common preference is to have x-y-z and r-t-z instead of 1-2-3?

This would require changing everything (inputs and outputs) from 1-6 to letters. I’m not sure if it’s a good idea just for the optional cylindrical csys.

However, maybe there could be a setting for this, allowing both types of naming. Many users are used to the current (Abaqus and CalculiX) syntax and it’s in line with ccx input deck.

Or maybe another way would be to keep 1-6 and just add optional letters in brackets (or appearing when hovering over the DOF number) when cylindrical CSYS is used ?

Ok, but if I remember well in CGX postprocessor with trfm cyl z (z axial) stress components are called TT, RR, ZZ
PS I found an old example

But only with cylindrical transformation and only in postprocessing ? That could be a way to use here as well. It’s rather inconsistent (with input and cartesian systems) but it could be optional or justified by the fact that only there this tip is needed.

I thought only of changing the letters on the symbols of coordinate systems and not the UI. As far as I understand, this is the Abaqus way.

So maybe I can only add a default label at the center of the coordinate system that would show if the coordinate system is rectangular R or cylindrical C. However, the user could change this label to the name of the coordinate system.

I looked at the .frd result file where the components of the fields are written, and the names of the field components do not change if one demands a local coordinate system output. So, without the input file, it is not possible to determine the orientation. I only used the *Transform card and not the *Orientation card, which might change how the results are written.

Ah, ok. That’s a totally different story then and it definitely makes sense. Sorry for the confusion.

1 Like

In all ways it is very useful improvement in pre and post processing. Thanks

1 Like

The Transform Keyword for Cylindrical user defined coordinates worked well for me, but now I am trying to understand the GUI input.

Are the points in the input panel supposed to be the points a & b that lie on the axial (z) axis ?


A rectangular system is defined by specifying a point a on the local X’ axis and a point b belonging to the X’-Y’ plane but not on the X’ axis. A right hand system is assumed.

When using a cylindrical system two points a and b on the axis must be given. The X’ axis is in radial direction, the Z’ axis in axial direction from point a to point b, and Y’ is in tangential direction such that X’-Y’-Z’ is a right hand system.

The points to be selected in GUI are not the same as are used in CalculiX. The CalculiX uses only 2 points that define the general direction but do not exactly position the coordinate system origin. To plot the coordinate system, I need the origin. So once the origin is set, the user must define the Point in the 1 axis direction. This point defined the direction of the 1 axis with regard to the origin. So, the vector difference between this point and the origin is computed. And then the Point on 1-2 plane is again defined with regard to origin. It can be any point on the 1-2 plane.

And then for the .inp file the points a and b are computed from the 3 given points.

I will change it to the Abaqus way.

1 Like