search

DLR-SL / CPACS

CPACS - Common Parametric Aircraft Configuration Schema
http://dlr-sl.github.io/CPACS/
Apache License 2.0
78 stars 38 forks source link

Inconsistency in joint name definition of control surface tracks #814

Closed anschust89 closed 9 months ago

anschust89 commented 1 year ago

There is an inconsistency within the CPACS-documentation regarding the naming scheme of the track joints of the control surfaces kinematics. Within the graphical representation of the different kinematic types at https://www.cpacs.de/documentation/CPACS_3_4_0_Docs/html/f441e070-dd48-6e0f-0cfb-2ebd172942cc.htm

the joint names always start with "P0".

On the other hand, the allowed names for the joints at https://www.cpacs.de/documentation/CPACS_3_4_0_Docs/html/e13066fd-04cb-cd3d-1ba5-e575ba9672e9.htm

start with "P1" and does not include "P0".

Which definition should be seen as the correct one?

MarAlder commented 1 year ago

True, nicely spotted!

@raedma, what would you say?

raedma commented 1 year ago

Naturally, I would go the pragmatic way and choose the solution of least resistance. Two possiblities:

From a coding point of view I would like to start with index 0. However, one has to keep in mind the commonality with the rest of CPACS. I do have in mind that indices in CPACS arrays start with 1 not 0. See from a tixi message for the first ID:

/cpacs/vehicles/aircraft/model/wings/wing[1]/componentSegments/componentSegment[1]/controlSurfaces/trailingEdgeDevices/trailingEdgeDevice[1]

I do not know if that is a Tixi or a CPACS thing? So initially I would ask Rene to update the sketches for the documentation to start with P1 and keep the nomenclature in the second link.

MarAlder commented 1 year ago

For some historical reasons we usually start with 1 in CPACS. We had the discussion about indexing the profile kinks. One argument was that it is consistent with XPath, which is one of the most important technologies when working with CPACS.

So maybe we should stick to 1 if René could update the sketches?

hollre commented 1 year ago

I am a bit torn about that. Basically we could just change the sketches. However, the numbering within the sketches (especially with the point P0, which is apparent in all mechanism types) is a convention we use in our design tool to mark the actuator position. I also saw this in other literature, although it is by no means in "industry standard". In my view the Points P0, P1, P2, ... describe certain points within a mechanism type, such as, actuatior attachment or hinge point, etc. rather than being an index. The generic terms P# are rather used due to the reason, that different mechanism types, do not share the same set of joints (except for the current P0). But I also see the inconsistency issue to the rest of CPACS. So I would rather prefer a change of the nomenclature. What do you think?

MarAlder commented 1 year ago

I think the importance of consistency outweighs in this case. For this reason, we have also moved to 1 for the kink indices. Since the data schema should be as independent of tool implementations as possible, we should be less concerned with this, especially since there is no official standard for it.

I would like to release a beta version this week and then move to an alpha version and the final 3.5 release in October. Maybe we can include the modified sketch there?