Joaquim

The reason I am saying this is because in `dforce`, when `LComputederivatives=1`, it looks like the matrices `dMA, dMB, `etc. are used to invert the Beltrami solution, but if I...

Here is a funny discovery: Running SPEC with the **same input** file twice gives **different results**! This is for the cases with `LBeltrami=2` where the helicity is constrained. For example,...

@zhucaoxiang what do you mean here by the Hessian? Because this case is for Nvol=1, namely no force-balance required. Do you mean the Jacobian used by the Newton method for...

@zhisong in which commit did you randomize the field initial guess? Does this apply when Linitgues=1? I cannot find this. Of course that would already explain why a result may...

I tried the new version of the branch helicity-fix with `Linitgues=1` and now the results are reproducible (as expected from the lack of random guess) and also the code successfully...

I have pulled the branch ` helicity-hessian` and verified to machine precision that the Hessian at fixed helicity is properly calculated. I have used a 3-volume slab case (one with...

You can find now the verification of the Hessian to machine precision here: SPEC/InputFiles/Verification/hessian/fixed_helicity/ Notice this is as of now only in the helicity-hessian branch.

@zhisong Yes, I agree. I would suggest that you add a warning if LBeltrami=2 and Igeometry=3 and Nvol>1, saying something like "Hessian needs to be revised/verified". Then, we could merge.

That's really great! That sets the first milestone towards SPEC speed optimization. Looks like what Stuart suggested, namely optimizing the volume integrals by e.g. exploiting symmetries, is the way to...

OK I agree with the work flow, but then we should first merge the ma00aa branch with master (I will do some final testing) and then create a new branch...