Resolve y-axis and w based local coordinate system

[ettaka]

The main application for the y-axis and w based local coordinate system is the stranded homogenization model where the homogenization parameters are oriented using the RotM transformation. The RotM transformation needs a local coordinate system and the wish is to be able to define it without direction solvers (in case of arbitrary wire cross-sections).

A test case derived from circuits_harmonic_stranded_homogenization is added. The original case computes the skin and proximity losses for a stranded coilcurrent via so called homogenization, where the strands are not geometrically in the model but their frequency responce is estimated using sigma and nu parameters that are gotten from the elementary solutions of 2D computations (transversal fields and perpendicular current). In 3D the cross-section needs to be oriented using the RotM transformation that requires the definition of a local coordinate system. For that we have previously used the direction solvers (Alpha and Beta).

The main point now is to get rid of the direction solvers. The other major change is to use CoilSolver solution to drive the circuit (instead of WSolver). There are many benefits for using the CoilSolver, for example, one can calculate closed coils.

The important new keywords (with respect to ) here are:

1. Body: Local Coordinate System Beta Reference and Gamma = Logical True

• CoordinateTransform computes alpha = beta x gamma: where beta is set to "Beta Reference" and Gamma is set to "coilcurrent e" computed by CoilSolver

2. Component: Coil Normal(3) = Real 0. 0. 1.

• CoilSolver needs to know how the coil is oriented

3. Component: Desired Current Density = Real 1.0

• CoilSolver will set a certain current density over the coil

4. Component: Coil Use W Vector = Logical True

• Coil uses a defined W Vector for which a name can be provided
• The W Vector set here is used for driving the component with circuits

5. Component: W Vector Variable Name = String "CoilCurrent e"

• Here we choose the correct field for W Vector

6. Boundary: Coil Start = Logical True

• CoilSolver needs a boundary for knowing where coil starts (if not closed)

7. Boundary: Coil End = Logical True

• CoilSolver needs a boundary for knowing where coil ends (if not closed)

Issue #429

[ettaka]

FYI @jvencels

[jvencels]

When compiled in Debug mode cmake -DWITH_MPI=TRUE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../install ../elmerfem the following error appears.

  10 0.1031E-06
  11 0.3683E-07
  11 0.3683E-07

WARNING:: CoordinateTransform: Polar Decomposition Determinant Tolerance not set. WARNING:: CoordinateTransform: Polar Decomposition Max Iteration not set. Fortran runtime error: Incorrect extent in argument B in MATMUL intrinsic in dimension 1: is 3, should be 4

Error termination. Backtrace: #0 0x7fe58f503960 in ??? #1 0x7fe58f5044d9 in ??? #2 0x7fe58f504989 in ??? #3 0x7fe58f6cde31 in ??? #4 0x7fe58ea6a930 in computerotm at /home/vencels/elmerfem/fem/src/modules/CoordinateTransform.F90:333 #5 0x7fe58ea696bd in rotmsolver_ at /home/vencels/elmerfem/fem/src/modules/CoordinateTransform.F90:263 #6 0x7fe58f88602c in __loadmod_MOD_execsolver at /home/vencels/elmerfem/fem/src/LoadMod.F90:465 #7 0x7fe58fc22eec in __mainutils_MOD_singlesolver at /home/vencels/elmerfem/fem/src/MainUtils.F90:5266 #8 0x7fe58fc20138 in _mainutils_MOD_solveractivate at /home/vencels/elmerfem/fem/src/MainUtils.F90:5609 #9 0x7fe5900b8afe in execsimulation at /home/vencels/elmerfem/fem/src/ElmerSolver.F90:2619 #10 0x7fe5900b6e39 in elmersolver at /home/vencels/elmerfem/fem/src/ElmerSolver.F90:664 #11 0x7fe59038e4a5 in solver at /home/vencels/elmerfem/fem/src/Solver.F90:57 #12 0x7fe59038e794 in main at /home/vencels/elmerfem/fem/src/Solver.F90:34

This error does not appear when compiling as Release. I did not test on other cases.

[ettaka]

@jvencels thanks for reporting! I added a fix. Let me know if it works for you.

[jvencels]

Thanks @ettaka Will test it and let you know

[raback]

I was thinking whether it would be more compact to replace: Component: Coil Use W Vector = Logical True Component: W Vector Variable Name = String "CoilCurrent e"

with
Component: Use Elemental CoilCurrent = Logical True

If you look here you see that for stranded coils keyword "Solver: Use Elemental CoilCurrent = Logical" already overrides the current.
https://github.com/ElmerCSC/elmerfem/blob/devel/fem/src/modules/CircuitsAndDynamics.F90#L602

Maybe it is too limiting that the name of the vector is same for all coils? The "CoilCurrent e" is fixed name of CoilSolver so it could be fixed for the module that is using its value.

[ettaka]

I was thinking whether it would be more compact to replace: Component: Coil Use W Vector = Logical True Component: W Vector Variable Name = String "CoilCurrent e"

with Component: Use Elemental CoilCurrent = Logical True

If you look here you see that for stranded coils keyword "Solver: Use Elemental CoilCurrent = Logical" already overrides the current. https://github.com/ElmerCSC/elmerfem/blob/devel/fem/src/modules/CircuitsAndDynamics.F90#L602

Maybe it is too limiting that the name of the vector is same for all coils? The "CoilCurrent e" is fixed name of CoilSolver so it could be fixed for the module that is using its value.

Thanks for the good suggestion! Unfortunately, there is something in CalcFields that does not agree with this:

      18 0.5324E-08
ComputeChange: NS (ITER=1) (NRM,RELC): ( 0.92046562E-07  2.0000000     ) :: mgdynamicscalc
      18 0.5324E-08
ComputeChange: NS (ITER=2) (NRM,RELC): ( 0.16796426E-06 0.58395797     ) :: mgdynamicscalc
      18 0.5269E-08
ComputeChange: NS (ITER=3) (NRM,RELC): ( 0.41757375E-07  1.2035657     ) :: mgdynamicscalc
      18 0.5504E-08
ComputeChange: NS (ITER=4) (NRM,RELC): ( 0.10611302E-06 0.87043311     ) :: mgdynamicscalc
      18 0.5616E-08
ComputeChange: NS (ITER=5) (NRM,RELC): ( 0.18957814E-06 0.56454255     ) :: mgdynamicscalc
      18 0.5632E-08
ComputeChange: NS (ITER=6) (NRM,RELC): ( 0.49610497E-07  1.1703536     ) :: mgdynamicscalc
       1        NaN
ERROR:: IterSolve: Numerical Error: System diverged over maximum tolerance.
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP 1

Do you have an idea what the problem could be? @raback Just to be clear: I use the keyword in Solver section: Solver: Use Elemental CoilCurrent = Logical

[ettaka]

@jvencels, could you confirm that the example works? Thanks!

[jvencels]

@ettaka it works!

[jvencels]

@raback this is regarding the CoilSolver. Could you please take a look at this change in the test case that causes

WARNING:: CoilSolver: No negative current sources on coil end!
ERROR:: CoilSolver: Crappy potentials, cannot continue!

I provided boundary IDs with coil terminals instead of electrode area, then swapped Coil Start/End

In the sif folder, there is the modified case to repeat the error 2241.zip

[raback]

Line ~150 in CoilSolver.F90 seems to suggest that if you provide "electrode boundaries" you don't even need Coil End / Coil Start. What if you drop them?

"Crappy potentials" seems to suggest that induced nodal currents are near zero. Is this a parallel problem or happens also in serial run?

[jvencels]

Correct. Removing the coil start/end solves the problem. Running the case in serial or parallel makes no difference.

I get the same error when I connect the coil driven by CoilSolver with other coils (e.g., massive, etc.) using circuits. Is it a limitation of CoilSolver or Circuits?

case1_oneStrandedtwoMassive.zip

[ettaka]

@raback @jvencels I think we have two separate issues now that are not directly related to the current PR.

1. Issue with using Component: Use Elemental CoilCurrent = Logical True (https://github.com/ElmerCSC/elmerfem/pull/440#issuecomment-1926641853, https://github.com/ElmerCSC/elmerfem/pull/440#issuecomment-1937921332)
2. Issue with CoilSolver (https://github.com/ElmerCSC/elmerfem/pull/440#issuecomment-1937921332)

I suggest that we merge this PR and create two separate issues for those above. Is that OK? @jvencels, could you create a separate issue for (2.)? Is it OK @raback for you to approve this? (This is anyway only a modification to CoordinateTransform.F90 solver.)

Thanks and have a great weekend!

[raback]

Ok, merged as requested. Great weekend to you too!

[jvencels]

@ettaka Removing Coil Start and Coil End from boundary conditions resolves the issue with (2) https://github.com/ElmerCSC/elmerfem/pull/440#issuecomment-1937921332 Do we need a Coil Start/End for anything?

[raback]

Coil Start and Coil End are used by CoilSolver to automatically set the BCs needed to create a coil current. As you can see in CoilSolver_init (line ~137) they are still used but derived from the "Electrode Boundaries". These were introduced independently and are redundant information. But it puzzles me why it should have any effect at all.

[jvencels]

CoilSolver is supposed to extend the homogenization method for tranded/litz windings, which is quite common for high-freq applications. Before, the RotMSolver was used with Direction solvers, but it can be applied to simple (square) winding geometries. CoilSolver+Circuits+Homogenization combo is supposed to be handy not only for magnetics, but also for modeling winding losses in electrical machines. There is interest from hardware/engineering people to help with validation, however there seem to be a few challanger regarding how CoilSolver gets connected to Circuits.

Regarding the case shared a week ago, it works if the component driven by CoilSolver is the only one. When we connect multiple components driven by CoilSolver to the circuit with other components, we get that error. This is the limitation of CoilSolver. Could you please check what is needed to have a full compatibility with circuits?

[raback]

So you mean there is a combination of currents such that some are from CoilSolver and some are not? Does the "CoilCurrent e" field look ok in each coil?

[jvencels]

I'll share another case to show the problem explicitly. The geometry has two simple turns.

oneCoil.sif - we connect only one turn to circuits, another one is modeled as air. This works. series.sif - we connect both turns in series using circuits and get an error. CoilSolver_Circuits.zip

These are the difference in cases: On the left sif where turns connected in series, on the right - only one turn Further, there are differences in circuit equations - one component and two components. The circuit setup should be ok as we use it all the time.