Who's in charge?

[SRHudson]

In another thread, Caoxiang suggested that I be responsible for keeping the master version consistent, clean and so so; however, I think that this will slow things down. I don't have much time. I can participate, but I cannot be the central person.

We do need to agree how to coordinate activities.

I suggest the following, initial, partition of responsibilities.

Joaquim should be in charge of the master version and identifying flaws and problems that need to be addressed. Joaquim will also regularly test the new versions of the code on standard input files to ensure that no bugs are introduced. Joaqium can also, with advice from others, map out the general research direction (i.e., should we concentrate on the free-boundary application, or compute a fixed-boundary W7-X with many interfaces, or should we work on computing the eigenvalues/vectors of the hessian to get a linear stability code for MRxMHD).

Sam can primarily be responsible for the Makefile, porting to different architectures, streamlining input and output (one goal of this work is to get SPEC into STELLOPT), and so on. Sam can also identify and pursue research applications, such as perturbed tokamak ITER relevant cases.

I can work on detailed aspects of the source, such as exploiting symmetries in the TTsscc(l,p,i,j) = TTsscc(p,l,j,i) matrix elements (see http://w3.pppl.gov/~shudson/Spec/ma00aa.pdf). Joaquim and Sam can inform me of subroutines which are not performing well or need to be completed so that their research agenda can move forward, and I will either fix the issues or explain what needs to be done. I will also maintain the LaTeX documentation so that we all will get a better understanding of the internal structure of the code.

Caoxiang, and Josh Breslau, can participate whenever and however they choose, such as helping to eliminate the NAG dependence etc.

Note that the above is just a suggestion for getting things started and is based on my estimate of how much time we each have to spend on this project. As we get the code up and running with Git etc., we can all use the code to perform whatever calculations we like.

[lazersos]

I would say it's probably overkill to specify things like this. The beauty of git is being able to create branches, test them and merge them. For example @StellaratorCoils, @jbreslau , and myself can both do work on the NAG removal simultaneously. So long as we don't try to replace the same line in the same file at the same time, things are pretty smooth. I would agree that Stuart should have final say about merges into the main repo, but this is a minor task in the end.

Also for the PPPL folks, Princeton offers an online course on git through Lynda, it's pretty comprehensive.

[jloizu]

Well I guess a consensus has to be found, and this probably lies somewhere in between what Stuart suggested and what Sam suggested. The "git" freedom is to be exploited, but of course there must be some guidance and control in order to guarantee code reliability and avoid too many branching and code versions.

I think we should try to concentrate efforts in creating a working (multi-institute) version of SPEC that we can verify (as I did with the IPP version) and then create a TAG-version, "SPEC 1.0" so-to-speak. This version could be partly or totally "NAG-free" - this remains to be seen depending on needs. In the meantime, efforts in making the code faster could be made, following certain branches.

I would suggest, as Sam, that we agree on some sort of "Stuart-clearance-procedure" by which Stuart gives green light for each merge into master. That should not be so hard to do.

Since I am quite experienced in running SPEC (it has been my main research tool in the last 3 years), I think I can provide good guidelines into the sequential needs of the code towards becoming an (even more) useful research tool. On the other hand, I have less experience in programming than Sam & Co, so we should coordinate our efforts efficiently - which means, in parallel, but not independently.

[SRHudson]

My main concern is the "Stuart-clearance-procedure". I will have perhaps a day at most per week to work on SPEC, and I don't want to slow the team down.

I guess that we should just get started on getting rid of NAG and establishing some standard test cases. Joaquim and I can become more fluent in the beauty of git, and everything will just work out fine.

[lazersos]

Just a general comment, we shouldn't be merging branches into each other. I cleaned up the master branch back to it's initial state (extra files and Makefile were left modified). The result is that the master branch no longer has the optimization of ma00aa.h in it and the removal of NAG from newton.h are no longer present. The optimization of the ma00aa.h routine is in the hotfix_Makefile branch and NAG_REPLACE branches. Hopefully, the hotfix_Makefile will be merged into master soon, @jloizu will report on this. At that point it'll be merged into master, and I think then we can merge it into NAG_REPLACE, since NAG_REPLACE will take some time to complete development.

[SRHudson]

Ok, thanks for the advice explaining that I need to learn how to use git. I can either learn how to use git better or start working on ma00aa. I choose the latter, and will learn git slowly.

By the way, I am very glad that a team has formed on this project. This raises the question: what are we to call this team? I suggest that we call ourselves the Thunderbirds, but I am open to other suggestions.

[jloizu]

Thunderbirds sounds nice, I always wanted to be able to fly and send lightnings at the same time. Although this is already the name of a Mozilla platform.

[lazersos]

A colleague at IPP has suggested "SPECtators." I would suggest we call ourselves "Project SPECial."

[jloizu]

Or "Project SPECtacular".

[SRHudson]

Dear Spectaculars,

I would like to make two suggestions, which as you will see I have name "Suggestion One" and "Suggestion Two".

Suggestion One: Can we agree that the source should be viewed with an editor with a horizontal width of 158 characters, and that no line should exceed a width of 158 characters? I think that having a wide screen makes it much much easier to read the source. As far as I know, the width = 158 is arbitrary. A little more perhaps?

Suggestion Two: Can we agree that that contributions to the source are identified. For example, I usually "sign" my edits with the date, such as " ! 27 Jul 17;", and now that we are multi-developer I am signing my edits with "! SRH; 27 Jul 17;". I also hope that internal comments are used to give some explanation of what is going on.

I would like to add a Comment, which as you will see I have named "Comment".

Comment: I consider that there are three levels of documentation. The highest level is published material, e.g. in Phys. Plasmas. The second level is the online LaTeX document, which I very much want to maintain. I hope that someone will soon adapt this to the Git format (as per the example provided by Caoxiang). The third level of documentation is internal comments. I hope that the spectacular contributors to SPEC, hereafter known as Speculators, will provide internal comments that will be illuminating.

[jloizu]

Suggestion One: I agree (I typically display the source code on 160-characters-width). Suggestion Two: I agree, especially on the need for internal explanatory comments. Comment: Fine with me. I think that when a TAG version of SPEC comes, SPEC-1.0 so-to-speak, perhaps we can think of summarizing documentation into a sort of "manual".

[jbreslau]

Regarding suggestion two, I certainly agree with the generous use of internal comments to make the code comprehensible. But I wonder if signing and dating every edit with such a comment is really a good idea -- as edits accumulate, it could contribute to clutter and hurt readability, and in principle at least, the revision log accomplishes the same thing.

---

Joshua Breslau Princeton Plasma Physics Laboratory Tel.: (609) 243-2677 Office: A-129 E-mail: jbreslau@pppl.gov Princeton, NJ 08543 Fax: (609) 243-2662

On Thu, Jul 27, 2017 at 8:01 PM, Dr. S.R. Hudson notifications@github.com wrote:

Dear Spectaculars,

I would like to make two suggestions, which as you will see I have name "Suggestion One" and "Suggestion Two".

Suggestion One: Can we agree that the source should be viewed with an editor with a horizontal width of 158 characters, and that no line should exceed a width of 158 characters? I think that having a wide screen makes it much much easier to read the source. As far as I know, the width = 158 is arbitrary. A little more perhaps?

Suggestion Two: Can we agree that that contributions to the source are identified. For example, I usually "sign" my edits with the date, such as " ! 27 Jul 17;", and now that we are multi-developer I am signing my edits with "! SRH; 27 Jul 17;". I also hope that internal comments are used to give some explanation of what is going on.

I would like to add a Comment, which as you will see I have named "Comment".

Comment: I consider that there are three levels of documentation. The highest level is published material, e.g. in Phys. Plasmas. The second level is the online LaTeX document, which I very much want to maintain. I hope that someone will soon adapt this to the Git format (as per the example provided by Caoxiang). The third level of documentation is internal comments. I hope that the spectacular contributors to SPEC, hereafter known as Speculators, will provide internal comments that will be illuminating.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PrincetonUniversity/SPEC/issues/4#issuecomment-318519331, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac620GQ3rn4-Lrqy6x-Cj1JsNJ7Fu1-Lks5sSSTfgaJpZM4OfgJv .

[SRHudson]

Dear Speculators,

Over the several years that I have been working on spec I have had to think carefully about political strategy. Initially, I was working on spec "in secret". The PPPL Theory Department, obviously, was not big enough for two MHD equilibrium codes that treat islands/chaos! The first task was to demonstrate excellent convergence properties with respect to numerical resolution (the first and only for such a code).

With the crucial help from Joaquim, we should that spec reproduced analytic results, in particular an accurate calculation of the singular currents (the first and only for such a code). Joaquim took this further and has shown that spec recovers scaling laws predicted by Friedberg (the first and only for such a code, sorry, you must be getting tired of hearing this).

So where are we now?

I had intended to get spec working for free-boundary non-stellarator-symmetric equilibria, and in fact most of this work has been completed. There are just a few subroutines that need to be tested etc. I have a non-stellarator-symmetric vacuum field calculation that I have verified to machine precision against a Biot-Savart code, and I will upload this input file to git soon. The only routine that has not been completely verified is the virtual casing, but I think I am very, very close.

However, I am beginning to change my mind with regard to strategy.

If we were to concentrate on getting spec really fast for fixed boundary equilibria (and on this topic we are making good progress) and improve the robustness of convergence (by revising the regularization factors that treat the coordinate singularity) then we might hit the front page by showing that spec is as faster, or even faster than vmec. This would be a game changer . . . .

What do you think? Should we prioritize free-boundary spec or fast fixed-boundary spec?

[jloizu]

Should we prioritize free-boundary spec or fast fixed-boundary spec?

I understand your points and I think that both are comparably important from the point of view of strategy. Having said that, I also think that robustness affects both fixed and free boundary spec, and is quite a critical issue. However, your progress in getting free-boundary is great and some time soon this could be published with some additional help from all of us.

My conclusion would be that since this new Speculators-team seems to have good potential, we could work on both issues in parallel. I could devote myself, with the help of @SRHudson, to solve the robustness issue. Also, I can help testingand verifying some free-boundary cases. For the speedup of the code, perhaps @lazersos , @jbreslau and @zhucaoxiang want to pursue their fantastic progress, with the help of @SRHudson.

These are just some thoughts.

[SRHudson]

We should not over-extend ourselves. Caoxiang should finish his PhD on the new focus code, which is actually producing some stunning results, which I hope he publishes really soon. Josh is an excellent programmer, so good in fact that he is required to spend most of his time working on transp and other projects. I am always amazed by Sam's ability to work, and make good progress, on multiple topics, but he is paid to develop stellopt, terpsichore and for experimental applications. I have found some time this last week to devote to spec, but I am unsure how much time I will have over the next few months.

So, even though we have an excellent team -- in fact the best team that I could have wished for -- most of us can only partially devote ourselves to spec.

We can inject ourselves with impact into the international stellarator community by (i) getting spec into stellopt, (ii) w7-x applications, or (iii) getting an invited talk.

As for getting an invited talk, we have to do something new, and I think that extending spec to enable a linear stability calculation would be exciting. This is really so close . . . . Think about a linear stability code (such as terpsichore) consistent with a partially relaxed equilibrium. (Another topic that Sam I think is interested in is rmp's & iter, and this could lead to an invited talk, and this is why that I prioritized free-boundary spec.)

Anyway, I just wanted to begin a discussion on this topic. Let's see how things go.

[jloizu]

Well @SRHudson mentioned all these busy people & their "assignments" but did not mentioned me :)

The truth is that I have an eurofusion grant that pays my salary and expects me to develop and use the spec code for stellarator and tokamak applications. That means, I may be the least knowledgeable of this team, but I have ~100% of my time available to invest on this project! However, I did not write this code and the documentation is not sufficient to understand all that the code is doing; which is why I need a little bit of help in order to make progress. So, all I can say is that I am ready to work on code robustness (regularization at the origin, etc.), for example, but I need some help, at least at the beginning!

[SRHudson]

The only reason I did not mention your activities is because I did not, until now, know what your activities are. Please forgive me (and sorry to hear that Neymar might leave Barcelona). I am very glad that you have %100 of your time for spec, and this is why I think that you should be in charge. I am happy to follow your, and Sam's, suggestions on how to proceed.

On geometrical regularization: see psifactor in preset.pdf and packxi.pdf. Start by reading the documentation, and as you have questions I will extend the documentation as required. We need an input file (preferably not a free-boundary case, as there might be some other problems with free-boundary) for which spec fails to converge. This is usually because there is an interface close to the origin. An axisymmetric, stellarator-symmetric boundary might be ok, and would be faster for debugging etc.