RFEM: Surface Support Bug In GRPC Client

Hey guys,

I've encountered a bug while working with the Dlubal software, specifically when trying to add surface supports using the gRPC client. It seems like the surface supports aren't being added correctly. Let's dive into the details so you can reproduce and understand what's happening.

Describe the Bug

The issue is that when I add surface supports via the gRPC client, the values I set (like translation and shear stiffnesses) don't seem to be reflected correctly in RFEM. They all show up as zero in the user interface. This is a major problem because it means the structural analysis isn't accurately reflecting the intended support conditions.

Here's an image of my surface in RFEM:

And here's the C# code I'm using with the Dlubal API:

using Dlubal.Api.Common;
using Dlubal.Api.Rfem;
using Dlubal.Api.Rfem.StructureCore;
using Dlubal.Api.Rfem.TypesForSurfaces;
using Google.Protobuf;

namespace ConsoleApp6
{
    
    public static class Program
    {
        public static async Task Main(string[] Args)
        {
            ApplicationRfem app = null;
            app = new ApplicationRfem("API KEY HERE");

            var s = new SurfaceSupport()
            {
                TranslationX = 3,
                TranslationY = 3,
                TranslationZ = 3,
                ShearXz = 3,
                ShearYz = 3,
                
            };
            s.Surfaces.Add(1);

            await app.create_object(s); 



            await app.close_connection();
        }
    }
}

In this code, I'm creating a SurfaceSupport object and setting the translation and shear stiffness values to 3. I'm then adding the surface with index 1 to this support. However, when I run this code and check the surface support in RFEM, all the values are zero.

Here's what gets added when I run the code:

As you can see, after adding the surface support, the UI shows all zeros for the stiffness values.

Root Cause Analysis

To effectively troubleshoot and resolve this issue, it's crucial to dive deep into the potential root causes. Here's a breakdown of factors that could be contributing to the incorrect surface support behavior:

1. Data Serialization Issues: The gRPC framework relies on efficient serialization and deserialization of data between the client (C# application) and the server (RFEM). Incorrectly configured or implemented serialization processes can lead to data loss or corruption. Specifically, the values assigned to TranslationX, TranslationY, TranslationZ, ShearXz, and ShearYz in the C# code might not be accurately translated into the corresponding data structures used by RFEM. This could be due to version mismatches between the client and server libraries, or incompatibilities in the data types being used.

2. API Endpoint Implementation: Within the RFEM API, the endpoint responsible for handling surface support creation and modification may contain bugs or logical errors. The API code could be failing to properly interpret the incoming data, leading to default values (zeros) being assigned instead of the user-specified values. A thorough review of the API endpoint's code is necessary to identify any potential flaws in its data processing logic.

3. Unit Conversion Problems: Different parts of the system (client application, gRPC framework, RFEM server) might be using different units of measure for stiffness values. If the client application sends values in one unit (e.g., kN/m), but the RFEM server expects values in a different unit (e.g., N/mm), a conversion error could occur, resulting in incorrect values being stored. Ensuring consistent unit usage across all components is critical to prevent such issues.

4. Data Validation and Constraints: The RFEM API might enforce certain validation rules or constraints on the allowed range of surface support stiffness values. If the values specified in the C# code fall outside of these valid ranges, the API could be rejecting the values and reverting to default values (zeros) without providing an explicit error message. It's important to understand the expected value ranges and ensure that the specified values comply with these constraints.

5. Asynchronous Operation Issues: The code snippet provided uses asynchronous operations (async and await). If the asynchronous operations are not properly synchronized or managed, race conditions or data corruption issues could arise. For example, if the create_object method doesn't correctly handle asynchronous data updates, it could lead to the surface support object being created with default values before the specified values are applied.

To Reproduce

To reproduce this bug, follow these steps:

1. Create Basic Geometry: Add four nodes on the canvas in RFEM.
2. Define Lines: Create lines connecting the nodes to form a surface boundary.
3. Add Surface: Add a surface element to the lines you just created. This will define the area where you'll apply the surface support.
4. C# gRPC Client Setup: In your C# gRPC client, create a SurfaceSupport object.
5. Set Non-Zero Values: Set the TranslationX, TranslationY, TranslationZ, ShearXz, and ShearYz properties of the SurfaceSupport object to non-zero values (e.g., 3 as in my example).
6. Add Surface Index: Add the index of the surface you created in RFEM to the Surfaces collection of the SurfaceSupport object. Make sure the index is correct.
7. Run the Code: Execute the C# code to send the surface support data to RFEM via the gRPC client.
8. Inspect in RFEM: Open the RFEM user interface and inspect the properties of the surface support you just added. You should see that the values for translation and shear stiffness are all zeros, even though you set them to non-zero values in the code.

Environment

• OS: Windows 11 24H2
• RFEM Version: 6.12.6
• Tool/Library Version: (Assuming the latest, but please specify if using a specific version) - Version of tool / library [e.g. 22]

Possible Solutions and Next Steps

Okay, guys, let's brainstorm some potential solutions and outline the next steps to tackle this pesky bug. Based on the root cause analysis, here's a roadmap we can follow:

1. Double-Check Data Serialization: We need to meticulously examine how the data is being serialized and deserialized between the C# client and the RFEM server. Here's what we can do:

   • Verify Library Versions: Make sure that the client libraries (Dlubal.Api.*) and the RFEM server components are using compatible versions. Mismatched versions can lead to serialization errors.
   • Inspect Protobuf Definitions: Dive into the Protobuf definitions (.proto files) that define the structure of the SurfaceSupport message. Ensure that the data types used in the C# code match the data types defined in the Protobuf definitions. For example, if TranslationX is defined as a double in the Protobuf definition, make sure you're using a double in your C# code.
   • Monitor Data Payloads: Use a network traffic analyzer (like Wireshark) to capture the raw gRPC messages being sent between the client and the server. This will allow you to inspect the serialized data and verify that the values are being transmitted correctly.

2. Examine the API Endpoint: If the data serialization checks out, the problem might lie within the RFEM API endpoint that handles surface support creation. Here's how we can investigate:

   • Review API Code: If possible, get access to the source code of the API endpoint. Step through the code to see how it processes the incoming data and how it assigns the values to the surface support object.
   • Add Logging: Add detailed logging statements to the API endpoint to track the values of the TranslationX, TranslationY, TranslationZ, ShearXz, and ShearYz properties at various stages of the processing pipeline. This will help pinpoint where the values are being lost or overwritten.
   • Unit Testing: Create unit tests for the API endpoint to verify that it correctly handles different combinations of input values. This will help identify edge cases or boundary conditions that might be causing the issue.

3. Address Asynchronous Issues: Asynchronous programming can introduce complexities, so let's make sure that our asynchronous operations are rock-solid:

   • Review Task Synchronization: Carefully review the code that uses async and await. Ensure that the tasks are being properly synchronized and that there are no race conditions or deadlocks.
   • Error Handling: Implement robust error handling to catch any exceptions that might occur during the asynchronous operations. Log these exceptions to help diagnose the problem.
   • Consider Alternatives: If the asynchronous code is too complex, consider simplifying it by using synchronous operations instead. This might make it easier to debug and maintain.

4. Contact Dlubal Support: If you've exhausted all other troubleshooting steps, it's time to reach out to Dlubal support. Provide them with a detailed description of the problem, including the steps to reproduce it, the code snippets you're using, and any relevant error messages or logs. The Dlubal support team has in-depth knowledge of the RFEM API and can provide valuable assistance in resolving the issue.

By systematically investigating these potential causes and following these steps, we should be able to get to the bottom of this surface support bug and ensure that our structural models accurately reflect the intended support conditions. Let's keep each other updated on our progress as we work through these steps!

I hope this detailed breakdown helps in resolving the issue. Let me know if you need more information or have any other suggestions.