All machines

Thermal computation results can be very different between FluxMotor an Flux2D

Thermal computation with FluxMotor can be very different from the one exported to Flux2D with same settings.

Indeed, the second-order temperature interpolation does not manage very well high temperature variations on an element.

That's why, sometime, in Flux2D, the result got for a single thermal node of the mesh can "hide" the real temperature distribution when the temperature map is displayed by default.

As a workaround, we can change manually the temperature scale, to make the results become closer to what is expected (ref.: FXM-16393).

Thermal computations - Problem of convergency

When losses are very high, there is a convergence issue with the Thermal computations (ref.: FXM-15900).

Wrong thermal analysis

Zero values are allowed for housing, bearing or shaft dimensions but lead to the wrong thermal analysis (ref.: FXM-14705).

When creating a Flux skewed project, issue with project

If you save and close your project, it is impossible to open and solve it
If you solve the project, it is impossible to delete results and rerun the project (ref.: FXM-15638).

Export to FeMT with too long output path

The Flux script crashes when the output path for FeMT export is too long (ref.: FXM-15471).

Fault in the coupling FluxMotor-HyperStudy

An error in the FluxMotor process doesn't stop the HyperStudy execution (ref.: FXM-15402).

Script Factory does not stop correctly.

This occurs if the FluxMotor process has been killed externally. Then, Script Factory is not able to get back to a valid state, neither automatically nor after a kill of the process (ref.: FXM-15140)

Issue with exported Flux Skew projects

After exporting a Flux Skew project, if the user solves the project, deletes the results, and then solves again, the running of the project fails (ref.: FXM-15075).

Null values are not well managed while designing the Frame and shaft.

Null values are allowed for designing the housing, bearing, or shaft dimensions, but this leads to the wrong thermal analysis. It is highly recommended not to use null values for the considered inputs (ref.: FXM-14705).

Error while opening a motor (2020.1) with null shaft extension.

Opening a motor built with version 2020.1 (or older) with a null shaft extension leads to an error. With new versions, a null shaft extension is forbidden (ref.: FXM-14684).

The interwire space is not well defined.

The resulting value of the interwire space applied in the finite element model is twice the value set in the user inputs (ref.: FXM-14672).

Air material properties are wrong for high temperature.

This issue impacts our internal computation processes during transient thermal solving. Indeed, some iterations involve very high temperature (more than 3000 °K), according to the Newton Raphson non-linear solving method. During the resolution, this can lead to negative conductivity and viscosity, which may make the computation fail (ref.: FXM-14465).

Note: In case of a problem, an “Air material” with the right parameters can be provided.

When an IO cannot be loaded, the test results are not accessible.

When an IO cannot be loaded, the whole process that loads all the test results is stopped. As a result, no test is visible, although the issue may concern one result in a particular test (ref.: FXM-13941).

A wedge and/or inter-coil insulation region leads to a wrong slot equivalent thermal conductivity.

The slot radial thermal conductivity, which is automatically provided by the FluxMotor® in the "Cooling-Internal" context, and used in all thermal tests, is wrong if the slot contains faces "wedge" or "inter-coil insulator" (ref.: FXM-13896).

Power electronics and coupling with HyperStudy®

For tests where the settings "Electronics" is available, data like power electronics stage, maximum efficiency, and its rated power can be selected for generating a connector for HyperStudy®, but it should not be.

In the Export-HyperStudy® area, when the selected test is “Working Point, T-N”, the settings of “Electronics” - "Max efficiency", and "Rated Power" - are exported even if the associated option is not selected (ref.: FXM-13726).

Winding environment – MMF computation

The counter-clockwise sequence (MMF computation) is not considered in the Altair® Flux® model, which one can export. Only the clockwise phase sequence is considered (ref.: FXM-10280).

Using "phase sequence" set to "Counterclockwise" leads to wrong results in tests (ref.: FXM-13358).

Flux density isovalues

When a skewed topology is considered (synchronous machines or induction machines), the flux density isovalues, the vector potential isolines, and the rotor bars current density isovalues are not displayed (ref.: FXM-12564).

Japanese language and Flux software exports

When we export a Flux project (Flux2D, FluxSkew and Flux3D) some chracters are written in Japanese which makes the file crash during the execution. A work-around consist in delete all the Japanese characters and then execute the python file (ref.: FXM-16590).