Eirene Coupling

[akashukla]

Overview

In this PR we enable the coupling of Gkeyll to Eirene for neutral evolution. The model for including plasma sources in Gkeyll based on eirene output is described in DR #923 . Gkeyll evolves the plasma and Eirene evolves the neutrals (recycling, reactions, etc.). They exchange data through I/O every time Gkeyll outputs data.

This PR contains several parts. The first is the automatic installation of eirene and grid generation parts of SOLPS-ITER as part of the gkeyll mkdeps process. (This only occurs if one uses --build-solps=yes). The second part is the installation of a python library written by @jRoeltgen and me which does post-processing and interpolation routines to pass plasma information from gkeyll to eirene and plasma sources from eirene to gkeyll. The third is the code within Gkeyll itself that applies the sources.

Automatic installation of Eirene + SOLPS-ITER Grid generation

Without modifying the eirene codebase itself, one has to use an existing interface for grid generation and coupling. We are using the SOLPS-ITER (https://github.com/iterorganization/SOLPS-ITER ) interface. The scrip install-deps/build-solps.sh automatically installs the necessary parts SOLPS_ITER into gkylsoft/. This is only tested on perlmutter, as the SOLPS-ITER installation process can be difficult.

Automatic Installation of GK-Neutral_coupling

To actually pass information between Gkeyll and Eirene, post-processing and interpolation routines are required. This is taken care of by the GK-Neutral_coupling repo (https://github.com/jRoeltgen/GK-Neutral_coupling/tree/main) which contains examples and instructions for how to run coupled simulations.

Code Within Gkeyll

With guidance from @manauref, the additions to the code have been written in such a way that they interfere minimally with the rest of the gyrokinetic app. Most of the new code is in gyrokinetic/apps/eirene.c and gyrokinetic/apps/gk_species_source_bgk.c. The second file, gyrokinetic/apps/gk_species_source_bgk.c, has now replaced gk_species_heating.c and retains the old functionality while also adding the ability to apply sources from an external model (EIRENE). I also had to modify array_ops.c with a new function gkyl_array_ceil_range to apply limits on the temperature of the sources come from eirene to improve the stability of simulations.

Input Files

The input file interface is quite simple. You provide

  struct gkyl_gyrokinetic_eirene  eirene = {
    .input_data_path = "./gkeyll_text_input/",
    .output_data_path = "./gkeyll_text_output/",
    .num_coupling_species = 3,
    .coupling_species = {"elc", "ion", "molecule"},
    .coupling_time = {0.5e-3, 0.5e-3, 0.5e-4},
    .core_coll_factor = {75.0, 75.0, 7.5},
    .damping_factor= {2.0e-1, 2.0e-1, 8.0e-1},
    .half_domain = true,
  };

  struct gkyl_gyrokinetic_multib app_inp = {
    .name = "hstep26",

    .cdim = ctx.cdim,
    .poly_order = 1,
    .basis_type = app_args.basis_type,
    .use_gpu = app_args.use_gpu,
    .cfl_frac = 1.0,
    .cfl_frac_omegaH = 1.7*0.5 * 1.1,

    .gk_block_geom = bgeom,
    
    .num_species = 3,
    .species = { elc, ion, molecule},
    .eirene = eirene,


    .field = field,

    .comm = comm
  };

[Maxwell-Rosen]

Maybe I'm ignorant, but I don't know what this b67 (or b1011) means. So if I'm a gkeyll person who doesn't know EIRENE, can we have a more descriptive names for what makes these two files different? We can put a comment that this means the files end in b67, but the function name should make the purpose and operation clear.

[Maxwell-Rosen]

The convention us usually _source_M0.gkyl, so maybe we should keep that for these formats

[Maxwell-Rosen]

Please put braces around single line if statements and for loops

[Maxwell-Rosen]

changing this to mapc2p_int might be clearrer and more organized