Unexpected results from CTiglInterpolatePointsWithKinks

[Leitner224]

Hello. We happened upon an issue during the generation of a fuselage with defined kinks, where the computed profile curves overshoot on a kink edge as shown in the pictures below.

We are not sure if this is a problem with our definition or if there is an issue with the loft generation. If it is possible, could you please check our .XML file where the issue happens for us ? It is attached below. kinkOvershoot.zip

Best regards and thank you for your time, Leitner A.

[joergbrech]

Thanks for opening an issue!

In CPACS all indices start counting at One. Is it possible, that you count your point indices for the kinks starting at Zero? I plotted the FuselageProfile2 in matplotlib and marked the kinks:

If I shift all indices by +1 (see kinkOvershoot.zip) there are no overshoots. Is this what you were going for?

[joergbrech]

@Leitner224 could you please check if my assumption of an off-by-one error was right?

[rainman110]

For me it seems, that the kinks are not placed anymore at the right position if you compare againts the profile that you draw earlier. There are these strange osscillations right before the kink. In the original image, it looked correct but it had this overshoot that probably came from reparametrization.

[rainman110]

Obviously, I implemented the indices starting from 0. Unfortunately, this does not really comply to the rest of the numbering in cpacs. see here: https://dlr-sc.github.io/tigl/towards-tigl-31.html

[Leitner224]

@joergbrech sorry for my late response. As rainman110 pointed out, there is no overshoot after the +1 shift, but the kinks are missplaced in this case.

[rainman110]

Just a guess, but I suppose the overshooting is caused by the reparametrization. In particular, because only one profile overshoots. This is done when creating the loft from the profiles. So it is probably a good idea to look at the profiles before lofting.