Skip to content

Conversation

@antonellozito
Copy link

@antonellozito antonellozito commented Dec 7, 2025

This PR contains all the modifications that I coded for B2.5 in the last months. Whereas they were aimed to my own current research, I coded everything in such a way to make it as general as possible and "ready" to be painlessly merged to the codebase. I have done the equivalent code modifications also for the release/3.1.1 branch. As soon as this PR will have gone through, I will create one also for that branch, already containing any new further modifications which will be suggested during the review of this PR. The B2.5 documentation has been updated accordingly, and new conversion rules (when needed) have been also implemented.
The new code is fully working and functional (as I have been using it for several months already). As such, this PR is, from my side, ready to be reviewed.
The changes consist in:

  • Extension of the capabilities for simulating time-dependent ELM events. The modifications are based on the already existing possibility to define ELM transport profiles in b2.transport.inputfile (through the tdata(3,:,:,:) fields). However, so far only a periodic step increase of the transport coefficients was possible (which also had to be the same for all the coefficients). Now:

    • A more sophisticated dynamics is possible, including exponential/logarithmic ramp-up/down phases, with plateau phases in between.
    • All time scales defining the periodic alteration of the transport coefficients (start of ramp-up, end of ramp-up, start of ramp-down, end of ramp-down) can be different for the 9 types of coefficients defined via b2.transport.inputfile.
    • The periodic increase of the transport can be localized around the outer midplane through imposing a ballooning-type poloidal dependency (also possibly different for all coefficients).
    • All the above mentioned options can be enabled via parameters in b2.transport.inputfile. All changes are fully backwards-compatible, so the old ELM model could be still used as it was.
  • Added flexibility (and improved output) when invoking the neoclassical transport model via b2tqna_user_transport=8. Now:

    • It is possible to add the NEOART-calculated transport contributions only to a subset of all the possible radial transport coefficients (particle diffusivity/convective velocity, electron/ion thermal diffusivities, etc.), via the switches b2tqna_neoclassical_xxx (with xxx = dna,vla,hci,hvi,hce,hve), and only to a given range of the computational grid within the confined region, via the switches b2tqna_neoclassical_iystart/end, and only to a subset of all the B2.5 fluid species, through the logical array NEO_NS_SET of size (0:NS-1) within the new namelist b2.neoclassical_transport.parameters.
    • It is possible to perform the calculation of the neoclassical transport coefficients only every N B2.5 time steps, through the new switch b2tqna_neoclassical_time_steps (default = 1). When they are not re-calculated, the previously calculated ones are used. Note that, for now, the switch works as intended only when both b2mndt_nstg0 and b2mndt_nstg1 are 1, while it works also for multiple 2nd level iterations. I have not found a satisfactorily solution for a more general case so far, because of the additional instances in which b2tqna is called in case of multiple inner iterations (since b2tqna is called 2+nstg2 times per B2.5 time step if nstg0/1 = 1, I could code a solid rule for this case; however I was not able to understand the rule setting how many times per B2.5 time step b2tqna is called if nstg0/1 > 1). A better solution might be therefore desirable.
    • It is possible to print the calculated neoclassical transport coefficients by NEOART (all of them, not only those really added to the B2.5 radial transport coefficients) to a new b2neo.nc output file at each of its calls.
  • Added the time-dependent anomalous transport cofficients fields on the B2.5 grid as additional output in b2movies.nc

  • Added several additional quantities to b2time.nc, in particular with regards to multi-species quantities and Eirene-related quantities. Namely (the below list may be not exhaustive):

    • Regarding the scalar quantities: NEW fields are densities for all fluid species (nasep(m/a/i)), atomic/molecular densities from Eirene (d(a/m)bsep(m/a/i)), atomic/molecular temperatures from Eirene (t(a/m)bsep(m/a/i)). The corresponding averaged time traces and standard deviation time traces are also included.
    • Regarding the profiles: NEW fields are density profiles for all fluid species (na3d(i/a/r/l)), atomic/molecular density profiles from Eirene (d(a/m)b3d(i/a/r/l)), atomic/molecular temperature profiles from Eirene (t(a/m)b3d(i/a/r/l)). MODIFIED fields are midplane transport coefficients profiles (dn3d(a/i),vx3d(a/i),vy3d(a/i),vs3d(a/i)) and target particle flux profiles (fn3d(a/i)), which now contain the data for all fluid species, not only for the main ion. Note that for the target quantities, also the additional fields for case of DN geometries have been added/modified).
    • For convenience, now also midplanes and separatrix indeces (jxi, jxa, jsep), radial coordinates (dsi, dsa, dsr, dsl), target areas (dsR, dsL) and poloidal contact areas (dsRP, dsLP) are outputted to b2time.nc. Again, the additional coordinates for DN geometries are also included.
    • Related to the previous point: currently, b2mod_mwti also outputs the above mentioned coordinates and areas to the run directory on ASCII files named in the same way as the coordinate/area. On case-insensitive file systems (e.g. one one present by default on MacOS computers) this would create problems, because e.g. the strings "dsr" and "dsR" are interpreted as identical. I have therefore added a safety, thanks to which the code detects if this is the case, and, only in this case, the target areas are insted outputted to files named dsRT and dsLT, to avoid this problem. For case-sensitive systems (e.g. all Linux distributions), the output is unchanged. Again, same for additional areas in case of DN geometries.
    • Note that this change DOES break backwards-compatibility, because dimensions and variables in NetCDF files are immutable: once the updated version of b2mod_mwti will have been rolled out, appending fields in b2time.nc over data from previous runs (via b2mndr_stim < 0.0) will not be possible anymore, namely a new b2time.nc will need to be created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant