nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Siemens Community Catalyst Program

The Siemens Community Catalyst program was co-created with our community to acknowledge technology leaders who consistently contribute to the Siemens Community. Nominations are accepted on a rolling basis.

Nominate Now

Looking for guidance on proper FEKO preprocessing regarding current sharing of stacked helical coils

DanielPerk

I've got the following setup, but am experiencing odd behavior related to mesh error. For example, when I increase the number of wire segments, and correspondingly the error associated with that wire, I notice that the current sharing in each wire begins to balance. This is counterintuitive, but perhaps the current in each wire isn't correlated to the error, but is correlated to something else I'm not looking at.

Helix_AltairTechCase_072926.cfx

Please assist.

Find more posts tagged with

Feko

Accepted answers

All comments

Torben Voigt

Hi @DanielPerk ,

Which version of Feko are you presently using?

When I run your model with Feko 2026.1 I don't get any error message. Could you specify which "mesh error" you get?

If you are referring to "WARNING 117: The ratio of the segment radius to length is too large" (not an error), this happens if wire segments are shorter then 1/5 of their length.

Best regards,
Torben

Torben Voigt

Hi @DanielPerk ,

I have removed the fine mesh settings of the wires. Now the warning doesn't show up anymore. I also relaxed the curvature mesh settings, since I think the parts "UmbilA", "UmbilB" and "UmbilC" were meshed extremely fine (at least in Feko 2026.1,). Model is attached.

test.cfx

Best regards,
Torben

DanielPerk

Torben,

Thank you for your response. Addressing the warnings was actually something I wanted to bring up as well, so I appreciate you already identifying and resolving them.

Regarding the R/L warnings, is there a way to quantify their impact on the final results? I've generally viewed those warnings as a secondary issue and, in some cases, have ignored them altogether.

As for the "error" I mentioned, I should have been more specific. I was referring to the error estimate plotted in postFEKO after requesting Error Estimation prior to solving.

To take a step back, I've been relying on two primary metrics to judge whether a solution is trustworthy:

Mesh Error Estimation – I try to reduce this as much as possible.
Input Impedance – I expect the source impedance to be approximately 200 mΩ + j(small value), ideally with the imaginary component below about 0.500 mΩ.

For the particular configuration I've shared, I would expect the current in all three coil wires to be nearly identical, with each carrying roughly 33% of the input current.

What I've observed, however, seems counterintuitive. When the mesh error is very low (<0.02%) and the input impedance is 203 mΩ + j0.0202 mΩ, the current sharing is about 37.6%, 28.7%, and 33.7%. On the other hand, when the mesh error is higher (around 1-2%) and the input impedance is approximately 206 mΩ - j466 mΩ, the current sharing improves to roughly 34%, 36%, and 30%.

Because of this, I'm questioning whether my setup is correct and whether I'm relying on the right indicators of solution quality. The results seem to suggest that a solution with poorer convergence metrics is producing a more physically reasonable current distribution.

Given this scenario, how would you approach the simulation? What metrics would you prioritize when determining whether the model is producing the most accurate results possible, and how would you reconcile a case where the convergence indicators appear to worsen while the physical results seem to improve?

Thanks for your help Torben,

-Daniel P

Torben Voigt

Hi Daniel,

Error estimation in Feko visualizes the change of currents between adjacent mesh triangles or mesh segments. This is typically used to identify areas where a finer mesh might be needed. In CADFEKO, you can automatically apply local mesh refinements to these areas as follows:

So a typical workflow would be

Simulation with Error Estimation request
Click on Error Estimate Refinement in CADFEKO
run solver again and compare results

This can be repeated if a significant change in the results is observed. A major advantage of automatic mesh refinement is obviously that the mesh is refined only locally, not everywhere. I wouldn't read too much into the error estimation value in POSTFEKO. There's actually no guideline on what constitutes a "good" or "bad" result. As I said, it can show you where mesh refinement might be necessary.

Here's what I always recommend if you have any doubts about the mesh quality:

Simulation with standard mesh
Refine mesh by ~10% or use fine mesh
Compare results

If results didn't change significantly, the standard mesh was good.

In your case, with all the mesh refinements in the model I see these deviations (deviation from avg in %, where avg is MeterA+MeterB+MeterC)/3) of the three currents:

DeviationA = ((MeterA-avg)/avg)*100 = 0.47018
DeviationB = ((MeterB-avg)/avg)*100 = 0.137191
DeviationC = ((MeterC-avg)/avg)*100 = -0.60737

Note, there are many warnings about very short segments.

Without any local refinements using standard mesh I get

DeviationA = ((MeterA-avg)/avg)*100 = -0.0198962
DeviationB = ((MeterB-avg)/avg)*100 = 0.0151716
DeviationC = ((MeterC-avg)/avg)*100 = 0.00472455

Similarly with a fine mesh I get

DeviationA = ((MeterA-avg)/avg)*100 = -0.0226881
DeviationB = ((MeterB-avg)/avg)*100 = 0.0165022
DeviationC = ((MeterC-avg)/avg)*100 = 0.00618591

From my perspective the standard mesh is sufficient.

I'd also like to point out that 19.8 kHz is a fairly low frequency for Feko. The wavelength is over 15 km, which makes the model electrically tiny. Fortunately, you've already enabled double precision (i.e., doubling the number of decimal places in the calculation) and low-frequency stabilization. Despite the low frequency, I expect the results to be quite accurate.

Files are attached.

files.zip

Best regards,
Torben

DanielPerk

Torben,

Thank you for the time you put into this post. Its good to know that there isn't any known method of results accuracy correlation with mesh error estimation. Based on your response, it sounds like focusing on the warnings and getting rid of those may be more useful for result accuracy.

I opened the "test" .cfx you attached and inspected the results. The current sharing is slightly better in this file versus the original model I uploaded. The way I determine this is a simple current1_1 cartesian plot. That said, the total current draw from your model is significantly lower than what's expected. With current 1_1 plotted, Im only seeing 3.8 - 3.9 amps, whereas the original model was 1.5+ kA. I've looked around but cannot see why this is the case. I'll keep searching, but we should be closer to 2500 - 3300 A total current in/out. We're expecting each wire in the coils to carry around 1 kA.

If you happen to know what is causing this, please let me know so I can address it. I've had this same behavior in a few of my other coil models, but it seemed to resolve itself with finer meshing. Not that this is the case with your model, but that's how I've been able to get the current back to what's being seen in the field.

I have two somewhat off-topic questions:

1: Is there a way to see if I have R/L warnings without solving?

2: is there a way to set up two or more configuraitons where the geometry changes as well as the request parameters? This coil has 5 separate tap locations, but ive not been able to find a way to have all 5 cases in one .cfx.

Thanks again for your continued help.

DanielPerk

Torben,

I've looked at every aspect of the .cfx file you sent, and I still can't find two things:

Why the current is so low. It should be around 3 kA.
Why your solution shows perfect current sharing between the three cables.

I have a feeling that if I can identify the cause of #1, then #2 may resolve itself as well, and the current distribution would no longer appear so perfectly balanced.

That said, the current split I am getting also doesn't seem reasonable. One cable is carrying less than 30% of the total current, while another is carrying close to 40%. I would expect the sharing to be much closer to what your results show, but with currents that are roughly 3 orders of magnitude higher.

Torben Voigt

Hi @DanielPerk ,

You have defined a 100 MOhm load on each of the three ports: MeterA, MeterB, and MeterC. This limits the current. I would recommend using 0 Ohm loads to measure the currents. I've also noticed that some wires are extremely thin. Since they also have a finite conductivity (58,130,000 S/m, like copper), there are high losses. If you enable the wire surfaces in the display settings, you can see their thickness:

For these wires no local mesh radius was defined, so the global mesh radius 5e-4 is used.

Note, in my model test.cfx I have already changed the global radius to "LitzDia/2". But there are still three wires on the tope with local mesh radius of "LitzDia/8". Maybe try to change their radius as well.

Regarding your other questions

Is there a way to see if I have R/L warnings without solving?
is there a way to set up two or more configurations where the geometry changes as well as the request parameters? This coil has 5 separate tap locations, but ive not been able to find a way to have all 5 cases in one .cfx.

1: Yes, you can activate "Only check the geometry" in the Component Launch Options:

2: No, the geometry/mesh of a Feko model is always identical in all configurations.

Best regards,
Torben

DanielPerk

Torben,

Thank you for your response, explanations, and answers to the two unrelated questions.

Regarding the analysis at hand, I still have not been able to apply the modifications you described and reproduce the same results obtained in your test.cfx model. Could you please explain exactly what changes were made when converting the helix-altairtechcase.cfx file I sent into the test.cfx file you returned?

Specifically, I need to understand how the model you provided shows nearly equal current sharing among all three cables while at the same time producing very little current throughout the overall system. In the original model, approximately 1.6 kA was being driven into the system.

For the simulation as a whole, the "meter" loads are intended only to prevent current from flowing into the coils below the locations where the umbilicals tap into them. Current is intended to flow upward through the top antenna load only, not downward into the "meter" loads. In reality, these endpoints are open circuits, so the expected current at the bottom three cable endpoints is effectively zero.

In addition to understanding the changes made between helix-altairtechcase.cfx and test.cfx, I would appreciate your thoughts on the lower triangular distribution network that is being used to split current equally into the three umbilical cables.

It appears that the inlet source wire, which contains the source and tune ports, is extremely sensitive to the manner in which it interfaces with the lower triangle. For example, I have observed that simply changing the number of vertices along the wire containing the tune port can shift the highest-current path from the inner coil cable to Umbilical A (the left-most coil when viewed from the source side).

My expectation is that such a minor geometric modification, such as changing the segmentation or vertex count of the input wire, should not materially alter the current distribution in the coils. The current flowing through each branch should be determined primarily by the branch impedances and geometry, not by the discretization of a single input conductor.

Does this behavior suggest that the current injection interface is not ideal? If so, would you recommend a different geometry for this interface, or perhaps a different approach altogether for achieving equal current distribution among the three umbilical cables?

Thank you for any additional insight you can provide.

Results with one segment on tune port input line. Middle umbilical carrying highest current:

Results with about 8 vertices on the input tune port wire. Umbilical A or left-most wire carries the highest current:

Torben Voigt

Hi @DanielPerk ,

Changes I made in test.cfx:

Remove all local mesh size settings for wires, faces and regions
In the Advanced tab of the Mesh dialoge, move "Curved geometry approximation settings" sliders to the right
Set "LitzDia/2" as global wire radius

Thanks for explaining the three 100 MOhm loads; now I understand your model better. For testing purposes, I placed three 0 Ohm loads in front of the upper triangle to see the currents in the individual wires there. As you already mentioned, these currents differ significantly in magnitude:

At this point, I can only assume that the "Thin Wire Approximation" is responsible here. The "Thin Wire Approximation" in FEKO is a method to efficiently simulate electromagnetic properties of thin wires. Instead of meshing the entire surface, it models the wire as a line, calculating current distribution along its axis. This significantly reduces computational resources and speeds up simulations, making it ideal for wire antennas and structures where the wire diameter is much smaller than the wavelength. It simplifies modeling by focusing on the wire's path and diameter.

Potential problem: The Thin Wire Approximation assumes that the current flows primarily along the axis of the wire and that the field distribution around a single wire is relatively uniform in the azimuthal direction. Strong electromagnetic coupling between them violates the "thin" assumption, as current distribution becomes non-uniform. This leads to reduced accuracy in calculated parameters and can cause numerical instabilities. If wires are very close (separation comparable to diameter), a full 3D surface mesh is often required for accurate results, despite higher computational cost.

I see that, combined with the extremely low frequency, as a problem. If you want me to investigate further I would kindly ask you to create a support ticket on the Siemens Support Center.

Best regards,
Torben