Closed jonmaddock closed 1 year ago
In GitLab by @rkemp on May 20, 2015, 13:47
Done in branch PROCESS_ped_dens_scaling. Had to swap the current calculation to before the pedestal calculation, but I do not think this should have any effect. Needs to be merged with full develop branch before closure.
In GitLab by @rkemp on May 20, 2015, 13:49
There is now a switch iscdens (default 0), which switches between setting pedestal density to neped (iscdens = 0) and to fgwped * Greenwald density (iscdens = 1). There is also a new input, fgwped, to set the fraction of Greenwald density at the pedestal top.
This is only active if ipedestal = 1 and iscdens = 1, of course.
In GitLab by @hlux on May 20, 2015, 13:52
Did you run this on one of the files in the test suite to a) verify nothing has changed for the iscdens =0 case and b) PROCESS does not start struggling finding solutions due to the additional variation in the iscdens = 1 case?
In GitLab by @rkemp on May 20, 2015, 13:57
I ran it on the baseline case with no convergence issues for various values of fgwped (and checked that the output was consistent with the input...). No variation on the baseline with iscdens=0.
In GitLab by @mkovari on May 21, 2015, 07:47
When I set neped
, the pedestal density, to zero (because I don't need it), I get an immediate error:
151 3 CHECK: density pedestal is lower than separatrix density
The check was being carried out even when it is not needed. I have fixed this (locally):
! Density checks:
! not required if pedestal is set using Greenwald density (Issue #292)
if ((iscdens == 0) .and. (neped < nesep)) then
fdiags(1) = neped ; fdiags(2) = nesep
call report_error(151)
end if
if ((iscdens == 0) .and. (abs(rhopedn-1.0D0) <= 1.0D-7).and.((neped-nesep) >= 1.0D-7)) then
fdiags(1) = rhopedn ; fdiags(2) = neped ; fdiags(3) = nesep
call report_error(152)
end if
! Core density should always be calculated (later) as being
! higher than the pedestal density, if and only if the
! volume-averaged density never drops below the pedestal
! density. Prevent this by adjusting dene, and its lower bound
! (which will only have an effect if this is an optimisation run)
! Not required if pedestal is set using Greenwald density (Issue #292)
if ((iscdens == 0) .and. (dene <= neped)) then
fdiags(1) = dene ; fdiags(2) = neped
dene = neped*1.001D0
call report_error(154)
end if
if ((ioptimz >= 0).and.(any(ixc == 6)).and.(boundl(6) < neped*1.001D0)) then
call report_error(155)
boundl(6) = neped*1.001D0
boundu(6) = max(boundu(6), boundl(6))
end if
In GitLab by @hlux on May 22, 2015, 10:23
Given that we are trying to get our documentation in the appropriate state and I have finally understood the arguments about the H-mode density limit, I think we should be adding the correct references for the default value of nped ~ 0.85 n_GW in H-mode scenarios i.e. M. Bernert (2013) "Analysis of the H-mode density limit in the ASDEX Upgrade tokamak using bolometry", PhD Thesis LMU München (http://edoc.ub.uni-muenchen.de/16262/) and M. Bernert et al. Plasma Phys. Control. Fus. 57 (2015) 014038, doi:10.1088/0741-3335/57/1/014038
In GitLab by @mkovari on May 29, 2015, 08:11
mentioned in commit c5bf7354a2c33ddd7df372d67740eaae766ad556
In GitLab by @hlux on May 12, 2015, 12:08
While we are not having a consistent pedestal model e.g. derived from EPED simulations in PROCESS, it has been suggested to implement a pedestal top density scaling with a fraction of the Greenwald limit. If this was the case, we should also revise how/when we actually apply the Greenwald density limit in its current form. (Do we need to implement constraints on the allowed peaking??)
@rkemp: I will not have the time to implement anything along those lines. As you though this would be worth doing, do you want to assign this issue to yourself??