Repository navigation
Problem solving tips
After I import the equilibrium (*.equ) and the single null (SN) topology, the separatrix doesn't appear, only the divertor legs
Cause: There is a second X-point somewhere in the topology and DivGeo can't deal with it.
Solution: Crop the equilibrium. This can be done in the following fashion:
cropequ path_to_input_file.equ path_to_output_file.equ
Press Enter and then input the number of cells in the R direction which are to be preserved, the corresponding Rmin and Rmax, and the same for the z direction. For instance:
126 0.3 0.8
201 -0.36 0.4
Import the new equilibrium into DivGeo and check if you've cut away the secondary X-point. If your secondary X-point is in an area which you can't crop away in this simple manner, or there is another problem, consider importing one of the double-null topologies.
If cropping the equilibrium file is not possible, or there is no additional X-point, and as a general rule, if the standard topology file does not produce the expected separatrix, one should try the other topology files available in the Import - Topology drop-down menu.
When I try to input a refined pasmin during carre -, it sets the pasmin to some strange value, like 10^-20
Cause: You may be using a bad form of input and Carre can't read the number.
Solution: Write pasmin=1.0e-4, not pasmin=1e-4. To correct an already written value, don't press Backspace but Ctrl+H to delete one character or Ctrl+U to clear the entire line.
Cause: It has too many wall elements compared to its tolerance limit.
Solution: Raise the tolerance limit. Go to $SOLPSTOP/modules/B2.5/src and from the folder include/, copy the file DIMENSIONS.F into the folder include.local/. Then, in this file, change the line
#define DEF_NLIM 300
...say, to 500. In most cases, Uinp will tell you how many walls your model is requiring. DivGeo can also tell you the numbers of wall elements it has in its model by selecting
Window - Statistics
After changing DEF_NLIM to the desired value, recompile SOLPS.
This error message also appears if Commands>Simplify>Merge/Split Elements is used to reduce the number of wall elements. The unused wall elements will appear in the statistics window (Window>Statistics) as "unused numbers". This can be easily fixed using:
Commands>Renumber Elements
When I perform a variable check, IU and OU targets appear as wrong, even though I'm using single null topology
Cause: You may have clicked Variables - Add - Extra targets for DN by accident.
Solution: Click Variables - Remove - Extra targets for DN.
Cause: The line that marks the edges for Eirene computation area actually intersects itself.
Solution: Look closely at the *.ps file Eirene draws - if there's a blue star in it, it may mark the place where the red line intersects itself. To check, plot the line in something that can zoom in, like gnuplot. In my case, this problem was initially caused when a part of the B2.5 mesh versions protruded outside of the tokamak chamber. (Note that tiny extra cells at the end of the mesh outside the chamber are normal, these are the ending, "ghost" cells. My protrusion was bigger and not limited to one cell per row. God knows how it happened.) The triangulation routine couldn't wrap its mind around having plasma outside of the chamber, and it produced a self-intersecting line. The catch was that I couldn't see the mesh error in my *.dg file, because since producing that faulty version of the mesh I had made changes to the *.dg file and produced a new mesh, which didn't have this problem. So what actually needed fixing was b2ag.dat file, which pointed to the earlier version of the mesh. Deleting this file AND fort.30 (where the same information is present, but for use by Eirene) allowed triang to update the mesh version link and finally resolve the issue.
If you are building the triang.eir file by hand, keep in mind that the list of wall index pairs (or single indices in case of limiter geometries) that are given at the end of the file to be matched to the grid corners must be given in order of increasing poloidal index as you travel along the grid.
Running b2run results in an error somewhere within Eirene, complaining about transparent edges in triangles
Cause: Actually, I had a deliberate error in the *.dg file. Its purpose had been to solve an earlier problem and I had forgotten to fix it. This error was that the region between two divertor targets had the TRIA-EIRENE parameter 0, not -2 as it should be.
Solution: Solving it was simple, I just had to set the parameter to -2, rerun triang and run b2run again. The difficult part was finding what the cause was, as the b2run error output complained about triangle no. 680 (among others) where I could only see triangles 1-678 in my Eirene files. Finally, Ray Chandra somehow extracted the position of the faulty triangles from the fort.33 and fort.34 files. He found that the triangles were located in the outermost layer of the triangulation grid, in the PFR. I assume that Eirene was unhappy that these triangles didn't lean against anything - there was no chamber or structure, just blank space.
All triangle edges in Eirene that are part of the outer contour of the grid must also be part of a "non-standard" surface. This is either a physical wall element or an absorbing surface. Otherwise, Eirene will return this error. The quickest way to find information about a particular triangle is to use the (I)nquire function inside the triang script, where you can input the triangle number and the script will return the location of the triangle vertices and its neighbors.
Cause: The file input.dat was the old version before I performed the triangulation fix described in the previous solved problem.
Solution: Make sure input.dat is up-to-date.
This can happen if the cells near the targets are very thin. One way to get out of the infinite loop is to enforce a stricter matching criterion for cell vertices. This is done by means of the b2agfs_geom_match_dist switch that can be added to the b2ag.dat file. Its default value is 1.0e-6. Choosing smaller values is likely to solve the problem.
The fluxes I see in b2plot are not the same as those I extract from the main code. What is happening?
In the main code, the fluxes are computed on cell faces (left and bottom sides). In b2plot, the fluxes are interpolated to cell centers, to facilitate their plotting with the same algorithm as other plasma quantities.
I am meshing a DDN-up topology and the triangulation fails. The tria.ps file shows strange lines crossing the plasma. What is wrong?
Independent of which X-point is active, in your DG model, for ALL double-null configurations, the ordering of the targets, when filling in the Target configuration table, should ALWAYS be:
Target 1: HFS-down Target 2: HFS-up Target 3: LFS-up Target 4: LFS-down
It is possible to coarsen the grid produced by Carre in one or both of the radial and poloidal directions, by means of the nx and ny numbers in the b2ag.dat file. However, sometimes you will get the following error message "Cell merging failed because of mismatched types", which means that the code was attempting to merge cells belonging to different topological regions of the grid, like a core and an SOL cell across the separatrix, for instance. Thus, to avoid this error, one must make sure that the coarsening is done using common divisors for the sizes of all grid regions. Remember that coarsening the B2.5 grid means you will also need to rebuild the associated triangular grids for Eirene (fort.33, fort.34, and fort.35), by means of triang script.
Use a top-level -j flag to run compilation in parallel across all submodules:
make -j $(nproc) solps
make -j 16 solps_openmpThis lets GNU make's jobserver share compile jobs across B2.5, Eirene, Carre, Uinp, etc. simultaneously. Typical speed-up on 32 cores: ~40% wall-clock reduction compared to the older MAKE_OPTIONS=-j8 approach.
Note: The older form make MAKE_OPTIONS=-j8 is still supported but only parallelises within each submodule — it does not share jobs across modules.
Cause: Triang's dependency file is generated by makedepend, which is a C-preprocessor-based tool that does not understand Fortran USE statements. In serial builds the natural source ordering happens to satisfy the module dependency chain, but under -jN the ordering is not guaranteed.
Solution: This is handled automatically as of the feature/parallel-build changes — the top-level Makefile forces Triang sub-makes to run with -j1. If you are on an older code version, either build Triang separately in serial first (make triang && make -j8 solps) or apply the fix from that branch.
Both setup.ksh (for bash/ksh) and setup.csh (for tcsh/csh) are fully supported. If your default shell is bash, there is no need to switch to tcsh:
cd $SOLPSTOP
source setup.ksh # uses default compiler
source setup.ksh gfortran # or specify a compilerThe helper scripts (b2run, itersubmit, triang, carre, divgeo, uinp, etc.) have tcsh shebangs but are invoked as external commands — they work regardless of the user's login shell.
When a CI test baserun tarball is extracted on a fast filesystem, the .dat input files and their derived outputs (e.g. b2fgmtry, b2fpardf) can end up with identical timestamps. GNU make may then decide to regenerate outputs (e.g. re-run b2ag), which fails because the Carre mesh file is not reachable from the CI test's search path.
Solution: The scripts/correct_baserun_timestamps script pre-ages the .dat input files by 10 seconds before touching the derived outputs, ensuring make considers them up to date. This fix is included in the feature/foss-intel-2025b branch.