Home

Welcome to the SOLPS-ITER wiki!

These Wiki pages are intended for code users to collate questions, tricks, bug reports, and suggestions for further code improvements or new features.

You will find most of the code documentation, including the Release Notes for new versions, in the $SOLPSTOP/doc folder.

Which branch for which code version?

There are currently 4 main versions of the SOLPS-ITER code suite that are supported and maintained by the IO and meant for widespread public use. These are:

• The 3.0.10 master version: This is the reference code version. Its code base is only updated once or twice a year, when a change in the input file formats triggers a version number change), or to accompany a major change in the IMAS infrastructure, or when a critical major bugfix is implemented. This version is the most suitable for users that want a stable code base for a long period of time while running a large set of related simulations, for example.
• The 3.0.10 develop version: This is the most current code version. It has a fast moving code base and contains all the latest bug fixes and new feature implementations. Bugs found in this version will be quickly addressed and fixed.
• The 3.1.2 (9-point-stencil) version: This version provides for a 9-point-stencil numerical treatment of all B2.5 equations, and contains almost all the features of the 3.0.10 version. It is still a work-in-progress, but user experience is welcomed to help debugging the last remaining issues. This version however only supports the SOLPS5.2 physics model.
• The 3.2.1 (wide grids) version: This version relies on the 9-point-stencil numerical treatment and allows for the use of field-aligned unstructured grids, which can extend to cover the entire vacuum vessel. It also only supports the SOLPS5.2 physics model and many code features from the reference version are still being implemented. This version, unlike the others, also contains two Carre submodules, one for the original Carre code, and one for the Carre2 version, as it needs both.

When checking out the code for the first time, users are given the 3.0.10 master version. To navigate between those versions, and know which branch belongs with which version, please refer to the table below. The update scripts listed will fetch the corresponding branches and attempt to position the code at their top, if there are no local uncommitted files preventing that operation. If that is successful, the script will then try to compile the main components of the code suite in standard mode. If the script fails the first time, it should be attempted a second time, as the script may have updated itself!

Another useful branch is feature/CX-reactions which is a derivative of the 3.0.10 master branch, but in which the Uinp case build-up program will include, by default, all CX reactions between hydrogenic neutrals and impurity ions.

Naming conventions for SOLPS-ITER top directory

Because of the way the debug, mpi, openmp, ig, etc... scripts work, one should not use the strings ".debug", ".mpi", ".openmp", ".ig", ".tgt", ".hess", or ".adj" as part of the name of the SOLPS-ITER top directory.

Also, because of the way some scripts parse the toolchain name, the HOST_NAME variable should not contain a period (".") within itself.

Notes about applying core boundary conditions for drifts cases:

When running cases with drifts, it is recommended to use boundary conditions at the core boundary that allow for some amount of poloidal variation. For density and ion temperature, this means using (BCCON=21,22,23 and BCENI=23,24) for single fluid H/D/T plasmas or (BCCON=25,26,27 and BCENI=26,27) for multifluid plasmas. The poloidal variation of the electron temperature is however neglected. So the recommendation is to use BCENE=1 to prescribe a poloidally constant electron temperature and/or BCENE=16 to prescribe the total energy flux through the core boundary with poloidally constant Te, both with and without drifts. Both these BCs are compatible with the two sets of BCCON's and BCENI's mentioned above.

All combinations above of BCCON's, BCENE's and BCENI's should, in principle, work with and without drifts, and should not lead to a divergence of the potential equation solver. The difference is in the physical meaning of the obtained solution in a thin layer near the core boundary, where so called 'regular' profiles (i.e. with some poloidal variation) should be transformed somehow to satisfy the chosen boundary condition. The only restriction is the recommendation NOT TO USE BCCON=BCENE=BCENI=8 WITH DRIFTS, since it usually leads to a divergence. It is recommended to replace BCCON=BCENE=BCENI=8 with BCCON=BCENE=BCENI=16 (or BCCON=BCENI=26, BCENE=16, or BCCON=22, BCENI=24, BCENE=16).

For the potential equation the following boundary conditions are recommended: BCPOT=11 for the targets, BCPOT=12 for the core boundary and BCPOT=13 for the PFR south boundary and north boundary. It can often be numerically preferable to use BCPOT=2, POTPAR=0.0 on the N and S boundaries if sharp gradients near them are observed or if the drift flows lead to plasma fluxes coming into the domain through these boundaries (note: this may still yield a charge source on the core boundary).

Recommended setting for NFILE variable in Eirene input file

The NFILE variable appears in block 1 of the input, as the fourth integer on the first line of integers. It contains 5 digits, so we make the equivalence NFILE = JKLMN. This variable governs the use of binary files fort.10 to fort.15 by Eirene. Please consult the Eirene manual for full details, but, as a reminder, here are the most common settings in use for SOLPS-ITER runs:

• The unity digit, noted NFILEN in the code, rules the fort.10 and fort.11 files. These files contain data that can be used for Eirene diagnostics and data post-processing. If NFILE=1, these diagnostics will be written for individual strata as indicated by the flags in block 11. If NFILE=6, only the sum over all strata will be written out. However, it has been found that the I/O involved with these files, particularly the fort.10 file which can grow to a rather large size, can slow down runs on some systems, so it is recommended to users not to use these optional files by setting NFILEN=0.
• The tens digit, NFILEM, is for the fort.12 file, which contains geometry data. This option is not used in SOLPS-ITER, so NFILEM=0 should be used.
• The hundreds digit, NFILEL, is for the fort.13 file. This file contains information that Eirene uses to remember data needed for the BGK neutral-neutral collisions treatment. If your case does not include neutral-neutral collisions, you can set NFILEL=0. Recall however that Uinp will include neutral-neutral collisions by default if your case includes hydrogenic and/or helium species. Thus, in such cases, Uinp will impose a non-zero value. This value used to be 4 if one used the DivGeo default (which can be set in the “Global Eirene Data” dialog box) or 3 from the default inherent to Uinp if it had not been saved from the DivGeo file. This discrepancy in the defaults between Uinp and DivGeo has now been fixed. In addition, and this is not yet reflected in the Eirene manual, values of NFILEL larger than 5 no longer refer to the files in XDR format, but rather to whether a “short” or “long” format will be used for the fort.13 file in Eirene stand-alone runs. When running SOLPS-ITER in coupled mode, the BGK virtual species background is always written in the “short” format, and this is enforced by the code. However, for Eirene stand-alone runs, values of NFILEL smaller than 5 expect the “long” format, which is incompatible. Thus, for consistent treatment between coupled and stand-alone runs, values of NFILEL larger than 5 are recommended. In addition, the best value (mod 5) to use is 3, since this will ensure that the virtual background will be read at the beginning of the first call to Eirene, while, for NFILEL = 4 (mod 5), this is only written at the end of the first Eirene call, leading to a subtle restart effect. Therefore, the recommended default for NFILEL is now 8.
• The thousands digit, NFILEK, is used for the fort.14 file, which, in SOLPS-ITER, is used to store the XMCT array, containing information relevant for load balancing between MPI processes when the BALANCED parallelization strategy (the recommended default when using MPI version 3 or above) is invoked. This is done when NFILEK = 4 (read-only) or 5 (read and write) (unfortunately, again not reflected yet in the Eirene manual). Uinp assumes an MPI run, so proposes a NFILEK = 5 default value, while the DivGeo default had NFILEK = 0 (now changed to match the Uinp value). If you are not running with the BALANCED MPI parallelization strategy, you can set NFILEK = 0.
• The myriads digit, NFILEJ, is used for the fort.15 file. This file contains data related to the “census” array, defined in block 13 of the Eirene input file and needed for time-dependent runs. Recall that the presence of a census stratum is governed by the number of associated trajectories, NPRNLI, set in DivGeo (also in the “Global Eirene data” dialog box). If you do not want a census stratum, set that value to 0 in DivGeo when building your case. If NPRNLI <> 0, then Uinp will have NFILEJ = 3 as its default, to ensure the census stratum data are both written and read on each Eirene call, avoiding restart effects.

Therefore, for productions runs, i.e. runs with neutral-neutral collisions, MPI load-balancing, and a census stratum, the recommended (default) value for NFILE is 35800.

Controlling the amount of output produced by a SOLPS-ITER run

In extreme cases, the amount of output produced by a SOLPS-ITER run can become prohibitively large and cause problems to the file system. To avoid this, here are some tips on how you can minimize the output file size and/or I/O load of your runs:

• In coupled runs, set the unit digit of the NFILE variable in the Eirene input.dat file to 0. This avoids the production and writing, on every Eirene call, of the (often quite large) binary fort.10 and fort.11 files, which are only needed for some Eirene internal diagnostics.
• During long production runs, avoid setting the b2wdat_iout switch (and other b2xxxx_iout switches) to a non-zero value, since this (especially when b2wdat_iout is set to 4) can create a very large number of diagnostic files, accessed at least once per B2.5 iteration. If you are indeed wanting to diagnose a run, only run it for a few timesteps to obtain a snapshot you can analyze in full detail. For long time-dependent runs, the b2wdat_iout.eq.2 setting is the most appropriate if really necessary.
• The code, by default, will output back the contents of the namelists it read. Depending on your compiler, the format for this may be very cumbersome. You can turn off this output, for each namelist, by setting the WRITE_NML_XXXX variable in that namelist to .FALSE. (most likely people may want to set WRITE_NML_BND to .FALSE.).
• The frequency at which the tallies are written to the log file is governed by the b2mndr_tally switch. The higher its value, the less frequent the output. Setting that switch to 0 suppresses the tally output altogether.
• Similarly, the NetCDF tracing files are appended to at frequencies governed by the b2mndr_b2time (for b2time.nc), b2mndt_av_ntim_batch (for b2batch.nc), tallies_netcdf (for b2tallies.nc), and b2wall_netcdf (for b2wall.nc). Writing of the balance.nc file is controlled by the balance_netcdf switch. Again, the output is suppressed if those switches are set to 0.
• The tracing files in the tracing/ directory are appended every ank_tracing B2.5 iterations, and will not be written if ank_tracing is set to 0.
• Eirene has its own set of tracing output switches, which are specified in block 11 of the Eirene input file, and described in the Eirene manual.