Material units

SOFiSTiK Teddy
1

Hi

I’m struggling with assigning units to my material:

+prog aqua
del#*
UNIT 6
let#emod 35000[N/mm2]
let#gamma 50[kN/m3]
MAT NO 1 E #emod GAM #gamma
end

If I remove [kN/m3] from the #gamma definition, It runs smoothly, but as I’m running a big model I’d like to use explicit units everywhere.

Why doesn’t gamma work with units?

2

Hey, try do it like this:
let#gamma 50
MAT NO 1 E #emod GAM #gamma[kN/m3]

3

Hi, that works as well, but it just seems strange why I can make the variable E #emod with a unit but not for G #gamma ?

surely this must be an error in the software, or am I missing something?

4

Hello

In order to understand the error message, you have to know that the program uses two different unit sets with the same unit [kN/m3].
The first set (78) is used for most of the standard cases (LET #gamma 50[kN/m3]).
The second set (1091) is used for the density of a material in the command item “MAT GAM”.
The background for this case is described within the following chapter of the AQUA manual:

SSD / TEDDY > Help > User Manuals > All Manuals… > AQUA > 2.1 Materials

So if you preallocate the variable with the unit, the program actually allocates, in this special case, the “false” unit set.
Due to the program algorithm this behaviour will not be changed in the future. So as a workaround I would suggest to use the following code:

LET#emod 35000[N/mm2]
LET#gamma 50[-]    $ [-] assignment of the variable without any unit

MAT NO 1 E #emod GAM #gamma[kN/m3]

Best regards
Frederik Höller
Your SOFiSTiK Support Team

5

Okay, thank you for the clarification.
So this peculiarity is only related to densities when assigning material parameters?

6

This behaviour applies to all variables with the unit set 1091.
The number of the unit set can be found in the associated manual.

7

Also ich hatte bei Verwendung von Unit-Festlegungen schon mehrfach Probleme, u.a. damit, dass SOFILOAD bei bestimmtem Lasten eigentlich zulässige Berechnungen mit >= 2 Variablen aus Unitgründen nicht mehr wollte.
Und ein NoGo ist für mich, dass schon bei der Eingabe intern der Variablenwert in die Grund-SI-Einheit umgewandelt wird (s. allg. Handbuch 2.2.14) !
Die Einheitenfestlegung bei let# sollte deshalb vielleicht besser immer unterbleiben.
So wird dann z.B.:
LET#V_MIT_UNIT 30[MM]; TXA AUSGABE -->#(V_MIT_UNIT,3)<-- Ausgabe -->0.030<–( [mm] werden zu [m] gewandelt)
LET#V_OHN_UNIT 30 ; TXA AUSGABE -->#(V_OHN_UNIT,3)<-- Ausgabe → 30<–
LET#V_MIT_UNIT 30[ft]; TXA AUSGABE -->#(V_MIT_UNIT,3)<-- Ausgabe → 9<-- ( [ft] werden zu [m] gewandelt !!)
Intern mag das bei Programmieren helfen, nur ich als Anwender kann da ziemlich ins Stolpern geraten.

8

Eine gewisse Abhilfe für das Wert-Konvertierungsproblem bei Variablendefinition MIT UNIT-Bezug würde m.E. die ZWANGSWEISE UNIT-Ausgabe (und nicht nur des Wertes) schaffen, also dann:
LET#V_MIT_UNIT 30[ft] ==> Ausgabe → 9 [m]<–
Ob das ginge weiß ich nicht, aber da lt. Handbuch die Variableneinheiten vererbt werden, könnte es gehen (auch über Modulaufrufe hinweg mit STO-Variablen ?). Das fände ich dann zumindest konsequent.

1 Like