Skip to content

Ansys/Python computation boundary #25

Open

Description

@smidl

Short summary
Ansys AEDT's expression language is necessary if you want to access ansys internal variables, like field solution. Using it for common variable manipulation is redundant.

The concrete duplication. The same five-phase Park/Clarke transform is written out by hand three times in motors/motor2.py — L101 for flux linkage, L129 for current, L133 for voltage — off the cos/sin pairs at L81-82. None of it needs the solve; it is algebra on quantities the solve already produced.

Proposed rule. Ansys computes what needs the field solution — torque, flux linkage, InducedVoltage, forces, core loss. Everything downstream — Park/Clarke, RsI, LewdI/dt, peak search, terminal voltage at a given speed — is Python.

Reasons:

  1. One solve, many operating points. Flux linkage at a given current is speed-independent, so V = RsI + jw*psi re-evaluates at any electrical speed in Python. An Ansys output variable is frozen at the solved frequency, so computing voltage there costs one solve per operating point — 3× the FEA for a three-point profile, N× for a drive cycle. In our five-phase profile study that is the difference between one 220-geometry pool and three.
    Post-processing scalars stay cheap. Lew (L79), winding turns, bus voltage and Rs are all post-processing. Keeping them in Python let us re-score 581 stored solves at an arbitrary turns count with zero new FEA, and correct a stale Lew (1.44 → 2.4 mH) by re-scoring instead of re-solving 220 geometries.

  2. It can be tested. Ansys expressions have no unit tests, parse differently across versions (Fix ddt/deriv #15), and mix units inside one argument (2pif*Time - 72deg, L109).
    A Python transform is assertable, and tests/ now exists (CI: add pytest workflow #9, Add unit tests #20).

Activity

  1. saxik13 commented on Sep 4, 2026

    @saxik13
    Collaborator

    I prefer to do the Park/Clarke transformations inside Ansys. For our purpose, I agree that only the Flux linkage vector and inductance matrix are needed; other calculations are needed only without the Ansys-Python connection.
    During the preparation of the Ansys model, you prepare the materials, main geometry, and the names of the parameters once - together with the Output variables (Park/Clarke transforms). During the optimization process, you do not define it again. But you are sending fewer parameters from Ansys to Python.

    Regarding the units - sometimes it is tricky in Ansys. For example, if you multiple 2 variables with units defined, the resulting number can differ from the product you expected (2*5 is not always 10 in Ansys) - but its mainly problem with the speed definitions (Hz vs rad/s vs rpm etc...).

    Some of the output parameters are not in the main units (current in mA, inductance in nH). Its problem of the default unit definition in Ansys, which can be modified by the user. You can check it in Ansys-Tools-Optins-General Options - Default Units.

  2. smidl commented on Sep 4, 2026

    @smidl
    ContributorAuthor

    Ok, so would you like to have all the variabels that are there now? Or you see some candidates fro removing?

  3. saxik13 commented on Sep 4, 2026

    @saxik13
    Collaborator

    I would preserve only lines related to the flux linkage, inductances, and torque.
    So looking to in motors/motor2.py, we can remove L76, L77, lines L103-L126, L131-L134.
    Optionally also L127-L130 - it is only a check of the input currents.

    But as a next step, we will prepare these transforms automatically by a separate script - universal for a different number of phases and harmonics.

  4. smidl commented on Sep 4, 2026

    @smidl
    ContributorAuthor

    We already have tools for transformations, many of them general. So their use in computations is simple. I will prepare a PR.

  5. haitao-ZCU commented on Sep 22, 2026

    @haitao-ZCU
    Collaborator

    @sadda

    In PRs #31 , #44 , and #52 , we have successfully moved unnecessary variables in 5f-machine into python instead of using Ansys to compute them, so I think maybe we should also do the same thing for the 3f-machine.
    with this, we can simplify set_output_vars and set_variables in synrm_3f_60s.py once synrm_3f_36s.py follows the same rule.
    If necessary, I'll do that.

  6. sadda commented on Sep 24, 2026

    @sadda
    Collaborator

    @haitao-ZCU Yes, please, do it for 3-phase machines as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions