# How to use non-dimensional form in open source codes instead of Units

I am using an open source FEM platform, which requires you to convert your equation system to non-dimensional form. So, there are no units specified for the parameters in the problem. If you use compatible input units, you should expect the output in matching unit - just like one would do in a normal python or C++ code for solving physical problems. I have an elasto-plastic dynamic problem to solve, and these are the parameters for the Drucker-Prager Soil Model for soft clay.

E = 5000000;                 // Young's Modulus in N/m^2 or Pa
nu = 0.35;                   // Poisson's Ratio Unitless
cohesion = 20000.0;          // N/m^2 or Pa
dilatancy_angle = 25.0;      // Degrees
hardening_parameter = 0.1;   // Unitless
friction_angle = 25.0;       // Degrees
double rho = 1750.0;         // Mass density in kg/m^3


The mesh is a (1 x 1) square mesh. So when I see the displacement caused by wave propagating on this mesh using the above parameters, in Paraview, is it meaningful to assume that the output shall be in metres (m). Also, in such platforms, how does one compare the mesh to a realistic scenario? For example, can I assume that my mesh is a 1km x 1km square ground surface and the displacement I am viewing is in metre? What if I take a (10 x 10) mesh? Can anyone please explain how this non-dimensional logic works?

The answer is very simple: you provide the code with geometric information, i.e. nodal coordinates (which in your case are expressed in metre), and not only topological information, i.e. how the mesh is laid out and connected to the nodes.

So depending on the nodal coordinates you provide, you can have different domain "sizes". E.g. if you have four nodes with coordinates $(0,0,0)$, $(100,0,0)$, $(100,100,0)$, $(0,100,0)$ then you are modelling a 100m square.

Of course all quantities (geometric, material properties, boundary conditions) shall be expressed in consistent units. As a general rule, if you use only SI units (kg, m, s, and their derivatives) you are on the "safe" side.

A final comment about the term "non-dimensional form". The way in which I like to understand what is going on is that I'm feeding the FE code with the numerical values of the physical quantities in a given consistent system of units, say SI. The output of the code will be the numerical values of the computed physical quantities in the same system of units.

A true non-dimensional form is a more general concept, in which you rewrite the equations so that the variables are pure numbers and not physical quantities.

• Thank you for explaining that Stefano! In that case I can expect the displacement to be in metres in the problem I specified, only if the dilatancy angle and the angle of friction are in radians (not degrees). Is that reasonable? – CRG Oct 15 '16 at 0:22
• You have to check the software user manual. The dilatancy angle and the angle of friction are material model parameters that occur only as arguments of a trigonometric function, (e.g. $\sin\phi$, $\tan\theta$), and it all boils down to how the material model is implemented. For historic reason commercial engineering FEM codes prefer material angles expressed in degrees. E. g. Abaqus states 'Material angle of friction, $\beta$, in the $p$–$t$ plane. Give the value in degrees.' – Stefano M Oct 15 '16 at 13:30
• As a side-note, you observation is correct for quantities like the angular velocity $\omega$, for which $v_\perp = \omega \cdot r$ holds. In this case the expression is correct only if $\omega$ is expressed in 'radians over time'. – Stefano M Oct 15 '16 at 13:32
• Thank you Stefano! I checked with the author, he said radians is good in this case. Your answers were very insightful! – CRG Oct 17 '16 at 20:11