Combining B-Rep and Implicit Modeling for Heat Exchanger Geometry
Interview with Tomoo YAMAJI
Tomoo Yamaji, founder of YAMAJI DESIGN, answered six questions ahead of his presentation at CDFAM Tokyo on the geometry design stage of an aerospace heat exchanger project.
The case study covers a diaphragm geometry that neither conventional CAD nor a single computational design tool could handle on its own, and the Grasshopper to nTop workflow built to generate, thicken and array a large family of variants. He also discusses where the handoff between B-Rep and implicit modeling still requires manual work, and where DfAM and computational design adoption stands in Japanese industry and academia.
Can you introduce YAMAJI DESIGN, the type of work it takes on, and give an outline of what will be covered in the heat exchanger case study at CDFAM?
- Developing programs for automated design
- Mechanism design for proof-of-concept mockups and prototypes
- Industry trend research and ideation of new products
- Training (computational design software and DfAM)
Although I describe myself as a “consultant for AM”, in practice I also provide services related to conventional manufacturing methods, my main clients are:
- Japan: aerospace company
- United States: consumer electronics manufacturer
Workflow: Within the full workflow (performance design > geometry design > CFD analysis > 3D printing > physical testing > correlation), this presentation focuses on the geometry design step.
Target region: The geometry of the diaphragm that forms the fluid channel core of the heat exchanger.
Challenge and solution: Many conventional 3D CAD systems are inherently ill-suited to generating a large number of geometric variations and to handling issues such as self-intersection and singularity. Computational design tools such as Grasshopper (B-Rep) and nTop (implicit) also struggle when used on their own. The presentation explains how combining the two tools allowed us to overcome these challenges.
What was it about the design space of the diaphragm geometries in this project that pushed the workflow beyond what a conventional CAD package could handle, and at what point did that become clear?
The project required generating a large number of geometric variations by taking one base diaphragm geometry and varying multiple parameters that define it.
1. Generating a large number of variations
The base diaphragm geometry was the type that requires significant effort to model even a single variation in conventional 3D CAD. For example, if the geometry is defined by three parameters and each parameter is varied across ten values, the total number of variants is 10 × 10 × 10 = 1,000.
Modeling these one by one in conventional 3D CAD would require an enormous amount of labor. To move the project forward within a short timeframe, computational design (3D modeling by programming) was the efficient approach.
2. Self-intersection and singularity
The base diaphragm geometry was not a simple planar shape but an organic one. Even if the zero-thickness surface could be modeled in conventional 3D CAD, adding thickness often caused self-intersection or singularity. Passing such data to downstream processes risks failures in slicing or 3D printing. Because most conventional 3D CAD systems use B-Rep as their geometric representation, it is inherently impossible to avoid these issues completely. This was another reason conventional 3D CAD was inefficient for this project.
When did this become clear?
In the very first meeting with the client, when I heard the project requirements, it was clear that completing the project using only conventional 3D CAD would be extremely difficult. At that time the client was not familiar with the concept of computational design and intended to proceed with conventional 3D CAD alone.
Grasshopper and nTop take very different approaches to programming and to representing geometry. How was the handoff between the two structured, what actually moves between them in the data flow, and where did that boundary cause friction?
1. Integration between Grasshopper and nTop
Grasshopper and nTop differ greatly in their characteristics, strengths, and weaknesses. The diaphragm geometry in this project was difficult to model in nTop alone. In the first half of the workflow, Grasshopper was used to generate zero-thickness B-Rep surfaces, which were exported as STEP files. In the second half, the STEP files were imported into nTop, where implicit modeling was used to add thickness, create arrays, and build the complete fluid channel core.
What data moves through the workflow?
Due to NDA restrictions I cannot disclose full details, but based on the example geometry shown in the presentation, the data included:
- Base diaphragm geometry (zero-thickness B-Rep surface, .step)
- Array information for the fluid channel core (.csv)
- Diaphragm thickness
In this workflow, some manual file handling was required when transferring data between Grasshopper and nTop. This created a significant discontinuity in the overall workflow. Manual operations introduce the possibility of human error, which is a form of friction. Increasing the degree of automation in the data transfer between the two tools would reduce this friction and lower the probability of error.
Once the workflow was in place, how were the generated variants evaluated and filtered, and how much of that assessment could be automated versus needing an engineer to look at the result?
Performance design > geometry design > CFD analysis > 3D printing > physical testing > correlation
Of these steps, I automated only geometry design. The other stages were mostly not automated on the client side. All variations generated by the workflow were therefore analyzed and filtered manually by the CFD engineering team. From those results, variations with a good balance across the evaluation factors below were selected for metal 3D printing, physical testing, and correlation with the CFD results.
Heat exchangers for aerospace must satisfy the following four factors in balance:
- Heat transfer performance
- Pressure drop
- Structural strength
- Weight
With more than fifteen years across service bureau and aerospace environments, how has the adoption of DfAM and computational design tools in Japanese industry shifted, and where does it still lag?
On-site adoption of AM is not as advanced as in Europe or the US, so DfAM concepts have not been widely adopted. Computational design is a different story: Grasshopper has been actively used in Japanese architecture for nearly twenty years.
In both DfAM and computational design, Japan lags significantly behind other countries. In the aerospace industry where I previously worked, understanding of the hardware (AM machines) has progressed, but the design methodologies needed to take advantage of that hardware have not. As a result, adoption of computational design software is limited, with a strong bias toward hardware over software. Academia shows similar tendencies.
I have recently been lecturing on computational design at a Japanese national university. Both industry and academia need to build their knowledge in a balanced way across hardware and software.
What is the main point to be taken from this presentation, and what would be worth hearing from the other speakers and attendees at CDFAM Tokyo?
- Computational design tools each have distinct characteristics.
- Grasshopper and nTop, for example, have highly contrasting characteristics.
- Depending on the project, a single tool may be insufficient.
- By combining multiple tools, it is possible to compensate for each tool’s weaknesses and build the entire workflow efficiently.
- Implicit interoperation: computational designers need to pay attention to data transfer between each process, both before and after 3D modeling.
CDFAM brings together speakers from three groups: software developers, users, and academia. I find particular value in presentations from users, showing how they solved the challenges in their own projects.
Through these I want to learn more about the characteristics of different tools. Given the rapid progress of AI, I am also interested in hearing about its potential in computational design.
Tomoo Yamaji will expand on this case study at CDFAM Tokyo, October 8 – 9, 2026, alongside others working on computational design for manufacturing. Join us to meet them. Registration is open at cdfam.com/tokyo-2026.
