Definition of cryogenic fuel storage

[TimBurschyk]

Current research activities consider liquid hydrogen as a possible aviation fuel. The way to store this cryogenic liquid differs quite a bit from storing kerosine. The definition for wingFuelTank or fuselageFuelTank uses border elements (e.g. ribs or spars...), which works fine for fuel tanks using mainly the aircraft structure as enclosure. However, the definition of cryogenic fuel storage needs a more independent approach.

Therefore, the following proposal describes the storage tank geometry as hulls. The hull inherits many features from the fuselageType, like the definition of segments and sections. Also the structure could be used. Defining the ...structure/skin different layers (with material and thickness) could be given in the right orientation from outer surface towards the center. If the layers always have the same thickness standardStorageLayers could be used. If some segments (e.g. domes) have different thicknesses nonStandardStorageLayers can be defined for the corresponding segmentUIDs.

As an example, a double walled vacuum storage tank with multi layer insulation would consist of two hulls. The first hull being the outer vessel may consist of aluminum with additional structural elements. The second hull defines the inner vessel, which may be composed of aluminum and MLI sheets. The vacuum in between the hulls is not explicitly given.

The xml structure of a cryogenic storage tank could look like this:

<aircraft>
  <model>
    <cryogenicFuelStorages>
      <cryogenicFuelStorage uID="..">
        <name></name>
        <description></description>
        <parentUID></parentUID>
        <transformations></transformations>
        <hulls>
          <hull uID=".."> <!-- always outer surface -->
                        <!-- similar to: current approach for fuselage -->
            <name></name>
            <description></description>
            <transformations></transformations>
            <sections></sections>
            <segments></segments>
            <structure>
              <stringers></stringers>
              <frames></frames>
              <skin>
                <standardStorageLayers>
                  <standardStorageLayer>
                    <!-- alternative: use of standardSheetElements -->
                    <materialUID></materialUID>
                    <thickness></thickness>
                  </standardStorageLayer>
                  <standardStorageLayer>
                    <materialUID></materialUID>
                    <thickness></thickness>
                  </standardStorageLayer>
                </standardStorageLayers>
                <nonStandardStorageLayers>
                  <segmentUIDs>
                    <uID></uID>
                    <uID></uID>
                  </segmentUIDs>
                  <nonStandardStorageLayer>
                    <materialUID></materialUID>
                    <thickness></thickness>
                  </nonStandardStorageLayer>
                  <nonStandardStorageLayer/>
                </nonStandardStorageLayers>
              </skin>
            </structure>
          </hull>
        </hulls>
      </cryogenicFuelStorage>
    </cryogenicFuelStorages>
    <analyses>
      <massBreakdown>
        <mOEM>
          <mEM>
            <mPowerUnits>
              <mFuelSystem>
                <massDescription/>
              </mFuelSystem>
            </mPowerUnits>
          </mEM>
        </mOEM>
      </massBreakdown>
    </analyses>
  </model>
</aircraft>

Possible points for discussion are:

• Using the fuselage like definition or an alternative parametric approach, giving parameters like cylindricalLength, outerRadius, etc...
• If staying with fuselage like definition: defining the inner or the outer surface of a hull?
• How to deal with additional fuel system elements, not only the storage structure
• Naming of the nodes: Is there a better name for cryogenicFuelStorage or hull
• Location within CPACS: ...aircraft/model/cryogenicFuelStorage
• Mass description of mFuelSystem could be split into fuel storage 1/ distribution 1...

I looking forward to discuss this topic with the community. Any suggestions or comments are welcome!

[jnwalther]

Very nice proposal @TimBurschyk! I agree that recycling the fuselage modeling approach is the way to go here to ascertain the conceptual consistency throughout CPACS. My personal feeling is, that the hull definition should describe the innersurface, since the primary task of the storage is to hold a certain volume of fuel, not to fit in the aircraft. Therefore, I think it should be easier to compute the fuel volume, than to integrate the tank with the structure, if that makes any sense, which is the case if we provide the inner hull (even though that will make my life more painful...).

As for the other points you mention, I don't have any strong opinions either way, but here are a few unreladted comments:

• The placement in model is fine by me, as long as we agree, that the tanks will be custom-designed for the aircraft. However, if we think of the storage as a stock part, which is bought from a supplier, we should consider introducing a library node, similar to cabin components.
• A few key features of the fuselage description are omitted from your fuselage description (I'm assuming for the sake of brevity), but I think should be highlighted, because they could be very useful for the tank, namely guide curves and symmetry. Symmetry could be useful for wing-mounted tanks (but I guess that maybe already works if the parentUID refes to a symmetric wing). Guide curves could be extremely useful to define smooth tank geometries efficiently, and while they are not common practice for fuselages yet, I think we should make sure that they are for storage tanks!
• I dont fully understand the idea behind having both multiple hulls and storage layers. I'm assuming the hulls are meant to described one hull inside the other, whereas the storage layers are a sequence of offsets. But what are the different use cases? Could you maybe provide an example? Nevermind. I guess the use case is when you have a vacuum in between hulls...
• For your standardStorageLayer, you have created a duplicate of the sheetBasedStructuralElementType so I propose you use that instead.
• In the nonStandardStorageLayer, how exactly would you describe the boundaries of different segment areas? In the fuselage we use skinSegments, which are bounded via frames and stringers. It's also possible to create "virtual" frames and stringers with a zero cross section, so maybe you could simply use that. That said, the frame/stringer definitions have some limitations (s. #480), where I can't tell if they could be a problem here.

That's all I have for now. Once again, great initiative, and, comments aside, I think you're already really close to a final definition.

[MarAlder]

Great proposal! I agree with @jnwalther comments and have some additional thoughts:

• We could rename standardStorageLayers/nonStandardStorageLayers to standardSkinLayers and nonStandardSkinLayers so it better fits into the node hierarchy.
• For nonStandardSkinLayers the idea was to simply reference segments because a technical drawing has indicated that the thickness is constant in the radial direction. But if, for example, the bottom of the tank is thicker than the top (e.g., because more insulating foam is used here) virtual stringers/frames might actually help. I like the simplicity of the segment solution and the flexibility of the latter solution 🤔
• I think we should assign the cryogenicFuelStoragesType directly to a child element of fuselage or wing. In this way we avoid that the tanks could be asssigned to landing gear or engines and we furthermore avoid a large collection of geometric elements under aircraft/model.
• Do we restrict ourselves to cryogenic fuels? How about only fuelStorages?
• We are now only looking at the geometry and material. Is there something more we should consider?

I offer to prepare the corresponding scheme soon. Thanks to the good preparation, it will go quickly.

[sdeinert]

Regarding the proposals using skinSegments or directly assigning the values to sections, it might be beneficial for several applications to extend the skinSegment logic so that you can either reference a frame or a section by uID. This way both cases discussed above could be handled without the need to create dummy frames as boundaries. For fuselage structure definitions, this extension would also be helpful for some special cases.

With respect to the standardStorageLayers, I am not sure if I understood correctly. The elements used in this node are simply the same as in a composite definition where different layers with thickness and material uID can be defined. Would it be realistic to re-use the composite element here?

[TimBurschyk]

Thank you for your detailed feedback and the good suggestions!

In regard to your comments - some additional thoughts from my side:

• The idea to use "virtual" frames and stringers could work out. Indeed, it's a very flexible way of storing the information and will probably serve also future designs. I can't foresee if the mentioned limitations (s. https://github.com/DLR-SL/CPACS/issues/480) cause a problem here. If the skinSegments logic is extended the definition would be simplified (at least in my eyes)
• The additional features from the fuselage definition (guide curves and symmetry) are useful. Inheriting these features aligns well with the proposal.
• I don't have a strong feeling of where to assign the cryogenicFuelStorageType - so I'm fine if it's a child element of fuselage or wing. In a way, it is a fuselage in a fuselage.
• Referring the geometry to the inner surface is also fine for me - are there any more comments on that?
• About the names: fuelStorage vs cryogenicFuelStorage - the current name fuelTank for kerosene fuel tanks could cause confusion. Where is the difference between fuelTank and fuelStorage?

[jnwalther]

Expanding the skinSegment definition could be a good idea. That said, the added value might be less than one might initially think, since the sections are usually x-positions anyway, so the extra step of adding a virtual frame actually takes very little extra effort. On the other hand, the hard part is the stringers, but here the sections won't help. For the purpose of this issue, we can probably simply agree to use skinSegments analogously to the fuselage and open a separate issue to figure out the details. @sdeinert, maybe you can provide a proposal on how to update the schema accordingly.

Concerning @MarAlder's comment, I agree it's probably nicer to have the tanks at fuselage/wing level. In the case of the fuselage, this would, however, leave us with two entries fuelTank and cryogenicFuelStorage at the same level. Here it would be really important that the naming of the nodes brings out the distinction.

[MarAlder]

True, we already have a fuelTank under fuselage 🤔 .. The name should indeed be distinctive. Maybe integralFuelTank or we leave it like the proposed cryogenicFuelStorage, that's fine for me. My concern was just the limitation to cryogenic.

[sfreund-DLR]

thanks @TimBurschyk for the proposal!

1. There is not really a "standard" to storage layers. Maybe standardStorageLayers should be simpleStorageLayers?
2. Layers and orientations: As @jnwalther says, the layers should ordered from inside to outside and the geometry is defined on the inside geometric shape. Additionally I think, composite layers should also be stacked from inside to outside. This is the opposite of the skin definition in the fuselage skins (if I recall correctly). What do you think about this?
3. cryogenicFuelStorage: what about pressurizedFuelStorage? This would at least include high pressure gas tanks, that also requrie a dedicated storage area and is not enclosed by the aircraft's structure.
4. For now, there is nothing regarding the load acting on the fuel storage. Adding internal pressure, temperature, safety factor, storage-uID etc. to the loadCase-definition might be a simple approach. Altough, this does not tell anything about the load during a mission.
5. Simplicity: I think, the geometric description is well suited matured tools in aircraft pre-design. It has a lot parameters when recalling all the geometric references to segments, sections, positionings, guideCurves and crossSections. All this is required to model something simple such as a cylindrical tank with ellipsoid domes. This structure is not suited for an easy and quick start with pressurized fuelStorages in CPACS. For a first quick and simple estimation, only few geometric quantities and a pressure level is requried. The output may also be very simple: skin+insulation thickness and total mass. What if we add a choice for a simple parameterization besides the hulls? Parameters could be: cylindrical radius, cylindrical length, domeType and additional parameters regarding the domeType
6. From a structures perspective, it's not advisable to have frames/stringers with zero properties that should never be zero (such as crosssectional area, thicknesses). I would encourage to either name them virtualFrame/virtualStringer or use other items to reference geometric boundaries such as a combination of stringerFramePositionType.

[marcengelmann]

We at Bauhaus Luftfahrt are using CPACS as the data model for our BLADE aircraft design environment. At the moment, we are enhancing the tool for hydrogen aircraft. For this, we also need liquid hydrogen tanks in CPACS. Currently, we are "misusing" the fuselage definitions with special uIDs for our tank descriptions but we would be more than happy to also be able to use a proper hydrogen tank definition.

We are happy to contribute to this definition and are also willing to share some information or participate in a workshop in this topic if there is interest from your side.

Maybe we can discuss this at the quarterly meeting tomorrow.

In general we also think that it makes sense to stick to the fuselage definition concept for this.

[MarAlder]

Thank you all for the detailed feedback! I uploaded a schema extension via a3a6b6c69b8ffc5925ae030be3619a8641027090 according to your comments. Next step should be that we find an hour to meet and discuss/agree on the open discussion points. I'll soon contact you on this.

Schema download

Location

Just a suggestion to evaluate all possibilities: *ok, cryogenic is also liquid... or 'conventional' or something else...

cryogenicFuelTankTsype

I tried to recycle as many elements from the fuselage as possible. @TimBurschyk, please see if a slightly different arrangement of the skinLayers, analogous to the individual skins of the fuselage, could be feasible.

• [ ] Decision on the location of the tanks in the CPACS hierarchy
• [ ] Decision(s) on the naming of the elements
• [ ] Specify correct element occurences
• [ ] Virtual stringers & frames vs extended segmentType (or both?)
• [ ] Add further fuselage features (e.g., guide curves)

[MarAlder]

A little update from my side (the above discussion still applies):

Renaming of fuel tanks

I propose to combine any fuel tanks in the fuselage/fuelTanks node. This requires transferring the current definition (which are essentially integral tanks) to a dedicated container node. Thus, integralFuelTanks.

Choice between simple and detailed design (example)

We can introduce a choice to the detailed description via hulls. The transformation from simple to detailed parametrization may be problematic in practice, but if the simplified definition is worthwhile at this point, I am open to it.

• [ ] @sfreund-DLR: Could you please propose the correct parameters for the globalDesignParameters node, if this is wanted?

[MarAlder]

Today we had a meeting with the main stakeholders and agreed on the following:

Using pre-defined tanks

Tanks will not be pre-defined and referenced, but the type will be used directly in the corresponding fuselage element. Furthermore, adding a element of the same type in the wing can be a possible enhancement in the future.

Naming of the parent elements

Not yet ideal, but we didn't came up with a better solution so far: All tanks should be combined under the main node fuelTanks. The current tank definition will be renamed to integralFuelTank and the new definition will be listed under genericFuelTank until someone has a better suggestion.

Choice between simple and detailed parametrization:

We agreed to introduce a choice between simple and detailed parametrization. @sfreund-DLR will work out the parametrization for the first.

Layers from inner to outer

We agreed to always use the definition that the layers count from the inner to outer direction. The documentation needs to be extended so that the direction of the normal vector is clear.

Virtual stringers and frames

We'll introduce virutal stringers and frames to support explicit helper-geometry for the definition of skin segments. So far we are using the exact same type. If we adopt this enhancement for the fuselage itself, we could think about making a baseType without structuralElementUID since this is not required for virtual stringers/frames and extend the actual stringer/frame types with structuralElementUID.

Definition of the skin

We agreed to use the same type as used for fuselage/strcuture/skin, i.e. skinType. This type has some limitations (see discussion above), which will be discussed in a separate issue. Thus, we remain consistent with the fuselage.

ToDo

• [ ] Any idea for a better name than genericFuelTanks?
• [ ] Document direction of wall normal vector
• [ ] Add parametrization for designParameters (@sfreund-DLR)
• [ ] Mass breakdown: add entry for genericFuelTanks

[sfreund-DLR]

Choice between simple and detailed parametrization:

We agreed to introduce a choice between simple and detailed parametrization. @sfreund-DLR will work out the parametrization for the first.

• transformation
• cylinderRadius: inner cylindrical radius
• cylinderLength: inner cylindrical length
• domeType (choice: spherical, ellipsoid, torispherical, isotensoid)
  • case ellipsoid:
  • halfAxisFraction
  • case torispherical see this drawing:
  • r1: dish radius
  • r2: knuckle radius
  • case isotensoid:
  • polar opening radius (radius of the fitting/smalles polar opening)
• burstPressure
• materialUID (materialDefinitionType)

Questions to all

• [ ] should burst pressure be included or should the upcoming system state definition be used for this?
• [ ] should an elliptical shape be an explicit option? It could also be modelled by the scaling of spherical domes of the transformation node
• [ ] for the dimensions, I perfer the inner dimensions from a H2 volume requirement perspective. With this the design space is an output of the structural and thermal sizing. Is this OK?

[MarAlder]

Thanks @sfreund-DLR. I added a emptyElementBaseType because spherical has no child elements. We never did this in CPACS before, but ... why not.

If the burstPressure is a property of the tank itself and not a changeable system state, we could include it in the current definition. If it depends on some system settings or flight conditions, then it should be part of the new configurationDefinition node.

<fuelTanks>
    <genericFuelTanks>
        <genericFuelTank uID="simpleTank">
            <name>Cryogenic fuel tank</name>
            <designPrameters>
                <transformation>
                    <translation>
                        <x>10.</x>
                        <y>2.</y>
                        <z>0.</z>
                    </translation>
                </transformation>
                <cylinderRadius>1.</cylinderRadius>
                <cylinderLength>5.</cylinderLength>
                <domeType>
                    <spherical/>
                </domeType>
            </designPrameters>
        </genericFuelTank>
    </genericFuelTanks>
</fuelTanks>

[sfreund-DLR]

Thanks @MarAlder

From a structures perspective, materialUID should be mandatory.

The burstPressure is a key parameter for both, the simple and the detailed version. Though, I don't have a good suggestion for it's location

[MarAlder]

Ok, so lets put burstPressure one level above:

Btw., the integralFuelTanks have a volume node. We could also implement this if needed.

[TimBurschyk]

Thanks @sfreund-DLR and @MarAlder for your last comments. Almost at the finish line, I got two more thoughts:

• Implementing the volume node similar to the integralFuelTank is a good idea.
• Regarding the mass accounting: I think mGenericFuelTank should be part of mPowerUnits (just like mFuelSystem) and how do we deal with more than one entities? What do you think?

[MarAlder]

Not sure, as the genericFuelTanks are explicitly a child of the fuselage and are mainly described by the structure of the hull(s), I would find it more intuitive to keep them in mFuselageStructure:

The powerUnits are, in my understanding, more like systems of distributed components. But I'm open to both places.

[TimBurschyk]

Setting the boundaries for the mass breakdown is a difficult thing. In my opinion the fuel tanks are part of ATA 28: Fuel system (incl. storage, distribution, ...). BUT: the cpacs mass breakdown is not alligned with the ATA chapters, anyway. Additionally, mFuelSystem has only a single occurence, if I'm right. So all in all:

-> keeping mGenericFuelTanks in mFuselageStructure is fine for me