load combinations and form-finding

[andy]

Hello,
I'm performing a form-finding (in which I need to consider a certain number of applied loads DURING the FF procedure, so I activated the specific FF load case).
After the form finding I need to perform the various code-checks so I activated the automatic generation of load combinations.

I found that the obtained results are not "automatically" correct: for instance for the serviceability limit state that consider only the self-weight (defined in load condition LC1 - self-weight) the "apparent combination" is
SLSa = LC1
This is correct, but in truth, the form-finding procedures is already accounting for the loads defined in the FF load case, and thus the "real combination" is
SLSr = SLSa + FF = LC1 + FF
The SLS combination is then not correct.

All other SLS and ULS combinations are, in fact considering the "apparent combination" PLUS the previous FF load case (implicitly present in the form-finding starting solution).

One possibility is to disable completely the automatic calculation of load combinations, and manually entering combination coefficients.
A general solution would be to define the "apparent combination" by SUBTRACTING the FF loads before adding all other loads. For instance for the SLS case defined before, I would obtain the "apparent combination":
SLSa = LC1 - FF
that would give the correct results, being the starting configuration based on FF, and thus the "real combination" is
SLSr = SLSa + FF = LC1 - FF + FF = LC1

I hope I've been sufficiently clear. Maybe there is already an option available to solve this issue: have you any suggestion?
Thanks in advance
Andy

[Frank Faulstich]

Hi Andy. We don't really understand the problem. Can you please attach a sample file.

Frank Faulstich

[andy]

Hello Frank,
let me take a step back.
Please consider the form-finding (FF) load condition equal to the self weight (that is rather common, even if not general) of the structure, as assumed in the example https://www.dlubal.com/en/support-an...ort/faq/003459 (and in the associated model).

In the model file the FF is LC1.
There is also an LC2 that has exactly the same load as LC1 (i.e. just gravity-Z) that considers the self-weight (SW).

The ultimate-limit-state (ULS) combination associated to the self-weight, as per eurocode is 1.35 SW, but as explained in the example, the coefficient to obtain this ULS is "just 0.35 LC2". Why? because LC1 (FF, that in this particular case is SW) is already incorporated as starting solution.

In this case if you enable "create combinations automatically" (inside "general data") of dlubal, you would obtain the ULS as 1.35 LC2. This is wrong (see the support question: the multiplier should be 0.35).

Now, generalizing and returing to my first post.
If the "create combinations automatically" procedure just subtracts the FF loads from all its combinations (both for ULS and SLS), then you would get correct combinations.

For this example: 1.35 LC2 - FF = 1.35 SW - SW = 0.35 SW = 0.35 LC2 (0.35 is the indicated coefficient in this example, and is correct only because FF is equal to the SW).

Hope I've been more clear, best regards
Andy

[Frank Faulstich]

Hello Andy, now things are clearer. One possibility is to apply the loads from the self-weight loading as a negative-acting prestressing load case. The following video shows the procedure.
Video1260.mp4

Frank Faulstich

[andy]

Hello Frank,
many thanks, clever solution!

I've another (totally unrelated) question: if I try to export this model to the IFC format, I obtain error message (see first picture). The written IFC file does not contain readable data.
Am I missing some system configurations or library dependency?

Instead, if I launch the "direct export to tekla structures" command, the structure is correctly exported to tekla). There is however a warning message: "Only 'Constant' surface thickness is supported..." and the surface is not exported: why? (in RFEM the surface is Constant, so I don't understand the error)

Best regards,
Andy

[Frank Faulstich]

Hello andy, I suspect that the error message in Figure 1 is related to this problem.

https://www.dlubal.com/forum/interna...teroperability

The message in image 2 is probably related to the fact that in RFEM the surface was defined as membrane and TEKLA does not know this surface type.

Frank Faulstich

[andy]

Hello Frank,
thanks for the point about the missing membrane feature interoperability: it would be an interesting feature the possibility to export to tekla the geometry after form-finding.

Andy

[Frank Faulstich]

Hello andy, I have just discussed the issue with our expert for the interfaces. The interfaces are currently designed more for normal high-rise buildings. Free-form surfaces are problematic. That's why there won't be such a feture in the near future.

Frank Faulstich

[andy]

Hello Frank,
thanks for the update.
Just my 2-cents thought.

As RFEM is already unique in the design and analysis of free-form / lightweight structures, I think it would be a strategic advantage to further enhance these capabilities. Even if I understand that it is a "niche" market with respect to the general high-rise buildings, I would think that pioneering BIM for lightweight structures could position RFEM as the tool of choice for design and construction of this kind of structures.

These are clearly strategical (mid/long-term) choices, that maybe the management could consider.
Andy

[Frank Faulstich]

Hello andy, unfortunately, this is less our choice. For data exchange, we use standards such as IFC. The IFC standard does not support freeform surfaces. First, this feature would have to be added to the IFC specification by Buildingsmart. Then the CAD manufacturers would also have to support this modified standard.

Frank Faulstich