GenCase v 5.0.174 and calculation of moments of inertia

Dear Developers,

As we all know, moments of inertia are key design parameters for structures withstanding loads that cause rotations. In the context of naval and ocean engineering, think of ships, floating reservoirs, drilling platforms, whether subject to mutual contact or to wave slamming/sloshing.

Earlier last year, I possibly identified a limitation in the way GenCase version 4 computed the moments of inertia of floating objects. In particular, GenCase was not able to obtain the same diagonal, same-valued tensor of inertia for three identical cubes (picture at https://forums.dual.sphysics.org/uploads/305/D4L13U40FE4X.png). For the discovery process and outcomes of that investigation, please see the comment https://forums.dual.sphysics.org/discussion/comment/3215/#Comment_3215 and up there, with XML snippets and shell scripts attached.

In sum, the calculation of the moments of inertia was correct only if the ratio between the cube edge and the particle spacing is an integer number. Otherwise strange things occur – see in that post the spread of results for arbitrary particle spacing. Maintaining integer ratios between particle spacing and any dimension defining several floating objects is too restrictive for real-word applications. Therefore, if this is correct, GenCase 4 may have done well for academic test cases, but was hardly suited for real-world applications. As a consequence the same perplexity applies to DualSPHysics, since one does not really know what is going on.

I have repeated the same test with GenCase v 5.0.174 (16-04-2020) and I am afraid that the problem is still there. The cubes’ edges are 1 unit, and

  • If the particle spacing is 0.125 units (1/8), the (principal) moments of inertia are the same within and across each cube (0.208333, 0.208333, 0.208333; pass).
  • If the particles spacing is 0.120 units (1/8.33) two cubes have (principal) moments of inertia (0.192,0.192,0.192; pass) but the last one has (0.2148,0.192,0.2148; fail).

I understood that this issue had ended up in the to-do list. Not having heard of any progress in the meantime, it would be important to know whether you could replicate it in the first place. Would you please let me know?

Comments

  • Hello Giodarno,

    This is a standard error due to discretising an object into discrete particles which will only align with the axes of symmetry for special (integer division) cases. It's good you are applying standard practice by checking values before you run simulations. Such human checks are not automated at the moment. You can always compute the moment of inertia with any other software or procedure and just include those values so that GenCase will not compute anything and the values used are defined by the user.

    I hope this helps,

    Ben

  • Hi Giordano,

    Let me just add that the way gencase it is conceived is to deal with complex geometry for which computing moments of inertia cannot computed analytically. As you might appreciate, while the moments you get are not exacts, they convergence to the exact value when you are increasing the resolution.


    Best regards

    Renato

  • edited July 3

    About:

    Thanks @Ben. Good to know that this is an acknowledged error and that the inertia tensor should be custom-input for all general cases of interest, beside the simplest ones.

    Please note, though, that in the case of non-integer ratios two cubes are fine, and one is not; this cannot be a standard error otherwise it should apply, or do not apply, equally well over repetitions. There is some error because of the repetition.

    Your remark does help, as it indicates a prudent modelling practice.

  • edited July 3

    Hi @Renato

    It is clear to me that moments of inertia are computed numerically, whereby they converge to the design values with decreasing particle spacing. This behaviour is, however, only retrieved when the ratio L/dp is integer. See this chart below from the comment https://forums.dual.sphysics.org/discussion/comment/3215/#Comment_3215 mentioned above; the design value is the lowest horizontal line (I=0.167 units); the behaviour you mentioned is the thick grey line.

    There are two implications I feel to underscore:

    a) this way of computing moments of inertia numerically is such that a floating object in DualSPHysics will always behave more sluggishly than assigned. Let's expect thus less angular acceleration for given torques, or a greater torque to obtain a given angular acceleration. A discretization error with physical relevance just to know, not unlike the numerical diffusion of different contexts.

    b) there is a more insidious problem when the size/spacing ratio is not an integer number. Ben has given a valuable workaround above. Yet, there is still something that could be improved in terms of internal consistency of GenCase (*). Unless I have made some mistake, of course; that's why my post question was whether you could reproduce this.


    Hope this is relevant.

    (*) By the way, I had chosen the symbols for each moment of inertia so that, when the values coincide, the symbols form a square. So you can distinguish the error of deviating from expected convergence from that of not seeing a cube as a rotationally symmetric object. Take note: the coordinate axes and the principal axes of inertia are parallel here.

  • Hi Giordano,

    I don't think there is any inconsistency in gencase, or at least I can't see it from you analysis. You just demonstrated that the moments of inertia computed by gencase are not identical to the analytical ones. This is due to a numerical approximation which (in my opinion) is fine, as long as the numerical error decreases when Dp goes to zero.

    The fact that the moments of inertia computed by gencase are not for simple symmetric geometrical objects (such as a cube) is just a side effect of the numerical approximation we adopted. Finally you can overcome the issue by forcing the correct moments of inertia in the input file (as explained before).

    Best regards

    Renato

  • edited July 4

    Three separate points, please to be handled separately if possible.

    #1 I presume that the moments of inertia you have in mind are those with respect to axes parallel to the reference system and passing through the centre of mass of the object. Also considering that computing the inertia matrix with another program than GenCase is among the suggested/recommended options, would you please add to the XML documentation of 5.0 (XML_GUIDE_v5.0.pdf, section 2.6, p.71) which moments of inertia do you model in DualSPHysics?

    And, also, would you mind it to align the User’s Guide to that? Not unlike some peer-reviewed publications, the formulation at https://github.com/DualSPHysics/DualSPHysics/wiki/3.-SPH-formulation#384-fluid-driven-objects still speaks about a single, scalar moment of inertia, while in the general 3D case it should be a tensor/matrix.

    #2 I admit ignorance, but I find it difficult to figure out a procedure returning good results for a drilling platform (complex object) and less good results for a lifebuoy (simple object). My expectation is that calculating the moments of inertia of a system of particles entails no more than an embarrassingly parallel summation of masses times squared distances. I understand that GenCase is a closed-source program and am fine with it. Would you mind it, nonetheless, to mention in the User’s Guide which algorithm you use for computing the six moments of inertia in an inertia matrix?

    @rvacondio #3 I find it puzzling when a program returns different results for the same task repeated. Think of counting the number of words in the sentence “count my words”. The result is 3. If I repeat the task on that sentence copied and pasted any number of times, the result remains 3.

    In contrast, in my experiment, the moments of inertia changed with the number of times GenCase computed the moments of inertia. The third cube, identical to the first two, yields different results than the first two, some times. Additionally, truncation errors generally lead to smooth and regular results (the thick grey line) and do not exhibit scatter (among and inside identical objects).

    So I still beg to differ on this point and consider GenCase as inconsistent. Unless I have overseen something else that I escaped me and my situation cannot be reproduced, which is what I asked in the first place: that should open another tack of inquiry and might close this one.

    I certainly agree that it is in my best interest to overcome this issue by setting a custom inertia matrix; to do so adequately, I come back to points #1 and #2.

  • Dear Giordano,

    Please send me the xml you are using to compute the moments of inertia together with the script (.sh or .bat file) you are using to execute gencase. I'll try to have a look.

    Best regards

    Renato

  • edited July 6

    I have created a separate topic about enhancing the documentation at https://forums.dual.sphysics.org/discussion/1814/moments-of-inertia-request-for-documentation (points #1 and #2 above). Here we can isolate whether a bugfix is necessary (#3 above).

    @rvacondio Thanks Renato (and any other volunteer) for taking the time to help with this.

    To make the tests as independent of each other as possible, I would propose that you copy and paste the minimum amount of lines in a baseline code of your choice. The necessary information has been waiting for you like messages in a bottle almost for one year :-) namely

    The XML snippet should only require that the simulation domain is large enough to host the three cubes.

    The script runs GenCase upon setting the particle spacing from the command line. It contains some basic comments to understand what it does, hopefully. You can choose the set of particle spacings to be tested by changing the last of lines 91-93 (integer L/dp ratios, sample of random L/dp, single value); then choose your custom name for the case and path in lines 97-98; and the GenCase binary name in line 108. The script also contains some functions that strip XML clutter from the output file, but this should only be cosmetics.

    As above, I would recommend that you only borrow the lists of particle spacing, insert them in your own script, and see if you obtain the plot above. Actually, the simplest test is to try with dp=0.125 and dp=0.120 and see if you get the same values as at the top of this discussion.

    Looking forward to reading from you!

  • Dear Giordano,

    I reiterate the request: I need the exact xml file you are using (even if it is the most simple one) and not just the cube definition.

    Can you please send it to me? If no I won't be able to reproduce your results.

    Best Regards

    Renato

  • edited July 6

    @rvacondio Yes of course. Attached herewith disguised as txt files, to work around the format not allowed by upload. Also with a file for mock floating materials. Thanks again

Sign In or Register to comment.