PROCESS no longer runs successfully after using write_new_in_dat script

[jonmaddock]

In GitLab by @kellis on May 17, 2018, 16:11

NB. I am running PROCESS without PLASMOD, but it is the PLASMOD branch. Commit 6b313b5d.

Working from the 'baseline 2018' file given to me by James, I made some changes with (sensible) feasible results. I then made the following changes:
iradloss = 0 (previously default value of 1) coreradius = 1.0 coreradiationfraction = 1.0
Following this successful run, I used script 'write_new_in_dat.py'. I ran the resulting file, but with no successful result - PROCESS failed with iflag 6 after 2 VMCON iterations.

Script write_new_in_dat appears to be doing what I expect, so the question is, why is PROCESS having difficulty with a solution which it has already found?

Files attached:
iradloss0.zip

(filename 'iradloss' is original; new_IN is the one written by write_new_in_dat)

@mkovari @jmorris-uk

[jonmaddock]

In GitLab by @Hlux on May 17, 2018, 16:13

Our initial assumption is that some of the values that are only correct on second iteration in PROCESS as causing this issue. I know there are several instances where PROCESS is only calculating the correct value the second time it is called. Maybe it is therefore worth calling caller once before doing any VMCON iterations??? Otherwise I do not see any reason why a working file using the output values of the iteration variables should no longer work.

[jonmaddock]

In GitLab by @kellis on May 18, 2018, 14:52

Investigation with @mkovari showed the bug IS in write_new_in_dat. Variable fimp(13) was not being overwritten with the new value. When I update this to the correct value (9.99e-5 instead of 0.00044) PROCESS finds the solution in 8 iterations. This fixes my problem. I will now look into the write_new... script and see what needs doing to fix this.

[jonmaddock]

In GitLab by @kellis on May 18, 2018, 14:59

Correction: @mkovari says this is actually a bug in PROCESS, and whether PROCESS is using fimp(13) or fimpvar.

fimp(13) = 9.9939e-05  *0.00044
fimp(14) = 5e-05
fimpvar  = 9.9939e-05 * Impurity fraction to be used as fimp(impvar)
impvar   = 13 * Impurity to be iterated (deprecated)

[jonmaddock]

In GitLab by @mkovari on May 18, 2018, 15:06

There is a choice - EITHER

1. First fix the longstanding problem with write_new_in_dat (TF coil geometry not well documented and not very precise #603) so that all the iteration variables are correctly updated, including the impurities when they are selected explicitly as iteration variables. Then remove code for fimpvar altogether. Update the relevant files in the test suite.
   OR
2. Fix the bug in PROCESS, so that when fimpvar is used it overwrites the relevant impurity value before anything else happens. This can be done in initial.f90, for example.

[jonmaddock]

In GitLab by @Hlux on Apr 24, 2019, 08:28

Dear @jmorris-uk , I think this was actually a quite important issue. It is currently assigned to me, but I am struggling to look into any issues at the moment. Do you want to pick this up or redistribute on the next issue meeting?

Thanks,

Hanni

[jonmaddock]

In GitLab by @jmorris-uk on Apr 24, 2019, 09:47

I can add it to the list of issues to discuss at the next meeting.

[jonmaddock]

In GitLab by @jmorris-uk on May 2, 2019, 13:40

Remove fimpvar and impvar.

[jonmaddock]

In GitLab by @jmorris-uk on Jul 17, 2019, 18:03

removed milestone

[jonmaddock]

This problem (Process not being able to solve when the initial optimisation parameter vector is the previous solution) has been resolved by #3186, which ensures that model evaluations are stable before returning objective function, constraints and gradients back to the solver, and all values in the MFILE are stable before writing a final solution file. I believe this problem was caused by a single model evaluation at the solution vector at the end of an optimisation run (i.e. with a history close to the solution) and the same point evaluated for the first time (the start of the subsequent optimisation run) providing different values to the solver, hence different convergence results. As the models are now ensured to be idempotent before returning values, this can no longer happen.

I have tested this with the large tokamak regression test solution, which, when converted into a new input file, converges instantly at the same point, as expected.