Repository navigation
named the wideband fit's elements the data does not determine, kept a CLI batch going past a file that crashes the engine, and noted the line's fragile refit - #30
Conversation
… which ended the command with a traceback and left the files after it unconverted
…the fit can move by 3 x at 1 % more error, from the curvature at the optimum (`_spread_warnings`), with the reason when a skin section lies above the band
… refit that a 1e-12 change of the data tips back to near-passive in 1 or 2 of 8 tries
…e line, instead of onto it
…actor at no more than 0.5 % more RMS error, where the curvature missed a saturating cost and invented a spread, floored the cost per goal instead of per point, and kept tied half coils on one skin section order
…d two noise draws give
…ne and the linear guess, kept the near-null directions of the others out of its steps, stated the bound of a fit below the floor, and named the check in the progress line
|
Hi @simi1505 please notify if there is something that I should fix in the upstream code. BR, |
|
@VolkerMuehlhaus a follow-up on the wideband inductor models you contributed, released now in snp2le 0.1.18. Elements the data does not determine. On the bundled center-tapped coil ( Your 1.2 skin penalty. The snp2le port follows inductor_fit from before your 1.1. 1.2 ( A latent issue in the center-tap sort, also in your current On why the values move: with |
|
Hi Simon @simi1505 to give some background: There were some issue when I used this model for inductor surrogate work, the N=1 inductors dind't fit well and we did some extra checks for smoothness and consistency in those models. This is what Claude answers to your post: Thanks — I checked all three points against inductor_fit. Is the 1.2 skin penalty the fix? No. On the bundled center-tapped coil, the uniform 1 + 1e-12 scaling barely moves 1.1 or 1.2 (R_skin2_h1 13.75 → 13.64 Ω in 1.1, 7.64 → 7.73 Ω in 1.2), so your 75 % comes from the pre-1.1 code. A random relative change of 1e-12 (three seeds) moves it in both versions, though: | R_skin2_h1 range | spread | fit cost range -- | -- | -- | -- 1.1 | 9.3 – 27.2 Ω | 2.9x | 0.007266 – 0.007288 1.2 | 7.6 – 18.0 Ω | 2.4x | 0.007304 – 0.007312 1.2, ftol=xtol=gtol=1e-12, 5000 evaluations | 8.7 – 11.2 Ω | 1.3x | 0.007307 – 0.007310The penalty lowers L_skin2 and narrows the spread, but it is too weak to make the direction unique. The corner of section 2 stays above the band: 113 GHz on this 60 GHz coil, about 450 GHz on the 500 pH coil. Your remark on the stopping criterion holds: tighter tolerances narrow the spread further but don't remove it. So your witness check would still name these elements after a 1.2 port. Center-tap sort: confirmed, thanks. It is fixed in inductor_fit 1.2.1 the same way you did it: when skin elements of the halves are tied, half 2 takes half 1's order. Only the reported values were affected; the circuit was not, since the series sections within a half can swap. As you found, a real fit never triggered it: synthetic center-tapped coils built with reversed corner order in half 2 were fitted with the same order in both halves. |
Three follow-ups from the work on #29, none of them visible on a default conversion of a bundled file except the new note on two coils.
Added
inductor_fit._spread_warnings()), for exampleRskin2_h1 (x3), Lskin2_h1 = Lskin2_h2 (x3) and Rskin2_h2 (x3) are not determined by the data, each can change by that factor or more while the fit's RMS error grows by 0.5 % or less (skin section 2 has its corner above the fit band, where it acts as plain L, and Basic model leaves section 2 out).Fixed
engine.convertraise: the command ended with a traceback, and the files after it were never converted. Such a file is now reported as[FAIL](after its progress bar has cleared the line), its stale outputs are removed, and the batch goes on with exit code 1.Docs
doc/architecture.mdon the note above, and a caveat ontline_100um: at orders 9 and 13 it comes out passive through the refit with its 0 Hz point, but a random 1e-12 change of its S values made that refit miss in 1 to 6 of 8 tries (the line then reads near-passive at 5.24), on scikit-rf 1.12, 2.1 and 2.2 alike. Order 6 gave the same result in every try.Verification against main
reuse lintclean, no file with CRLF in the index.[FAIL]line on the progress bar and the sort tie issue, all fixed. The second confirmed that every name has a valid witness and found misses near flat directions of the other elements (fixed: the search starts from the cheaper of the element alone and the linear guess, and leaves those directions out of its steps), the wording of a fit below the floor, and three wrong numbers in the docs, all fixed.