Ankündigung

Einklappen
Keine Ankündigung bisher.

load combinations and form-finding

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • load combinations and form-finding

    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

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

    Frank Faulstich
    Support Team der
    Dlubal Software GmbH
    [email protected]
    https://www.dlubal.com

    Kommentar


    • #3
      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

      Kommentar


      • #4
        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
        Support Team der
        Dlubal Software GmbH
        [email protected]
        https://www.dlubal.com

        Kommentar


        • #5
          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

          Kommentar


          • #6
            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
            Support Team der
            Dlubal Software GmbH
            [email protected]
            https://www.dlubal.com

            Kommentar


            • #7
              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
              Zuletzt geändert von andy; 27.05.2021, 13:02.

              Kommentar


              • #8
                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
                Support Team der
                Dlubal Software GmbH
                [email protected]
                https://www.dlubal.com

                Kommentar


                • #9
                  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

                  Kommentar


                  • #10
                    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
                    Support Team der
                    Dlubal Software GmbH
                    [email protected]
                    https://www.dlubal.com

                    Kommentar

                    Lädt...
                    X