We suggest making a few refinements to the tanks definition introduced in CPACS v3.5.
The main motivation is that the new tank concept introduced with CPACS v3.5 has already proven useful in first practical implementations, but the current placement below fuselages is too restrictive for broader application. In particular, these tanks should be placeable not only in fuselages, but also in other geometric components such as wings, nacelles, or other geometry components.
Background
The original tank concept was introduced in the context of cryogenic fuel storage in CPACS v3.5. The main idea was to provide a more independent tank geometry than the classical wingFuelTank / fuselageFuelTank definitions based on borders such as ribs or spars.
Relevant background:
The current proposal reflects the experience gathered from first implementations and usage:
In parallel, TiGL support for the new tank definition was requested here:
The corresponding TiGL implementation has meanwhile been completed and tested:
Proposed changes
1. Move vessel-based tanks to aircraft/model level
We propose moving the vessel-based tanks from the fuselage subtree to aircraft model level:
- move
genericFuelTanks/genericFuelTank out of .../fuselages/fuselage
- introduce them at
vehicles/aircraft/model/fuelTanks
The parent-child relation should no longer be expressed by XML nesting below fuselage, but via a parentUID reference on fuelTank.
This makes the placement concept consistent with other CPACS geometry elements and allows tanks to reference different geometric parents, e.g.
fuselagewingnacelle- potentially other geometric components in future extensions
This is the key functional motivation for the refinement.
2. Revert the v3.5 renaming of fuselage-integrated tanks
In CPACS v3.5, the former fuselageFuelTanks were renamed to integratedFuelTanks in order to distinguish them from the newly introduced vessel-based tanks.
With the proposed relocation of the vessel-based tanks to model level, this ambiguity disappears. Therefore, we propose restoring the former naming:
integratedFuelTanks -> fuselageFuelTanksintegratedFuelTank -> fuselageFuelTank
This would also restore the established terminology from earlier CPACS versions and make the distinction clearer again:
fuselageFuelTank: tank integrated into fuselage structurefuelTank: independent vessel-based tank placed via parentUID
3. Refine the content definition of vessel-based tanks
We also propose several refinements to the internal tank definition.
3.1 Rename hulls to vessels
We propose renaming hulls/hull to vessels/vessel. Easier to pronounce... ;-)
3.2 Move the geometry choice to vessel level
In the current concept, the distinction between a simplified parameterization and a fuselage-like definition is too coarse.
We propose moving this distinction to vessel level:
- each
fuelTank can contain multiple vessels
- each
vessel can individually be defined either by
sections / segments (fuselage-like definition), or- simplified design parameters
This allows a single tank with multiple vessels where each vessel can use the most suitable representation.
The simplified vessel representation remains as introduced in v3.5:
cylinderRadiuscylinderLengthdomeType
3.3 Remove the need for a dedicated spherical dome type
A spherical dome can be represented by ellipsoid, so a dedicated spherical option is not required.
We therefore suggest using ellipsoid consistently instead of keeping a separate spherical specialization.
3.4 Allow structure also for simplified parametric vessels
The proposed change allows to use structure for each vessel, independent from its geometric definition (simplified design parameters or sections & segments). Here a subset of structural elements from fuselage/structure (each having the same sub-elements) is available:
stringersframesskinLayerswalls
This is important because even simplified tank geometry may require structural and internal details.
3.5 Use walls for flexible baffle definition
We propose using walls for the internal definition of baffles.
This is attractive because it reuses an already established CPACS concept and enables flexible internal structures:
- freely positioned in space
- rotatable
- composed of multiple segments
- not restricted to a simple plane at fixed stations
Example XML: simpletest-fuelTanks.cpacs.xml
Why these changes are useful
In summary, the proposed refinements provide the following advantages:
- vessel-based tanks are no longer tied to fuselages only
- placement in wings, nacelles, etc. becomes possible in a clean CPACS-consistent way
- the distinction between integrated fuselage tanks and independent vessel-based tanks becomes clearer
- the naming is simplified and partly restored to the established terminology of earlier CPACS versions
- multi-vessel tanks become more flexible because each vessel can choose its own geometric representation
- existing CPACS concepts such as
parentUID, sections / segments, and walls are reused consistently
Open points
There are some related point which should probably remain outside the scope of this issue:
- varying skin thicknesses on vessel level -> relevant, but would also affect the corresponding modelling approach for
fuselage and therefore seems better suited for a separate discussion
- definition of fuel tank mounts (the applicability of
structuralMounts needs to be evaluated with regard to dynamic and thermal behavior)
- weight & balance and mass breakdown -> this also seems better suited for a separate discussion
- cutouts: this is in general an open ToDo for CPACS and TiGL, which will not affect this issues
Implementation status and next steps
As discussed above, the proposed tank functionality has already been implemented and tested in TiGL:
The TiGL implementation already provides:
- geometry support for the CPACS tank concept
- an example CPACS file:
- C++ unit tests:
- Python unit tests:
The example and tests already give a good impression of the intended CPACS structure and of the robustness of the schema adjustments.
We therefore suggest targeting CPACS v3.5.1 for these adjustments (consistent to #858). This would make it clear that these changes refine the tanks definition introduced in CPACS v3.5, while also aligning with the corresponding functionality planned for the next TiGL v3.5 release.
tagging @sfreund-DLR @Aerolufti @joergbrech @TimBurschyk @sdeinert @rmaierl @DLR-BT
We suggest making a few refinements to the tanks definition introduced in CPACS v3.5.
The main motivation is that the new tank concept introduced with CPACS v3.5 has already proven useful in first practical implementations, but the current placement below
fuselagesis too restrictive for broader application. In particular, these tanks should be placeable not only in fuselages, but also in other geometric components such as wings, nacelles, or other geometry components.Background
The original tank concept was introduced in the context of cryogenic fuel storage in CPACS v3.5. The main idea was to provide a more independent tank geometry than the classical
wingFuelTank/fuselageFuelTankdefinitions based on borders such as ribs or spars.Relevant background:
The current proposal reflects the experience gathered from first implementations and usage:
develop: cpacs_schema.xsdIn parallel, TiGL support for the new tank definition was requested here:
The corresponding TiGL implementation has meanwhile been completed and tested:
Proposed changes
1. Move vessel-based tanks to aircraft/model level
We propose moving the vessel-based tanks from the fuselage subtree to aircraft model level:
genericFuelTanks/genericFuelTankout of.../fuselages/fuselagevehicles/aircraft/model/fuelTanksThe parent-child relation should no longer be expressed by XML nesting below
fuselage, but via aparentUIDreference onfuelTank.This makes the placement concept consistent with other CPACS geometry elements and allows tanks to reference different geometric parents, e.g.
fuselagewingnacelleThis is the key functional motivation for the refinement.
2. Revert the v3.5 renaming of fuselage-integrated tanks
In CPACS v3.5, the former
fuselageFuelTankswere renamed tointegratedFuelTanksin order to distinguish them from the newly introduced vessel-based tanks.With the proposed relocation of the vessel-based tanks to model level, this ambiguity disappears. Therefore, we propose restoring the former naming:
integratedFuelTanks->fuselageFuelTanksintegratedFuelTank->fuselageFuelTankThis would also restore the established terminology from earlier CPACS versions and make the distinction clearer again:
fuselageFuelTank: tank integrated into fuselage structurefuelTank: independent vessel-based tank placed viaparentUID3. Refine the content definition of vessel-based tanks
We also propose several refinements to the internal tank definition.
3.1 Rename
hullstovesselsWe propose renaming
hulls/hulltovessels/vessel. Easier to pronounce... ;-)3.2 Move the geometry choice to vessel level
In the current concept, the distinction between a simplified parameterization and a fuselage-like definition is too coarse.
We propose moving this distinction to
vessellevel:fuelTankcan contain multiplevesselsvesselcan individually be defined either bysections/segments(fuselage-like definition), orThis allows a single tank with multiple vessels where each vessel can use the most suitable representation.
The simplified vessel representation remains as introduced in v3.5:
cylinderRadiuscylinderLengthdomeType3.3 Remove the need for a dedicated
sphericaldome typeA spherical dome can be represented by
ellipsoid, so a dedicatedsphericaloption is not required.We therefore suggest using
ellipsoidconsistently instead of keeping a separatesphericalspecialization.3.4 Allow
structurealso for simplified parametric vesselsThe proposed change allows to use
structurefor each vessel, independent from its geometric definition (simplified design parameters or sections & segments). Here a subset of structural elements fromfuselage/structure(each having the same sub-elements) is available:stringersframesskinLayerswallsThis is important because even simplified tank geometry may require structural and internal details.
3.5 Use
wallsfor flexible baffle definitionWe propose using
wallsfor the internal definition of baffles.This is attractive because it reuses an already established CPACS concept and enables flexible internal structures:
Example XML: simpletest-fuelTanks.cpacs.xml
Why these changes are useful
In summary, the proposed refinements provide the following advantages:
parentUID,sections/segments, andwallsare reused consistentlyOpen points
There are some related point which should probably remain outside the scope of this issue:
fuselageand therefore seems better suited for a separate discussionstructuralMountsneeds to be evaluated with regard to dynamic and thermal behavior)Implementation status and next steps
As discussed above, the proposed tank functionality has already been implemented and tested in TiGL:
The TiGL implementation already provides:
The example and tests already give a good impression of the intended CPACS structure and of the robustness of the schema adjustments.
We therefore suggest targeting CPACS v3.5.1 for these adjustments (consistent to #858). This would make it clear that these changes refine the tanks definition introduced in CPACS v3.5, while also aligning with the corresponding functionality planned for the next TiGL v3.5 release.
tagging @sfreund-DLR @Aerolufti @joergbrech @TimBurschyk @sdeinert @rmaierl @DLR-BT