Skip to content

Investigate the output variables #16

Closed
#34
Closed
Investigate the output variables#16
#34
Assignees
saddahaitao-ZCU

Description

@sadda
sadda
opened on Sep 2, 2026

Short summary

The output variable f seems to have different values than the input variable f. This causes the extracted variables from Ansys to have different values than expected.

Long description

  • Investigate why this happened.
  • Replacing f by some other name (or worse, by hard-coding 50) is not an option because we may encounter it again in the future.
  • Try to understand whether it may happen for other variables.
  • Is there any check possible for this behaviour?
  • Before starting the PR or fixing the issue, post the summary in this issue in proper Markdown formatting.

Estimated time investment

1-3 days

Activity

  1. sadda
    assigned
    sadda
    and
    haitao-ZCU
    on Sep 2, 2026

  2. haitao-ZCU commented on Sep 3, 2026

    @haitao-ZCU
    haitao-ZCU
    on Sep 3, 2026
    Collaborator

    What I have investigated:

    1. Cause of the incorrect evaluation

    f reads incorrectly because it conflicts with Ansys Maxwell's own intrinsic variable names. Maxwell reserves several intrinsic names, including F, Freq, R, Temp, and more (https://ansyshelp.ansys.com/public/Views/Secured/Electronics/v242/en/Subsystems/Maxwell/Content/UsingIntrinsicVariables.htm). Matching is case insensitive, so f and freq conflict with these reserved names.

    1. Verification

    Tested several candidate names by assigning them the same value and comparing against a hardcoded reference. f, freq, R, Temp gave wrong results, t, w, V, I, L, fr behaved correctly. Matches the documented list exactly.

    1. Time vs time

    Time (capitalized) is required in output variable expressions, time (lowercase) in the winding excitation source, not interchangeable.

    1. Variables we actually use

    Tested InitPos, f, RotSpeed, Nper, PointPer, PolePairs, RotSign, Rstat, Lew for real, not just against the list. All correct except f.

    1. Separate bug found along the way

    A normal Computation2 run crashes in extract_results(): solutions.data_real() returns a plain list, and the code does an in-place division for unit conversion, which lists don't support. Likely the "main does not run" issue, opened a separate PR fixing it.

    1. Proposed check

    Compare a candidate variable name against the documented list (case insensitively) before pushing it to AEDT.

  3. sadda commented on Sep 3, 2026

    @sadda
    sadda
    on Sep 3, 2026
    CollaboratorAuthor

    @saxik13 Can you please check this? Haitao claims that having f in the expression for the output variables does not work because it is protected (see the link above). Actually, it works, but the value is taken from some other variable, so instead of erroring, it gives a nonsensical answer.

    @haitao-ZCU Can you please provide Honza the code (here) where you substituted 50 for f and it gave you a different answer?

  4. haitao-ZCU commented on Sep 4, 2026

    @haitao-ZCU
    haitao-ZCU
    on Sep 4, 2026
    Collaborator

    of course.
    Here is the repro script: https://github.com/AI-RICE/MachineDesign/blob/diagnose/f-vs-50-repro/notebooks/diagnose_f_confirm.py
    It pushes diag_coeff_50 (hardcoded 50) and diag_coeff_f (symbolic f) as output variables computing the same coefficient, they should match but diag_coeff_f comes out 50x smaller, as if f were 1.

  5. sadda commented on Sep 4, 2026

    @sadda
    sadda
    on Sep 4, 2026
    CollaboratorAuthor

    @haitao-ZCU Thanks, can you also paste the actual results (output of the script), please?

  6. haitao-ZCU commented on Sep 4, 2026

    @haitao-ZCU
    haitao-ZCU
    on Sep 4, 2026
    Collaborator

    Sure, results are:

    dIA_dt           = [8.1681409e+09 8.1681409e+09 8.1681409e+09 8.1681409e+09 8.1681409e+09
 8.1681409e+09 8.1681409e+09 8.1681409e+09 8.1681409e+09 8.1681409e+09
 8.1681409e+09]
diag_coeff_50    = [408.40704497 408.40704497 408.40704497 408.40704497 408.40704497
 408.40704497 408.40704497 408.40704497 408.40704497 408.40704497
 408.40704497]
diag_coeff_f     = [8.1681409 8.1681409 8.1681409 8.1681409 8.1681409 8.1681409 8.1681409
 8.1681409 8.1681409 8.1681409 8.1681409]

where diag_coeff_50 is correct (408.4), diag_coeff_f is 50x smaller (8.168), same formula, only f is symbolic instead of hardcoded.

  7. saxik13 commented on Sep 4, 2026

    @saxik13
    saxik13
    on Sep 4, 2026
    Collaborator

    Not sure where the problem could be. I use the variable "f" for the frequency definition in models and it is without problems.
    I can imagine that if you input f=50 Hz and try to output f from Ansys, you get f=50e-9. It is problem of Default units in Ansys (GHz) (I commented in Issue #25) But it is not the problem you are facing right now

  8. sadda commented on Sep 4, 2026

    @sadda
    sadda
    on Sep 4, 2026
    CollaboratorAuthor

    @saxik13 This is not a problem with units almost for sure. Haitao has changed f to fr everywhere in the inputs and outputs, starting from

    "f": "50Hz",

    to

    "fr": "50Hz",

    The output for this change is different. This implies to me that it is unsafe for ANY computation to use f (or any other variable used in Haitao's link) because there is probably some overwriting of variables (it seems after the Ansys solution happens and before they are accessed by pyaedt).

    There are some Postprocessing variables (such as Freq or Time) which cannot be set by the user and if it happens, the call returns an error (tried both while changing f to Freq and freq). The problem may be that F is Frequency of the circuit/system analysis and this value gets accessed by pyaedt.

    This problem may potentially affect other projects as well. I think that changing f to something else is the minimum change we must do. Any ideas?

  9. sadda commented on Sep 4, 2026

    @sadda
    sadda
    on Sep 4, 2026
    CollaboratorAuthor

    One more thing. It seems that Ansys is case-insensitive for variables (even though Google told me otherwise). That goes back to the difference between time and Time Haitao mentioned and which Vasek highlighted. When we changed time to Time in the equation

    I_A = "Im1*cos(2*pi*f*time+epsI1-pi) + Im3*cos(3*(2*pi*f*time)+epsI3-pi)"

    there were no changes in the results (making the original Haitao's assessment 3 probably wrong). It probably makes sense because we never define time or Time.

  10. haitao-ZCU commented on Sep 4, 2026

    @haitao-ZCU
    haitao-ZCU
    on Sep 4, 2026
    Collaborator

    Update on point 3 (Time vs time, I wrote in the first comment.):
    after switching f to fr. Time and time give the same results in both dIA_dt..dIE_dt and I_A..I_E. So they are interchangeable here, this point was wrong.

  11. saxik13 commented on Sep 4, 2026

    @saxik13
    saxik13
    on Sep 4, 2026
    Collaborator

    I agree that the simplest solution is not to use "f" as a variable. Its only usage is to be multiplied by 2pi and for the definition of the rotating speed of the model. We can directly use w as w=2pi*f.

    It is true that it seems like for the variables, Ansys is case insensitive, and we should avoid the names from that list...

  12. sadda commented on Sep 4, 2026

    @sadda
    sadda
    on Sep 4, 2026
    CollaboratorAuthor

    @haitao-ZCU I think that we are ready now for a PR. I think we should continue (along with the suggestion of Honza) by doing:

    • Remove f by created a new variable w, which is 2.pi.f. Check that it can be replaced everywhere.
    • Unify time and Time.
    • Get a list of variables from the webpage (I would probably add all or at least the most important ones) and write checks that they do not appear in (the keys of) the dictionaries which we have there. If so, there should be an error. This should be a general property in one fo the base classes and the checks should be performed automatically. Write some tests for this behaviour.

  13. haitao-ZCU commented on Sep 4, 2026

    @haitao-ZCU
    haitao-ZCU
    on Sep 4, 2026
    Collaborator

    @sadda Agreed. I'll open a branch for this and start with removing f in favor of w = 2pif, then unify time/Time, and finally add the reserved-variable check with tests. It should be 3 PRs for these three items.

  14. haitao-ZCU
    linked a pull request that will close this issueReplace design variable f with w to avoid Ansys intrinsic variable co… #30on Sep 4, 2026
  15. haitao-ZCU
    removed a link to a pull requestReplace design variable f with w to avoid Ansys intrinsic variable co… #30on Sep 5, 2026
  16. haitao-ZCU
    linked a pull request that will close this issueAdd automatic check for Ansys reserved variable names in ComputationBase #34on Sep 8, 2026
  17. sadda
    closed this as completedin #34on Sep 10, 2026

  18. sadda commented on Sep 10, 2026

    @sadda
    sadda
    on Sep 10, 2026
    CollaboratorAuthor

    This was resolved in 32, 33 and 34.

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

Metadata

Metadata

Assignees

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