Warnings for function ncore

[jonmaddock]

In GitLab by @stuartmuldrew on Jul 9, 2018, 08:32

The function ncore in plasma_profiles.f90 calculates the central density of a pedestal profile, however there is currently no warning if the central density is less than the pedestal density. Additionally, under certain situations it returns a negative central density without stopping. I will add a warning to the error list.

[jonmaddock]

In GitLab by @stuartmuldrew on Jul 10, 2018, 13:12

created branch 735-ncore

[jonmaddock]

In GitLab by @stuartmuldrew on Jul 10, 2018, 14:09

mentioned in commit 90f7ddd5ddac024534591074ee09ef7a2b9d4003

[jonmaddock]

In GitLab by @stuartmuldrew on Jul 10, 2018, 14:44

mentioned in commit 18af683e2aa401094b5940ef73071087d3c9cdc1

[jonmaddock]

In GitLab by @stuartmuldrew on Jul 10, 2018, 17:01

mentioned in commit e9a3810ba87f8859447297072f733a9322d0008a

[jonmaddock]

In GitLab by @mkovari on Jul 17, 2018, 11:51

I don't think it should be possible for the central density to be less than the pedestal density unless the density profile exponent has a silly value. Is there a bug in ncore?

[jonmaddock]

In GitLab by @stuartmuldrew on Aug 24, 2018, 09:07

The equation for the core density is given by:

ncore = 1.0D0 / (3.0D0*rhopedn**2) * ( &
         3.0D0*nav*(1.0D0 + alphan) &
         + nsep*(1.0D0 + alphan)*(-2.0D0 + rhopedn + rhopedn**2) &
         - nped*( (1.0D0 + alphan)*(1.0D0 + rhopedn) + &
         (alphan - 2.0D0)*rhopedn**2 ) )

I guess if the pedestal density is set to be very high in the input compared to the volume averaged, then the core density can end up low. I've added the warning so maybe this will inform the user not to do that.

The reference for that equation is the Johner (2011) HELIOS paper, however it doesn't appear in that form. In the paper the central density is written in a very convoluted way.

[jonmaddock]

In GitLab by @stuartmuldrew on Oct 9, 2018, 16:03

Attached is Hanni's Mathematica file ped_averages.nb

[jonmaddock]

In GitLab by @mkovari on Oct 10, 2018, 08:50

Can you attach this file as an image?

[jonmaddock]

In GitLab by @stuartmuldrew on Oct 24, 2018, 16:59

Unfortunately that is the only file Hanni could find and I don't have access to Mathematica to run it. Is there a machine with Mathematica installed?

[jonmaddock]

In GitLab by @mkovari on Oct 24, 2018, 17:05

Not that I know of

[jonmaddock]

In GitLab by @skahn on Jun 10, 2019, 11:46

Hi all

Investigation results

It is really possible for Hanni's formula to be right and the issue to be caused by the fact that the nav (volumic average electrons temperature also dene) value of the iteration is too low.

It appears that even though raising the flag and the appropriate action is commented in the terminal :
The 2 CHECK: boundl(6) has been raised to ensure dene > neped
nothing is really done in the value, and therefore dene is at some point low enough to get a negative central density value.

Proposed solutions

It seems that all of these problems comes from the fact that the pedestal and the separatrix densities are defined in a different than the average density value :

• The average electronic density is a optimization variable with only an upper limit using fGW on it.
• The separatrix and the pedestal electronic densities are defined with an exact fraction of the greenwald limit

In this situation, the pedestal densities can be set at a relatively high value while the average densities are free to vary to lower values, causing from time to time negative central densities.

1. Find a way to really enforce the action printed in the warning messages
2. Rethink the way the density profile is parametrized to make sure that the density profile keeps the desired shape during the optimization process.
3. Add an inequality constraint equation make sure ne(0) > ne(ped) (already done in local version)

Solution 1

The constraint or the warning check is performed with the initial value of neped. If the neped is set with the greenwald fraction, the defauld PROCESS value is used for the test : 0.4E20.
If there is no lower boundary, there will be effectively a lower bound of 0.404E20.
In the STEP run, nesep is set with 0.65*nGW ~ 1.8E20. Therefore this security is not enough.

The solution would be to have a dynamic boundary setting for the average density, by the structure of the code is currently not adapted to this. The solution 3 therefore may be better for now.

Solution 2 proposal

If solution 2 is proposed, it can be parametrized as

• n0/nped set to a number
• nped/nsep set to a number
• average densities set with the Greenwald fractions.

All the three would be set as exact values or iteration variables, with properly defined limit ranges

Solution 3

This is done in a local version, and although this is not perfectly avoiding the negative ne(0) values, it clearly improves the situation

Cheers

Seb

[jonmaddock]

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

removed milestone

[jonmaddock]

In GitLab by @skahn on Jul 29, 2019, 09:24

This has lead to a contraint, we can close this issue.

[jonmaddock]

In GitLab by @skahn on Jul 29, 2019, 09:24

closed

[jonmaddock]

In GitLab by @mkovari on Jul 29, 2019, 09:26

Hi Seb,
Are you saying that no action is required so the issue can be closed? If so, why?