fix: cosmui, sinmui have wrong normalization factors for lasym=T #21
Comments
Further code changesThe following lines needed to be commented out in At IF (lasym) THEN
tcon = p5*tcon
END IFAt IF (lasym) tcon = p5*tconTesting with the SOLOVEV caseFor the
and with
Testing with the CTH-like Stellarator test caseI tested this now also with the Here are the results using the current
and with
It is noted that in the asymmetric case, the initial R and Z force residuals printed to the screen symmetric case: asymmetric case: I then re-ran this case with the changes on
and with
However, with these, changes, the force residual printout is the same: symmetric case: asymmetric case: We note that somewhere around iteration 800, the asymmetric case starts to break down. |
|
Going a little bit deeper, the issue seems to come from the zero-current algorithm in |
|
As a test, I switched to constrained-iota with an iota profile fitted to the equilibrium profile obtained from the free-boundary symmetric run: However, the convergence issues in the asymmetric case still persist. |
|
The scaling-down of |
|
Other places where
This should conclude the changes in other parts of VMEC. |
|
The following two sketches illustrate how the inverse Fourier transforms of the geometry to real space in The following two sketches illustrate how the forward Fourier transforms/integrals of the forces to Fourier space in |
This is an issue to track work related to the case of an (I think) incorrectly initialized
dnormfactor infixaray.f.The code changes happen on the branch
fix_cosmui.I found this problem when trying to understand the Fourier transform of the forces in VMEC.
The problem appears only when running VMEC with
lasym=T.Any (periodic) function can be decomposed into an even-parity contribution and an odd-parity contribution.
Some force components (armn, brmn, ..., clmn, frcon, fzcon) have even parity, some have odd parity when symmetry is assumed.
In the asymmetric case, the forces are decomposed into definite-parity contributions
and then Fourier-transformed over the poloidal half-interval [0, pi] (1, ..., ntheta2).
The decomposition into definite-parity contributions is done in
symforce.Those-parity contributions that would be the only ones in symmetric mode are Fourier-transformed by
tomnsps.The other-parity contributions are Fourier-transformed using
tomnspa.Concluding, the Fourier integrals computed to get the Fourier coefficients of the forces are only ever computed
over the poloidal half-interval [0, pi] and never over the full-poloidal interval [0, 2pi[ .
The Fourier integrals in
tomnsp*make use of the Fourier basis functionsstored in
cosmui,sinmui,cosmumiandsinmumi.These are filled in
Sources/Initialization_Cleanup/fixaray.f.Here, the normalization of the Fourier integrals is being done using the
dnormfactor.Note that this enters also in the flux-surface average weighting factor
wintthroughcosmui3.dnormgets changed to1/(nzeta*ntheta3)iflasym=T.In that case,
ntheta3equalsntheta1, which refers to the full poloidal interval [0, 2 pi[.The Fourier integrals done in
tomnsp*use thisdnormfactor to normalize the discrete integrals there,which however are still only being computed over half the poloidal range.
I think this is incorrect.
Instead,
dnormas used forcosmui, ...,sinmumishould always be1/(nzeta*ntheta2-1)as in the symmetric case.Furthermore,
cosmui3and in turn the weighting factorswintstill need to adjust to the changed poloidal interval.Thus, I propose to introduce
dnorm3infixaray, which shall get adjusted to reflect the actual number of poloidal grid points.The actual errors resulting from this mixup seems to be that in the asymmetric case,
the Fourier coefficients of the forces are too low by a factor of
ntheta3/(ntheta2-1)which is approx. 2.VMEC seems to be able to cope with that by just using more iterations,
but I think this should be fixed anyway.
The expected results of fixing this issue are:
lasym=T, the number of iterations should approximately stay constantThe
SOLOVEVcase from theDESCrepository is used as a simple test case here:Running this case with the current master branch, I get the following output:
Then
lasym=Tis put in the input file and the output now reads:The number of iterations has increased:
ns=16 from 272 to 533ns=256 from 1698 to 1906With the changes on this branch, the symmetric case runs in the same number of iterations
and the asymmetric case runs in 312 (for
ns=16) and 1685 (forns=256) iterations.TODO:
cosmui, ... are used and see if this has implications thereThe text was updated successfully, but these errors were encountered: