Who's in charge? about spec HOT 16 CLOSED

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.

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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

from spec.

Or "Project SPECtacular".

from spec.

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.

from spec.

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".

from spec.

from spec.

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?

from spec.

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.

from spec.

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.

from spec.

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!

from spec.

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.

from spec.