deprecation of search direction if VMEC fails #60
Comments
|
The latest push to the stellcopt branch resolves the MGRID issue. Would you like me to rebase it and repeat the pull request? |
|
@pomphrey So we no longer set chisq to a large value when a search direction fails. The LMDIF algorithm does print the number but instead the search direction is explicitly removed from the Jacobian. This was done because setting chi-squared to a large number results in the individual chi's being smaller. The resulting Jacobian array would produce unexpected results when inverted. So the correct method of reducing the space dimensionality was implemented. The search direction are explicitly deprecated now. The input files output after the major iterations do output the value which they had at the time VMEC was run. This way they should reproduce any VMEC run when used. However, when I try to run your test case something weird is happening. For some reason the code isn't running in free boundary. Can you upload a full test case for us (input, cws, coil and mgrid parameters to produce the first mgrid file)? |
|
@lazersos Please copy the following files from /p/stellopt/ANALYSIS/Pomphrey/LDRD20/STELLCOPT_RUNSwTF/RUN7 input.RUN7, cws, COILS.RUN7.00000, TFcoils, terpsichore_input_00, terpsichore_input_01 If you don't want to run with terpsichore, set the two SIGMA_KINK values in the input file input.RUN7 equal to 1.e30. The mgrid parameters appear at the end of input.RUN7 under &MGRID_NLI. Otherwise, you can simply copy mgrid_RUN7.00000.nc in which case you don't need to copy the coilsfile. I think the reason the code is running in fixed boundary mode is that it was unable to find the mgrid file. |
|
@zhucaoxiang can you upload the files? I don't have access to the PPPL cluster. |
|
@lazersos Here it is. The MGRID file is too large to exceed the size limit. |
|
@pomphrey I've been able to run this case now on Marconi using the I can confirm that the input files are not updating the RBC/ZBS values. However, this is by design. The RBC/ZBS values in free boundary are only initial conditions for the free boundary simulations. In the old version of STELLOPT these would be updated to be whatever the free boundary simulation had found. However, this caused two problems. First it was possible that if you took that input file and tried to run it, VMEC would fail to converge. This is because the input file no longer contained the initial condition for the run. This led to the second problem which was that overly detailed boundary specifications would fail to converge when simpler boundaries would in fact converge. This is less to do with the boundary and more to do with the multi-grid behavior of VMEC. It's a trivial matter to output the RBC/ZBS harmonics from the I would nominally propose that we include an option Regarding the DELT problem. Nothing in the VMEC input namelist should be changing from run to run unless the optimizer is changing the value. So if you set DELT=0.4 then it should always be 0.4 in the files. |
|
I think your proposal to include the LBOUND_UPDATE option is good. For
cases where the plasma shape changes a lot in the simulation I have found
it necessary to update the boundary shape to get the initial equilibrium to
converge so, personally, I expect I will normally set this variable to T.
The W7X plasma shape may not change a lot from start-up to full plasma
parameters, but certainly when we were doing ramp-up simulations for NCSX
where we were essentially coupling STELLOPT to a transport code there was a
significant shape change. That would be an example where the initial guess
for RBC/ZBS would end up being far from the values at the end of the
simulation and difficulties would ensue.
With regard to the DELT problem, if VMEC is having problems converging it
will change DELT and send a message to the screen. So in STELLOPT
simulations when, for example, one is raising beta to find a kink stability
or ballooning limit there may come a point where VMEC struggles to find an
equilibrium with an initially aggressive DELT. So DELT can change during a
STELLOPT run. At present there may not be any communication of the DELT
change by VMEC to STELLOPT so this info would have to be passed on if any
change is decided ... your decision.
…On Fri, Jun 12, 2020 at 5:14 AM Samuel Lazerson ***@***.***> wrote:
@pomphrey <https://github.com/pomphrey> I've been able to run this case
now on Marconi using the stellcopt branch. I've got a couple of notes:
I can confirm that the input files are not updating the RBC/ZBS values.
However, this is by design. The RBC/ZBS values in free boundary are only
initial conditions for the free boundary simulations. In the old version of
STELLOPT these would be updated to be whatever the free boundary simulation
had found. However, this caused two problems. First it was possible that if
you took that input file and tried to run it, VMEC would fail to converge.
This is because the input file no longer contained the initial condition
for the run. This led to the second problem which was that overly detailed
boundary specifications would fail to converge when simpler boundaries
would in fact converge. This is less to do with the boundary and more to do
with the multi-grid behavior of VMEC. It's a trivial matter to output the
RBC/ZBS harmonics from the wout file.
I would nominally propose that we include an option LBOUND_UPDATE which
when set to T will overwrite the RBC/ZBS values in vmec_input with the
values from the WOUT file. The source to do this is actually commented out
in stellopt_load_equil.f90 so implementation would be simple.
Regarding the DELT problem. Nothing in the VMEC input namelist should be
changing from run to run unless the optimizer is changing the value. So if
you set DELT=0.4 then it should always be 0.4 in the files.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#60 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIEWEBOV5SJ5YX5MC6GZGPDRWHWWBANCNFSM4NG5SDPQ>
.
|
|
I'm closing this bug, as I've opened a enhancement issue #83 which tracks this since I believe the original bug has been addressed. |
When running STELLOPT in free-boundary mode, it appears that either (a) a search direction is not deprecated by returning a large Chisq if VMEC fails to converge or (b) input files at the end of a major iteration step when using lmdif do not list the actual value of DELT and boundary fourier coefficients (in the VMEC namelist) that were used to calculate the equilibrium during the STELLOPT run. This is evidenced by my failure to reconstruct an equilibrium using input file input.RUN7.00318 with mgrid file mgrid_RUN7.00381.nc. However, when I decrease DELT to 0.2 from 0.4 the equilibrium DOES converge. It is quite possible that (b) is the problem and not (a)!
Also, at the end of each major iteration, the name of the mgrid file referenced in the input file should be changed from one that contains an _opt string (eg mgrid_RUN7_opt0.nc for the case of the 1st iteration) to a string such as mgrid_RUN7.00000.nc that corresponds to the saved mgrid file, and the boundary fourier coefficients in the VMEC namelist should change from the input 'guess' to the values calculated for the actual free-boundary equilibrium shape.
Code execution was in /p/stellopt/ANALYSIS/Pomphrey/LDRD20/STELLCOPT_RUNSwTF/RUN7
input.RUN7.txt
The text was updated successfully, but these errors were encountered: