    

 ## On this page

  

 

 # Version 2026 R1

 Last update: 09.03.2026 

**Version 2026 R1 (V261)** introduces new capabilities for parameterization in stage definitions, expanded controls for tree visibility and highlighting, and significant refinements to contact and interface property definitions. This release also includes supporting APIs for new physics models introduced in the V261 product, as well as renaming and refactoring to improve consistency across the API surface.

## Stage Definition

**Add-in Parameterization Support**Stage definitions now support parameterization through new optional API delegates. Add-ins that do not implement parameterization may set these values to null.

New delegates include:

- **Func&lt;CancellationToken, Task&gt; UpdateVariationTableSolve**
- **Func CanSolveVariationTable**
- **Func IsSolveInProgress**
- **Func&lt;ICustomObject, string, DimensionalQuantity&gt; GetQuantity**
- **bool TrySetQuantity(ICustomObject customObject, string persistentId, DimensionalQuantity dimensionalQuantity)**

These additions allow parameterized automation workflows and tighter integration with variation table solving.

## Custom Tree

**Controls for Tree Highlighting**Custom objects defined by add-ins can now reference associated geometry to enable correct highlighting behavior in the tree and viewport.

**SpaceClaim.Api.V261.CustomWrapper**

- `ICollection<IDocObject>` AssociatedLocations Defines geometric objects (faces, bodies, etc.) associated with a custom object. Selecting the custom object displays its associated geometry, and selecting the geometry highlights the corresponding custom entry.

**Ansys.Discovery.Api.V261.Customization.Wrapping.DiscoveryCustomWrapper**

- `List<IDocObject>` AssociatedBodies Defines the bodies associated with the custom object that should highlight inside the design tree.

These enhancements improve usability and visual consistency when working with custom tree elements.

## Contacts and Interfaces

Significant refactoring has been made to improve clarity and expand supported modeling options.

### Renamed Properties

- **SpecifyThermalConductance** → **ThermalConductanceSpecified**
- **SpecifyElectricConductanceFromThicknessAndMaterial** → **ThermalConductanceSpecifiedFromThicknessAndMaterial**
- **DetectSharpAngles (DetectTool class)** → **DetectSliverFaces**

### New Properties Added

- **ThermalConductanceSpecifiedAsPerfectInsulator**
- **ThermalConductanceSpecifiedFromValue**
- **ThermalConductanceSpecifiedFromThicknessAndConductivity**
- **ThermalConductanceOptionType**
- **ThermalConductanceConductivity**

These changes enable improved modeling of thermal behavior, including new options based on thickness and conductivity.

### Electrical Conductance Updates

- **Contact.SpecifyElectricConductance** → **ElectricalConductanceOptionType**
- **ContactGroup.SpecifyElectricConductance** → **ElectricConductanceSpecified**

Refactoring supports new electrical conductance models and resolves inconsistencies across contact classes.

## Detect Tool

The DetectTool and DetectToolType enums have been updated:

- **DetectSharpAngles** → **DetectSliverFaces**

This renaming better reflects the tool’s purpose and aligns API terminology with the UI.

## Internal Fans

Internal fan behavior was updated to support new validation and library handling:

- Adjustments to fan library modification rules
- Minor corrections to ensure consistent behavior across projects and local libraries

## Discovery Changes (Internal)

Internal development notes:

- Added support for expanded thermal conductance options, including thickness + conductivity models
- Updated **ContactGroup** and **Contact** classes to use new option types and naming conventions
- Improved validation and correction logic for fan library entries
- Updated **DetectToolType** enum and associated UI terminology

## API Changes and Incompatibilities

**Breaking Changes**

- Renaming thermal and electrical conductance properties
- Renaming **DetectSharpAngles** to **DetectSliverFaces**
- Refactoring of conductance option types may require migration updates in add-ins
- Changes to contact and interface classes may break code relying on deprecated properties

These changes increase modeling consistency and improve alignment between the API, UI, and solver capabilities.