Giter Club home page Giter Club logo

Comments (6)

jloizu avatar jloizu commented on June 21, 2024

Here is an example of input file (one has to remove the .txt extension) that illustrates what I mean.

l2freeboundaryexample_L0.sp.txt

from spec.

jloizu avatar jloizu commented on June 21, 2024

As identified by @SRHudson , the problem is that the angle constraint coefficient sweight , which is defined in preset.h, was proportional to tflux in each volume. However, in free-boundary and e.g. Lconstraint=0, the toroidal (and poloidal) flux in the outermost volume, namely the vacuum volume, is modified in order to ensure the constraint of the linking current(s). Thus, when force-balance is obtained, the restart .end file contains a converged geometry but the value of tflux (which is the one initially in the input) has not changed, so that when the code is run again with this new file as input, the part of the force-balance that corresponds to the angle constraints is not converged. For example, one gets initially:

newton : 6.03 : 0 0 ; |f|= 5.43747E-03 ; time= 5.87s ; log|BB|e=-16.44
newton : : ; ; log|II|o= -3.10

from spec.

jloizu avatar jloizu commented on June 21, 2024

One way to fix this, as proposed by @SRHudson, is to remove the dependency of sweight on tflux,

SALLOCATE( sweight, (1:Mvol), zero )
!sweight(1:Mvol) = upsilon * tflux(1:Mvol)**wpoloidal
do vvol = 1, Mvol ; sweight(vvol) = upsilon * (vvol*one/Nvol)**wpoloidal
enddo

from spec.

jloizu avatar jloizu commented on June 21, 2024

I created a branch called fixrestart and applied this change. I checked that the code compiles and runs, and that the restart problem has been indeed fixed.

An important caveat is that the angle constraint (and therefore the angle definition itself) is different than before, even if running the same case. That makes comparison with previous runs very hard: the physical solution should not change, but for example the harmonics Rmn,Zmn,etc. will be different.

from spec.

jloizu avatar jloizu commented on June 21, 2024

One alternative would be to keep the definition of sweight as before and write in the .end file the new values of tflux that have been calculated during the previous run.

from spec.

jloizu avatar jloizu commented on June 21, 2024

Problem solved via the branch fixrestart. Closing issue.

from spec.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.