Resolve y-axis and w based local coordinate system #440
Conversation
|
FYI @jvencels |
|
When compiled in Debug mode
This error does not appear when compiling as Release. I did not test on other cases. |
|
@jvencels thanks for reporting! I added a fix. Let me know if it works for you. |
|
Thanks @ettaka |
|
I was thinking whether it would be more compact to replace: with If you look here you see that for stranded coils keyword "Solver: Use Elemental CoilCurrent = Logical" already overrides the current. 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 Do you have an idea what the problem could be? @raback |
|
@jvencels, could you confirm that the example works? Thanks! |
|
@ettaka it works! |
|
@raback this is regarding the CoilSolver. 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 |
|
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? |
|
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. |
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
force-pushed
the
feature/local-coordinates-based-on-w-and-y-axis
branch
from
906ba68 to
6b67b59
Compare
|
@raback @jvencels I think we have two separate issues now that are not directly related to the current PR.
I suggest that we merge this PR and create two separate issues for those above. Is that OK? Thanks and have a great weekend! |
|
Ok, merged as requested. Great weekend to you too! |
|
@ettaka Removing Coil Start and Coil End from boundary conditions resolves the issue with (2) #440 (comment) |
|
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. |
|
CoilSolver is supposed to extend the homogenization method for tranded/litz windings, which is quite common for high-freq applications. 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? |
|
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? |
|
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. These are the difference in cases: |
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_homogenizationis 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 usingsigmaandnuparameters 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 (AlphaandBeta).The main point now is to get rid of the direction solvers. The other major change is to use
CoilSolversolution to drive the circuit (instead ofWSolver). There are many benefits for using theCoilSolver, for example, one can calculate closed coils.The important new keywords (with respect to ) here are:
Body: Local Coordinate System Beta Reference and Gamma = Logical TrueCoilSolverComponent: Coil Normal(3) = Real 0. 0. 1.CoilSolverneeds to know how the coil is orientedComponent: Desired Current Density = Real 1.0CoilSolverwill set a certain current density over the coilComponent: Coil Use W Vector = Logical TrueW Vectorfor which a name can be providedW Vectorset here is used for driving the component with circuitsComponent: W Vector Variable Name = String "CoilCurrent e"W VectorBoundary: Coil Start = Logical TrueCoilSolverneeds a boundary for knowing where coil starts (if not closed)Boundary: Coil End = Logical TrueCoilSolverneeds a boundary for knowing where coil ends (if not closed)Issue #429