WingCell.getLoft() error

[hardt-fa-flb]

I get an error if I try to get the wing cell shape of a test CPACS file with a circular beam:

Beam_Composite_Export_Test_32.zip

The error message:

    self._shape = cell.get_loft().shape()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <tigl3.configuration.CCPACSWingCell; proxy of <Swig Object of type 'tigl::CCPACSWingCell *' at 0x0000029C9945DAB0> >

    def get_loft(self) -> "PNamedShape":
        r"""
        get_loft(CCPACSWingCell self) -> PNamedShape
    
    
        """
>       return _configuration.CCPACSWingCell_get_loft(self)
E       RuntimeError: OpenCASCADE Error: BSpline curve: at least 2 poles required

[joergbrech]

I am sorry for keeping you waiting. When opening your CPACS file in TiGL Viewer, you will see a bunch of error messages in the console:

I believe your CPACS file is ill-formed? The eta1 and eta2 coordinates of the inner and outer cell borders need a coordinate and a referenceUID: https://www.cpacs.de/documentation/CPACS_3_3_0_Docs/html/103ad7fc-072e-f9e2-4f26-15266af61839.htm.

Could you please check if fixing this resolves your problem?

[hardt-fa-flb]

Hey, sorry, the CPCAS-file was ill-formated. I just overlooked the referenceUID element... But thank you for your help!

[hardt-fa-flb]

Unfortunately there is still an error with the same method and the now valid CPACS file (Beam_Composite_Export_Test_33_cell.zip):

self = <tigl3.configuration.CCPACSWingCell; proxy of <Swig Object of type 'tigl::CCPACSWingCell *' at 0x000001E2028AEB70> >

    def get_loft(self) -> "PNamedShape":
        r"""
        get_loft(CCPACSWingCell self) -> PNamedShape
    
    
        """
>       return _configuration.CCPACSWingCell_get_loft(self)
E       RuntimeError: Cannot associate projected point with (u,v)-coordinates

[joergbrech]

I confirm this is a bug. The logic in the following code block is wrong, we must also differentiate between lower and upper shell when determining the umin and umax values:

tigl/src/wing/CCPACSWingCell.cpp

Lines 731 to 740 in 3260a54

	if ( border == ChordWiseBorder::TE ) {
	if (fabs(u-umin) > tol ){
	umin = u;
	}
	}
	else {
	if (fabs(umax-u) > tol ){
	umax = u;
	}
	}

As a workaround, you could use the new contour coordinate definition:

<cell uID="test_cell">
    <skin>
        <material>
            <compositeUID>SymmetricBalancedIso</compositeUID>
        </material>
    </skin>
    <positioningInnerBorder>
        <!--
        <eta1>
             <eta>0.3</eta>
             <referenceUID>beam_component_0</referenceUID>
         </eta1>
         <eta2>
             <eta>0.3</eta>
             <referenceUID>beam_component_0</referenceUID>
         </eta2>
        -->
        <contourCoordinate>0.3</contourCoordinate>
    </positioningInnerBorder>
    <positioningLeadingEdge>
        <!--
        <xsi1>0.2</xsi1>
        <xsi2>0.2</xsi2>
	-->
        <contourCoordinate>0.2</contourCoordinate>
    </positioningLeadingEdge>
    <positioningOuterBorder>
        <!--
        <eta1>
            <eta>0.7</eta>
            <referenceUID>beam_component_0</referenceUID>
        </eta1>
        <eta2>
            <eta>0.7</eta>
            <referenceUID>beam_component_0</referenceUID>
        </eta2>
        -->
        <contourCoordinate>0.7</contourCoordinate>
    </positioningOuterBorder>
    <positioningTrailingEdge>
        <!--
        <xsi1>0.8</xsi1>
        <xsi2>0.8</xsi2>
	-->
	<contourCoordinate>0.8</contourCoordinate>
    </positioningTrailingEdge>
</cell>

[hardt-fa-flb]

When using the get_loft method with larger models, an unusual behavior occurred: with a small test case (Beam_Composite_Export_Test_32_cell2.xml) with one segment, the get_loft method works for several cells. In a larger test case with several segments (IEA-10.0-198-RWT_CPACS_contour_coordinates.xml), only the cells on the first segment are created correctly. Is that a bug or can only one segment be used with the contour coordinate definition of the cells?

CPACS.zip

[joergbrech]

@hardt-fa-flb, I opened a new issue, because your last comment exposes an issue unrelated to the first one. I think it might be a bug, but I need to dive deeper.