General Geometry Description in CPACS for everyone

[Aerolufti]

Hello everyone,

Idea (short version)

• Introduce an optional detailed geometry layer in CPACS
• Store general geometry descriptions close to CAD level
• Provide a tool for reading/writing/editing geometry data

Idea (long version)

Motivation

Many of us build geometry models from CPACS for FEM, CFD, visualization, etc. Currently, CPACS is limited to very specific parameters (e.g., fuselage structure defined by frames, stringers, pressurebulkheads,... or wing structure defined by specific ribs, spars, flaps,...). For new concepts the modeling is limited to the current components and parameter ranges. Modifying the CPACS schema and tool (model generator) is required for new designs, which is time-consuming or even impossible.

At DLR-BT, we increasingly need detailed fuselage structures (e.g., for LH2 tank integration or crash analysis). While CPACS is intended for preliminary aircraft design, tools are becoming more detailed, increasing the need to exchange richer geometry data. A general geometry layer in CPACS could:

• Access CPACS data directly (sections, structural profiles, materials,...)
• Allow simple geometry editing without scripting complex CAD operations (like OpenCascade)
• Support a combination of automated and manual adjustments, saving significant time

Current vs. Proposed workflow (DLR-BT tools)

Current:

1. CPACS input with outer aircraft shape
2. Fill CPACS with structure definitions (frames, stringers, …) via tool-specific parameters
3. FEM generator reads specific parameters to build model

Proposed:

1. CPACS input with outer aircraft shape
2. Fill CPACS with structure definitions (frames, stringers, …) via tool-specific parameters
3. (Optional) convert to general geometry description in CPACS
4. Users or scripts can view/edit general geometry in CPACS (add details, tweak structures)
5. FEM generator reads general geometry from CPACS to create model

Why it matters to use general geometry in CPACS?

• Reduces dependency on “blackbox” tools
• Allows flexible, semi-automated workflows (basic structure generated automated, to complex details manually)
  e.g. define basic aircraft structure automated and add details for landing gear attachment or details for wing folding mechanism
• Supports interdisciplinary integration

Suggestion to discuss

• Introduce a general geometry layer in CPACS accessible to all users
• Combine multiple needs of existing tools for geometry (and meshing) into a unified framework (TIGL, grunk, FUGA, PANDORA,…)

Example how the format could look like:

example_cpacs_geom_api.xml

Example how it is currently used by DLR-BT:

Best regards, Michael
Merry Christmas and a Happy New Year to you all!

[joergbrech]

Hi Michael,

interesting thought.

For new concepts the modeling is limited to the current components and parameter ranges. Modifying the CPACS schema and tool (model generator) is required for new designs, which is time-consuming or even impossible.

The problems you are trying to solve are similar to some of the issues that we want to address with grunk, but grunk uses a slightly different approach. To be clear: I don't want to plead the case that grunk is the "better" solution, I just want to compare your approach to the grunk approach as a basis for discussion.

The idea of grunk is a generic parametric engine with a plugin system, as well as a file format that describes parametric recipes. One plugin would be TiGL, a geometry interpreter for CPACS files if you will. Another plugin could be a more CAD-like generic geometry generator like OpenCascade or geoml or any other suitable library.

Then, a CPACS file could be distributed together with a grunk recipe. The grunk recipe loads the CPACS file, extracts geometry information using the TiGL plugin as b-spline curves, surfaces or solids (using OpenCascade under the hood). It then uses a CAD-plugin for further geometry manipulation to extend the CPACS definition with custom solutions.

This way, a design team can use CPACS as a far as feasible and extend the standard with the custom solutions needed in the current analysis, design project. These geometry customization and extension can then potentially be used as a basis for CPACS or TiGL extensions in the future if it makes sense. But the extension also can be used without modifying the CPACS schema or waiting until a CPACS proposal is accepted, merged and implemented in TiGL.

General Geometry Description in CPACS	grunk
Everying in one document, everying is xml	An additional document for extensions, parametrization and geometry modeling that go beyond the current state of CPACS
Geometry description using an XML Schema	Geometry description using the API of a CAD plugin
Textual description, it's a "Standard"	Tool/implementation-centric
CPACS is extended with non-physical CAD-like geometry	CPACS remains as is, where almost all nodes have an interpretation as a physical system
Extensions restricted to Geometry/CAD (-> simpler)	Extensions are generic and can include Geometry/CAD, but also other domain specific plugins (-> higher complexity)

That being said, I believe there could be a middle ground as well. If we want an XML-Schema for general geometry description, we could define it next to the CPACS schema (which is less intrusive) and we could develop an interpreter, that we all use in our frameworks. A CPACS file and a geometry file conforming to the second schema could optionally be merged into a single document.

As a follow-up question: Where do you see the benefit of an XML-Schema for geometry over a (stable) API of a geometry modeling library? The schema would have to be implemented by a library anyway, which adds an additonal layer, translating the schema to the library API. Different interpreters can potentially lead to (slightly) different geometries due to different algorithmic implementations and tolerances in the different libraries.

[Aerolufti]

Hi Jan,

thanks a lot for your detailed and thoughtful response – I really appreciate the comparison. I fully agree that grunk addresses a very similar problem space and see it as a powerful and well-designed approach.

I don’t see this as “geometry in CPACS vs. grunk” or one approach replacing the other. I’m exploring the gap between CPACS as a physical system description and low-level CAD/kernel scripting. The idea is a simple, optional, high-level geometry description that captures geometry intent and can be executed by different backends.

The main goal is to reduce the required background knowledge and procedural complexity. Users or scripts should be able to express operations like “extrude this object along that path” without dealing with low-level OCC BRep details, input types, or operation order. A geometry API would translate this intent into the appropriate low-level operations.

Motivation:

• More robust parametrization (less dependency on procedural logic)
• Easier inspection and modification by non-CAD experts
• Clearer separation between geometry intent and execution

I agree that such a layer would still need interpretation and that different backends may produce slightly different results. But this is already the case today with different TiGL versions and different CPACS-based tools. Making it explicit at a higher level could improve transparency.

I like your “middle ground” idea. From my perspective, grunk could be an excellent execution environment for this high-level geometry intent layer, rather than an alternative.

My motivation here is mainly research-driven: to see if this gap can be closed in a way that complements tools like grunk, without bloating CPACS or forcing changes on existing workflows.

Answering your follow-up question: From my point of view the main benefit of an XML-based geometry description over a pure API is not execution, but where the geometric intent lives. A schema-based description is tool-agnostic, inspectable, diffable, and can be validated independently of a specific implementation. Geometry intent can be exchanged, reviewed, and versioned without requiring a specific runtime. The API becomes an execution mechanism, not the place where intent is encoded.

This approach is independent of a specific CAD kernel or backend—it could be implemented on OCC, CATIA, a FEM-internal CAD kernel, etc., and extended with mesh definitions or structural couplings. It also allows linking of CPACS-defined data, like aircraft shapes, sections, materials, and beam cross-sections, to a top-level geometry description. This enables consistent management of multiple model aspects (geometry, mesh, materials, structures) without embedding low-level procedural logic in CPACS.

But I’m also fine with storing general geometry descriptions in external files linked to CPACS, as long as CPACS-defined data can be linked. The key for me is having a simple, high-level geometry description.

Do you think grunk could be extended to read high-level recipes for geometry descriptions? Or do you see any showstopper or issues here I have not considered? Maybe we also need some more detailed examples to see which is the best way to go.

[MarAlder]

Sorry for the late reply, it is a complex topic.

I understand the need for a standardized description of the geometric interpretation of CPACS data. According to our current philosophy, we describe CPACS parameters as explicitly as possible and add the geometric processing knowledge to TiGL. I am open to discussing how to address the gap between CPACS parametrization and geometry handling. However, combining it with the current CPACS structure while maintaining the explicit character describing what things really are is certainly not trivial. Looking at your example, it begins with a fuelTank having vessels plus a list of geomParts. When receiving such a dataset, how would I know which geomPart belongs to which vessel? Further embedding it in the hierarchy or using uID references raises the question of how to combine it with the existing geometry parameterization while avoiding redundancy. One of the major benefits of CPACS is the interlinked parametrization. How can I ensure that the geomParts adapt to changes in the radius parameter of a vessel?

Having an intermediate level that references CPACS objects and standardizes instructions for geometric handling is a very interesting research approach. The development of grunk recipes is moving in this direction. Perhaps you could exchange examples to further discuss the concept? Maybe there are existing standardized ontologies that can already be used? I only found this link at a quick glance. I think the topic can become very complex quite quickly, don't you think?

We can also arrange a phone call to brainstorm a bit furhter, if you like.

[gPauls-TUHH]

Hey everyone, it looks like you have implemented fuelTanks into the model node (see fuelTanks), but in the latest CPACS file it does not show up.

Therefore, I get errors within my schema check when trying to implement such fuel tanks.

Will there be an update either fixing the schema file or the documentation?

[MarAlder]

Hi @gPauls-TUHH,

well spotted. Yes, we moved the fuelTanks from fuselage to aircraft/model/fuelTanks (you find the difference in the corresponding documentations for v3.5 vs develop). Together with some small updates on the systems we will soon invite to a CPACS meeting on this and bring a CPACS v3.5.1 update.

You can download the corresponding schema here or link in your CPACS file via:

<?xml version="1.0" encoding="UTF-8"?><cpacs xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
      xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/DLR-SL/CPACS/refs/heads/develop/schema/cpacs_schema.xsd">

The latest TiGL release-candidate 1 should already support the new fuelTanks location. A systems implementation is in the making and prototypically available on request.

[gPauls-TUHH]

Good to know - thx!