wrong load direction after loading a saved document

[bernd]

... Only the solver documentation knows what to put where. They could ask for forces per length or per element. The solver could work on dimensionless values.

+1

An where does the factor 1000 originate? ...

The factor is to correct the youth modulus unit and therefore should be at the youth modulus in my opinion.


OK guys may be step by step ...

The following branch has changes to get correct results using the FemWB

fix1 - load direction
fix2 - adaption of youth modulus unit is made at youth modulus and no longer at the load
fix3 - material cards of steel and concret to work with fem

https://github.com/berndhahnebach/FreeC ... r/tree/fem

attached an example file for testing (you may have to click on FemConstraintForce first to correct the direction, the original problem of this thread see first post) EDIT: CalculiX example http://web.mit.edu/calculix_v2.7/Calcul ... node7.html

FemWB f = 0.0879 m
BeamFormula f = 0.0877 m
CalculiX orginal file from manual f = 0.0877 m



with the applied patch and this real workl example it is may be easier to talk about the load unit stuff ...

[shoogen]

youth modulus

Thomas Young.
It appeared in the Big Bang Theory season 8 episode 2.

But a conversion factor is not part of a dimension L. It is part of a calculation with units.
if you convert MPa to GPa it introduces a factor of 1000. But i think we should document all those units in comments.
The hole discussion is about, messing with(out) units.

[bernd]

youth modulus

Thomas Young.

upps Yeah should be YoungsModulus, for sure not enouth sleep last night ...

[shoogen]

CLOAD does concentrated load per element.
DLOAD does hydrostatic pressure (on facets) and mass loads.
so we need to use CLOAD for line loads and distribute the cload based on the length of the edges. ? (or stop the user from doing that in case of an unsuitable mesh)
Or am I mixing up 1D,2D and 3D elements?

[saso]

Look at just the units in an mathematical formula (force = load * length) 1N = 1N/m * 1m, meters go away...

Yes. But units are arbitrary. Only the solver documentation knows what to put where. They could ask for forces per length or per element. The solver could work on dimensionless values.

What I was trying to show in this example, it is a very different thing to ask from the user for a value with N or N/m2

So let me try to ignore the different terms and present the issue just with units and math:
have a surface area of 2 x 2 m = 4 m2
if user provided value is 1,5 N/m2 then for the full area it is 4 m2 * 1,5 N/m2 = 6 N
if user provided value is 1,5 N then for the full area it is 1,5 N <- this is how the current implementation works

An where does the factor 1000 originate?

We are talking here about if it should be N, kN, MN and mm, m,... right, so to say the scale/magnitude? I was totally ignoring that in my previous posts and was just trying to show the difference between asking for N or N/m2 and that it is because of this why I believe showing the correct units is important. As can be seen from the example above the N or N/m2 give two totally different "masses". In both cases we talk about the distributed load.

And about the factor 1000 (scale/magnitude), while it is true that the solver can work ignoring this, it is fact that in FC we create objects at a scale, so we automatically have a predefined unit of length/area and for FEM the unit of force should scale accordingly to it. It is the same reason as above why I believe it is important to show the units so the user know if he should provide N, kN or MN for the results to be correct.

[saso]

CLOAD does concentrated load per element.
DLOAD does hydrostatic pressure (on facets) and mass loads.
so we need to use CLOAD for line loads and distribute the cload based on the length of the edges. ? (or stop the user from doing that in case of an unsuitable mesh)
Or am I mixing up 1D,2D and 3D elements?

Concentrated loads are normally always working on a single point, so they are actually a line/vector on a point/vertex, nothing else and always have the unit N (ignoring the magnitude kN, MN,...).

Distributed loads can work as line loads or surface loads. In case of line loads they are a surface/face on a line/edge and have the unit of N/m or N. Surface loads are solid on a surface/face and have the unit of N/m2 or N.

This "or N" was actually the point of my previous posts.

But I am not sure if we are still trying to solve the same problem

[saso]

Concentrated loads are normally always working on a single point, so they are actually a line/vector on a point/vertex, nothing else and always have the unit N (ignoring the magnitude kN, MN,...).

Distributed loads can work as line loads or surface loads. In case of line loads they are a surface/face on a line/edge and have the unit of N/m or N. Surface loads are solid on a surface/face and have the unit of N/m2 or N.

This are just sort of theoretical representations of them to help understand them visually. Non of this has to be actually created in FC, Fem tools and the solver take care of it, one just has to provide the correct values...

[saso]

http://www.autofemsoft.com/help/idd_for ... rties.html
http://www.autofemsoft.com/help/idd_pre ... rties.html

[bernd]

Just tested

git commit 71154f5 fixes the issues.

Mhh, the problem still exists ...

- open the document
- load direction is direction of z
- Open FemConstraintForce
- click ok --> load direction is again in y-direction but,

Code: Select all

<unknown exception traceback><type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'execute'

- check the attributes by python

Code: Select all

>>> App.ActiveDocument.FemConstraintForce.Direction
(<Part::PartFeature>, ['Edge6'])
>>> App.ActiveDocument.FemConstraintForce.DirectionVector
Vector (0.0, 1.0, 0.0)
>>> 

- looks good to me
- save the document --> close the document --> load the document
- load will be again in z-direction

Code: Select all

>>> App.ActiveDocument.FemConstraintForce.Direction
(<Part::PartFeature>, ['Edge6'])
>>> App.ActiveDocument.FemConstraintForce.DirectionVector
Vector (0.0, 0.0, 1.0)

- Mhh could it be the attribut DirectionVector is saved wrong in the FreeCAD saved document

How would I check this?

[bernd]

Extracted the document. There is a file Document.xml and line 151 looks good to me

Code: Select all

<Property name="DirectionVector" type="App::PropertyVector">
	<PropertyVector valueX="0.000000000000" valueY="1.000000000000" valueZ="0.000000000000"/>
</Property>

If I would like to change something for testing purposes how do I get a valid FCStd file from all the unpacked files.FCStd seams not a zip. What format is it?