VMCON / COSSAN feasibility discrepancy

[jonmaddock]

In GitLab by @emiralle on Mar 11, 2020, 17:22

Hi,

I made an analysis of the feasibility of an input file (attached) using OpenCossan. We say a sample is feasible when it fulfils all the constraints. The method was the following:

1. Define parameter space (iteration variables);
2. Sample parameter space;
3. Run PROCESS without VMCON (ioptimz = -2);
4. Extract constraint parameters from MFILE;
5. Evaluate constraints.

I used as iteration variables the following (15 in total):

bt in [5.0, 6.0]
rmajor in [9.2, 9.6]
te in [12.0, 12.5]
beta in [0.020, 0.04]
dene in [7.1e+19, 7.4e+19]
ohcth in [1.1, 1.3]
q in [3.2, 3.8]
bore in [1.55, 1.70]
gapoh in [0.040, 0.055]
fvsbrnni in [0.30, 0.43]
vdalw in [0.00050, 0.0014]
gapds in [0.015, 0.025]
ralpne in [0.060, 0.075]
tfcth in [1.1, 1.8]
thkcas in [0.2, 0.8]

The intervals were defined arbitrarily. I just did their original values (2018 DEMO baseline) +- some arbitrary number not too large for this initial sampling. Sampling was made with Latin hypercube, and 1000 samples.

The constraints used to perform the analysis were:

-(a) Density upper limit;
-(b) Neutron wall load upper limit (8);
-(c) LH power threshold limit;
-(d) Net electric power lower limit (500);
-(e) Beta upper limit;
-(f) Injection power upper limit (50);
-(g) I_op/I_crit;
-(h) PsepB/qAR max (9.2);
-(i) Peak toroidal field upper limit (13);
-(j) tau_p/tau_eff (5);
-(k) TF temp. margin (1.5);
-(l) OH temp. margin (1.5);

The values in parentheses are the limits defined in the input file. Otherwise the limits are calculated in PROCESS, and therefore sample dependent. The only f-value used is for the density limit (1.2). Note that there are no equality constraints.

Everything defined here can be found in this input file template_IN.DAT. It is pre-defined to run with ioptimz = -2, and minmax = 18.

Also, the values defined at the bottom are those that led to a feasible solution:

-bt = 5.21511026991430
-rmajor = 9.20706496531877
-te = 12.4017358090378
-beta = 0.0283644431285763
-dene = 7.20011509676718e+19
-ohcth = 1.14787729936003
-q = 3.39420530604244
-bore = 1.65561810949693
-gapoh = 0.0465059275842240
-fvsbrnni = 0.334759011353181
-vdalw = 0.000814130735895917
-gapds = 0.0200739012885777
-ralpne = 0.0724549861277614
-tfcth = 1.57183516141506
-thkcas = 0.406462992278413

So VMCON will use these values as initial point, which according to COSSAN, is a feasible point.

When I say "according to COSSAN" what I'm basically saying is that the constraints are fulfilled, as I extracted the parameters of each constraint from the MFILE, and compared one by one whether they are fulfilled or not.

So those iteration variables, at these values, in the input file attached, yield constraint values that fulfil the conditions, using parameter values from the MFILE, and constraint definitions from the constraint_equations.f90 file.
However, when running VMCON with ioptimz = 1 and minmax = 18 (null figure of merit), it is unable to find a feasible solution (despite using an initial point that leads to constraint values that are successful).

The values of the constraints are the following (for the above values of iteration variables):

(a) 7.96090000000000e+19 < 6.68300000000000e+19 * 1.2
(b) 1.00160000000000 < 8
(c) 139.890000000000 > 113.310000000000
(d) 512.680000000000 > 500
(e) 0.0241205000000000 < 0.0568850000000000
(f) 50 < 51
(g) 11514000 < 27399000
(h) 7.53056094389663 < 9.2
(i) 10.8800000000000 < 13
(j) 5.07590000000000 > 5
(k) 2.58260000000000 > 1.5
(l) 1.86960000000000 > 1.5

In bold are the limits (either calculated or defined in the input file/default). So all fulfilled so far.

VMCON should find this point as feasible. So there must be something going on. Some possibilities:

1. The criteria used by VMCON to decide whether a run is feasible or not does not only depend on the value of the constraints (note that epsvmc is set ~0.1 in the input file, something reasonably large). Maybe there is something hidden, and this analysis cannot be performed using the MFILE;
2. The definition of the constraints is not exactly the one stated in the constraint_equations.f90 file;
3. I made a mistake somewhere in the analysis.
4. Other reasons.

Enrique

[jonmaddock]

In GitLab by @mkovari on Mar 11, 2020, 18:46

The criteria used by VMCON to decide whether a run is feasible or not does not only depend on the value of the constraints

As far as I know, if you use the null figure of merit, only the constraints should determine whether VMCON decides that an iteration results in a feasible solution.

The definition of the constraints is not exactly the one stated in the constraint_equations.f90 file;

The values of the residuals given in the table are calculated in an erratic way. However, the constraint array calculated in constraint_equations.f90 is the one used by VMCON.

Note that the once-through option has not been tested extensively. We know that there are some variables that do not have their correct values after the physics and engineering routines have been run once.

Please attach the OUT.DAT

[jonmaddock]

In GitLab by @emiralle on Mar 13, 2020, 13:46

Hi @mkovari,

this is the out.dat template_OUT.DAT.

and the mfile template_MFILE.DAT.

This is after running with null figure of merit, with the initial ITV points at the feasible solution found in Cossan.

[jonmaddock]

In GitLab by @mkovari on Mar 13, 2020, 14:03

You don't seem to have included any of the f-values as iteration variables, even though all the constraints are listed as equality constraints.

[jonmaddock]

In GitLab by @emiralle on Mar 13, 2020, 15:14

I'm not using f-values for this analysis. In my total set of constraints I have 3 equality constraints (radial build, beta consistency, and global power balance). However, these are deactivated (as well as tburn lower limit) to perform the analysis with the once-through. I don't have any f-value as ITV, and all of them (except fdene) are set to their default values.

Is it possible to run VMCON without f-values, and without equality constraints? I'm aware when running VMCON without f-values I had to specify the number of equality constraints, and define them at the top of the list (e.g. in my case it would be neqns = 3). However, it is not the case now, as I have all the equality constraints disabled.

So what I did now is to set nineqns = 12, as apparently it does the same job as neqns, but for inequalities.

Now the OUT.DAT state template_OUT.DAT:

Equality constraints : 00
Inequality constraints : 12
Total constraints : 12
Iteration variables : 15
Max iterations : 200
Figure of merit : +18 -- minimise Null figure of merit.
Convergence parameter : 2.00E-01

and still says it is unfeasible.

[jonmaddock]

This issue appears to involve non-idempotence in the models, which I believe would explain this behaviour. This is exactly what I have experienced: optimised solutions producing solutions that evaluate differently (perhaps infeasibly) when fed back in as non-optimising (once-through) runs, and Process not being able to converge its own solution. This has been fixed in #3185.