-
Notifications
You must be signed in to change notification settings - Fork 21
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 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.
I am trying to model a linear device with a single target and the plasma flowing on the opposite side
Solution: The standard way to establish a single-target case is to run DivGeo like for a two targets case. For the side where the plasma comes in, you change the Target Specification Eirene switches to be a reflecting wall surface (or whatever else works for you there) and then you will modify the boundary condition in b2.boundary.parameters for that side from a sheath boundary condition to a plasma incoming flux (or whatever else you want).
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: This comes from an incompatibility between the GR/0.0.94 GKS implementation and the one from the GLI module.
Solution: We have found that linking to the GKS library from the a more modern GR implementation, such as GR/0.56.0 or GR/0.73.6, works. At ITER this means having lines like
setenv GKSDIR /work/imas/opt/EasyBuild/software/GR/0.73.6-GCCcore-13.2.0
setenv LD_LIBRARY_PATH ${GKSDIR}:${LD_LIBRARY_PATH}
in the $SOLPSTOP/SETUP/setup.csh.ITER.ifort64 file and defining:
LD_GKS = -L${GKSDIR}/lib -lGKS -lgfortran -lX11 -lXt
LIBGKS = ${GKSDIR}/lib/libGKS.so
in $SOLPSTOP/SETUP/config.ITER.ifort64.
This issue also affects Eirene stand-alone runs when asking for graphical output. It does not affect coupled runs that skip the Eirene graphics. The problem appeared when the GLI and GR modules were rebuilt with GCC/10.2.0.
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
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.
Problem: I am running a D+Ne case which, after some running apparently smooth, suddenly crashes. After some preliminary diagnostics, I see that the crash corresponds to a blowing-up of some tally traces, all more or less related to sources in the ion heat equation. Moreover, the problem seems to originate from the core region (it is a standard SN case). Some trial-and-error tests, told me that increasing the radial viscosity seems to lessen the problem.
Possible solutions:
- Switch on the Mach number limiters (
ion_vlct_restrictswitch). - Switch off the viscous heating terms (
b2sihs_phm2andb2sihs_phm8for viscous heating from poloidal and radial velocity gradients, respectively) - Increase the minimum density for the impurities ('b2mndr_na_min`) There is a known issue that, for cases with species with very low density (like the low ionization stages of heavy impurities near the core boundary of a hot plasma), their velocities, if not limited, can explode, and this will then appear as very large viscous heating terms in the ion heat equation, unless of course the viscous heating terms are turned off. We have found that this issue is mitigated if the densities of those rare species is not allowed to become too small.
Problem: I am working with a D only, fluid neutral run. I noticed that when I restart the run from its previous end state b2fstate, the residuals are a factor 100 higher than at the end of the previous run and require a few hundred iterations until they are back at the original level. Is this behaviour normal?
Cause: This is a side-effect of the level of accuracy with which the data in b2fstati/e are written. By default, it is to 8 significant digits. But there is a (hidden) switch to change that to more (or less) as you want.
Solution: The switch is hard-coded as ifmt=1 in cfwure.F. You can change it to ifmt=0 and see how the restart residual decreases after that (on the second cycle, after a new b2fstate file has been written and can be used as the new initial state with higher precision). An example of such a switch change can be found in the CI test script https://github.com/iterorganization/SOLPS-ITER/blob/703210201feed52981aa26251a3d9562c7a014dd/scripts/SOLPS-ITER_CI_test#L121 .
Cause: At least one of the velocity fields contains a cell where the absolute velocity is larger than the speed of light
If supra-luminal velocities occur when turning on drifts, even with very small multipliers, the problem is likely in your grid. Look near the core boundary, for the cells immediately next to the cut(s). These are often very narrow and the derivatives there can go crazy (because the denominators are too small) leading to erroneous values. I suggest running for a little bit, well before the error message appears, and then plotting along the innermost core ring, the values of the electron parallel velocity ue, to check for this. If you see a spike there, then consider rebuilding your grid with a larger pasmin value.