CoilSolver Crappy potentials for multi-turn circuit case

[jvencels]

@ettaka 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.

[jvencels]

Comparison. On the left it runs, on the right it fails.

[ettaka]

I looked around a bit. Didn't find the problem yet, but I cleaned the case up so it will be easier to narrow the problem down: only_coil_solver.zip

[jvencels]

I tried running the case, getting convergence problem:

     500 0.4154E+10
     501 0.4154E+10
ERROR:: IterSolve: Numerical Error: Too many iterations were needed.
STOP 1

@ettaka Can you reproduce "crappy potentials" error with cleansed case?

[ettaka]

@jvencels yes, I did reproduce it also. I must have uploaded some other try. I will upload another

[ettaka]

This gives me the error you mention: only_coil_solver.zip

[ettaka]

I see that the coil current is fine, but the coil current e is terrible

Even if I have commented out "Component 2" here, coil solver seems to still compute the same thing for the other coil turn too (I set Coil Start/Coil End at the boundaries)

[ettaka]

What I found now is that if Component 2 is defined (even if Electrode Boundaries is not used) then the Crappy potentials issue emerges.

And if I compute without Components (with Coil Start/End) Then I get weird CoilCurrent e

[ettaka]

OK. Now I found that CoilSolver was activated in air. It is one issue (not sure if it solves the main issue) because now I get better fields in CoilCurrent e

Nope... This is a separate issue.

So the main issue kicks in when the Component 2 is activated (does not matter if Electrode Boundaries is used or not). One has to inspect what the effect of Components is in CoilSolver next.

[jvencels]

In the case I shared before, the coil solver is not solved in the air. Regarding Component 2, that sounds like the cause of the problem.

[ettaka]

That is the correct way. I'll try to review further today if I have time.

[ettaka]

I had a look now and it seems that if one adds CYCLE just before line: https://github.com/ElmerCSC/elmerfem/blob/48ade7a16ddaeee4ceefe7314e1ecb0f675667e6/fem/src/modules/CoilSolver.F90#L361 Then the results are as expected. If one adds it after that line, then the problem re-emerges. FYI @raback

FYI @jvencels, Maybe as for a temporary hack, you can try to use that.

[jvencels]

Thanks, @ettaka I will proceed with further testing.

[jvencels]

@ettaka @raback, this quick fix seems to work for crappy potentials. What could be done to have it in the devel version?

I had a look now and it seems that if one adds CYCLE just before line:

https://github.com/ElmerCSC/elmerfem/blob/48ade7a16ddaeee4ceefe7314e1ecb0f675667e6/fem/src/modules/CoilSolver.F90#L361

Then the results are as expected. If one adds it after that line, then the problem re-emerges. FYI @raback FYI @jvencels, Maybe as for a temporary hack, you can try to use that.

[raback]

Unfortunately this fix does not make any sense to me. If you add CYCLE before that then there will be no coils as defined in the "component" section? I will have a look with the test case.

[jvencels]

This is the recent case I use to test homogenization + circuits. homoCirc.zip Used it for testing with/without CYCLE

[raback]

Ok, so there was a bug that materialized when there multiple non-closed coils. The CoilIndex was set in a place which was never reached resulting to problems. With closed coils this was reached and no problems occurred.

Further the test case was somewhat inconsistent. The user could define the CoilSolver in different set of bodies that what was the union of the Master Bodies of the components. This does not make sense so some Fatals were added. Also the user could give both Coil Start/End and Electrode Boundaries. It suffices to do either.

Changes are in devel.

[raback]

Just a comment why the "CYCLE" also fixed the issue, sort of. It basically enforced just one coil and because "Coil Start" and "Coil End" gave sufficient BC's there was no problem in solving the potentials. However, this meant that all coils where scaled together so one could not enforce different current to them. Just the combined current was set to be the desired current of the 1st coil.

[ettaka]

Just a comment why the "CYCLE" also fixed the issue, sort of. It basically enforced just one coil and because "Coil Start" and "Coil End" gave sufficient BC's there was no problem in solving the potentials. However, this meant that all coils where scaled together so one could not enforce different current to them. Just the combined current was set to be the desired current of the 1st coil.

@jvencels @raback Note that this was not intended as a fix but a hack that allowed the work continue.

[raback]

Indeed, it worked when there was a separate mechanism to scale each coil separately with the circuit machinery. But the fixed version should work also there now.

Maybe this can be closed now?

[jvencels]

Tested, seems to work fine.

[jvencels]

It seems that the case when components are of different types, has Crappy potential errors.

Case with one massive and two homo-stranded components: case1_oneMassivetwoStranded_testing.zip

[raback]

What should be done with Component 2 here? It is a coil but not associated with the CoilSolver. Now this causes problems as it tries to scale the potential which are not solved. I moved the sanity checks earlier to avoid this ambiguous Fatal but I think you would like to do something else with Coil 2 that with the other coils?

[jvencels]

Indeed, associating it with CoilSolver works.

I am assuming the transformer has solid and stranded wire types. All windings are connected to circuits.

[raback]

The code checks only that we have a coil:

  IF(.NOT. ListCheckPresent( CoilList,'Coil Type' ) ) CYCLE      

We could skip certain coil types.

[jvencels]

A stranded component with homogenization can be primary, while a massive/foil/stranded component without homogenization can be secondary. All combinations are possible.

For reference, such solvers are used for non-homogenized components:

• For Massive Components = WpotentialSolver + Circuits
• For Foil Components = 2x DirectionSolver + RotMSolver + WpotentialSolver + Circuits
• For Stranded Components w/o homogenization = WpotentialSolver + Circuits

Recently @ettaka connected homogenized stranded to circuits. Further, CoilSolver was added instead of alpha/beta fields to allow modeling wires of any cross-section (e.g round).

1. So, skipping components that are not using CoilSolver might be one option.
2. Might using CoilSolver for massive/foil/stranded components be another option?

[raback]

Ok, I replaced the Fatal with a Warn in case the Component has a coil but no CoilSolver defined in the equation block. Should allow for a hybrid case. It then takes back the NoCoils=NoCoils-1 and continues to the next one. Hope this helps.

[jvencels]

Seems to work. Thank you!