standard input files about spec HOT 20 CLOSED

Perhaps we can use the ITER case that Sam had considered some time ago?

from spec.

@jloizu I'm working on it. For some reason I can't get it to converge. I'm playing around with simplifying the equilibrium a bit.

from spec.

@SRHudson I keep running into issues with F04AEF in tr00ab. Any suggestions?

from spec.

Eventually I would like to concentrate on input files that fail to converge, as we learn a lot about the performance of a code (and indeed the mathematical foundations of a code) by understanding what causes the code to crash.

However, at present it will be more productive to collect a set of inputs which test various aspects of SPEC's algorithm and for which SPEC performs well.

I have a free-boundary, non-stellarator-symmetric, axisymmetric iter case which is converging. Let's work on this case first before performing postmortems on your iter input.

I have placed the input file into the horrendously named TESTCASES subdirectory, and performed

git add iterfree.sp
git commit

Now what? Sorry that I am still ignorant with using git.

from spec.

Good! Next time you do a commit, do it like:

git commit -m "some short explanatory message"

now, you can first check in which branch you are locally:

git branch

and if this is the branch you want to change (I guess it was the master?), then pull and push:

git pull origin branch_name
git push origin branch_name

where the pull is just to be sure that you are up-to-date before pushing. Once you pushed it, it will be changed in the remote repository, and we can all get up-to-date by doing a git pull.

from spec.

OK I just saw that you changed this on the ma00aa branch, which is fine because we will eventually merge it into the master.

from spec.

I will test this iterfree.sp case and use some diagnostics to have a look at it.

from spec.

I think that you should also include various examples of the input files that were used in the J. Plasma Phys. paper that is presently under consideration. I believe some cases enforced the rotational-transform constraint and that others did not.

I would like to see that every input file that is used towards either a journal publication and a presentation to be saved.

from spec.

I have added the input file iterfree.sp to the master branch. This file is different to the previous case that I added to ma00aa. This new input file should be used, and the older input file should be deleted.

There is a lot to understand about how SPEC converges in free-boundary mode and what problems are encountered that we can learn from this running SPEC on this input file. The input file contains the geometry of the internal interfaces that are consistent with force balance, so no iterations are performed by SPEC. If, however, the input file is changed to set Linitialize=1, then I believe that SPEC fails to converge. I think that there is a type of instability near the origin, which suggests that the regularization factor r^m that is included needs to be modified. I have a guess what the problem is, and I will begin work on this soon.

from spec.

Just adding to an earlier comment, I suggest that Joaquim create a subdirectory in TESTCASES called 2017JPPLoizu or 2017Loizu, and places into this subdirectory every input file used in his paper submitted to J. Plasma Phys.

We do not need to routinely test new versions of SPEC on every input file, but I can easily imagine that in one or two or three years from now that someone, perhaps a student, would like to extend this work. An incredible amount of work is saved if the original input files can be recovered.

Another point related to saving input files, both for debugging and archival purposes, is the issue of backward compatibility. Thus far, I have not been too concerned with backward compatibility as SPEC was going through rapid development and there were not many users. But now things have settled down, and backward compatibility becomes more attractive. I suggest that as a variable becomes redundant because of code improvements that the variable is kept in the namelist even though it may not be used anywhere else in the source.

The redundant variable need not be written to the output .sp or .sp.h5 file; however, this may be desirable. We will also develop a visualization package, and it will be desirable for this to be able to interpret old output files.

from spec.

I will work on this this coming week (iter free-boundary testing, and adding some reference input files used for published material).

from spec.

I pulled the master branch, compiled, and run the iter-free-boundary testcase @SRHudson uploaded.

As Stuart mentioned, with Linitialize=0,the force imbalance is already down to 1e-14 and no iterations are performed. When I look at a poincare plot, however, I see some "vertical shift" in the field-line-traced trajectories, while the interfaces look good, see uploaded pdf herein.

iter_poincare.pdf

from spec.

@jloizu That's a non-stellarator symmetric equilibria. So your plot of the interfaces looks off. I did a similar plot last night (no Poincaré plots) and it seemed reasonable.

@SRHudson What did you use the generate this model?

from spec.

Thanks @lazersos , indeed I had to include the non-stellarator-symmetric terms in the analysis.
Now the poincare plot makes sense (attached).
iter_poincare_correct.pdf

from spec.

@SRHudson I confirm that the iter-free-boundary testcase does not converge for Linitialize=1.

I looked at the q-profile versus flux (see attached) and since q(0)<1 it could be that the equilibrium is simply ideal-kink unstable (even the converged case) and thus gives problems when deviating from the equilibrium. What do you think?

iter_qprof.pdf

from spec.

@SRHudson Also, is the field-line-tracing routine also tracing the last (vacuum) volume? From the source, it looks like it, but then when loading the data, I do not see where are these points (even if nptrj=-1 for the extra-volume, lvol=Mvol).

from spec.

Stuart wrote:

I have added the input file iterfree.sp to the master branch. This file is different to the previous case
that I added to ma00aa. This new input file should be used, and the older input file should be deleted.

I have deleted such file from the ma00aa branch and pushed that modification. You can

git pull origin ma00aa

in order to be up-to-date with that branch

from spec.

I think that the failure to robustly converge for this free-boundary iter-like case is associated with regularization problem near the coordinate/magnetic axis. The geometry of innermost interface goes crazy. Please see
http://w3.pppl.gov/~shudson/Spec/packxi.pdf
where I have given a brief description of the coordinate pre-conditioning factor that I have included.
Also, I think that the spectral constraints,
http://w3.pppl.gov/~shudson/Spec/lforce.pdf
are an absolute mess. The spectral constraints need to be revised. I think I know what to do, and I think that I am close to having this problem fixed once and for all, but I have not had the opportunity to concentrate on this problem. If this matter is deemed a priority, then I will work on this.
Note that I can get spec to converge for this case. It just requires a little human intervention and playing around with different choices of Linitialize. See
http://w3.pppl.gov/~shudson/Spec/global.pdf
for the possible values of Linitialize.

There is, however, potentially a more serious problem with this iter-like free-boundary case. Do I have the correct sign on the plasma current? What is the rotational transform negative? Do I have the correct normalization on the magnetic field at the computational boundary produced by the plasma current (computed using the virtual casing)?

I uploaded this input file for reference. It would be a lot easier to verify that free-boundary SPEC is working for tokamaks using a circular cross section boundary configuration.

from spec.

A comment on the idea of Stuart about uploading input files corresponding to published material.

I think that this is a good idea, but there are two issues:
(1) the input files that were used to run the previous ("pre-GIT") version of SPEC are not directly compatible with the new version of SPEC. For the l2stell.sp case, I had to clean the input file manually in order to make it run with the current version.
(2) in some papers, e.g. the last JPP2017 under revision, I performed fine beta-scans and have hundreds of input files.

Given (1) and (2), I think that a representative selection of input files for each paper should be carried out (I can then clean these selected input files manually) and then upload them.

@SRHudson would that be satisfactory?

from spec.

Yes, that would be satisfactory. The point is, and I think you understand, that we should be able to reproduce published calculations at an arbitrary time in the future.

from spec.