Skip to content

KiLCA overwrites input profiles #102

@zandivx

Description

@zandivx

QL-Balance modifies the input profile files in ./profiles/ during execution. This is important to understand when preparing runfolders or debugging unexpected profile changes.

What Happens

During time evolution (and other run types), QL-Balance:

  1. Reads profile data from ./profiles/*.dat files
  2. Interpolates profiles onto its internal computational grid
  3. Writes the resampled profiles back to ./profiles/*.dat

The affected files are:

  • n.dat (density)
  • Te.dat (electron temperature)
  • Ti.dat (ion temperature)
  • Vz.dat (toroidal velocity)
  • Vth.dat (poloidal velocity)
  • Er.dat (radial electric field)
  • q.dat (safety factor)

Note: Da.dat (anomalous diffusion coefficient) is not overwritten.

Technical Details

Code Location

The profile overwriting occurs in:

src/base/wave_code_data_64bit.f90:187-237

subroutine update_background_files(path)
    ...
    integer :: flag = 1;  ! always keep flag =1, since KiLCA reads profiles from ./profile directory
    ...
    open (20, file=trim(path)//'n.dat');
    open (30, file=trim(path)//'Te.dat');
    ! ... etc for all profile files
    do k = 1, dim_r
        write (20, *) r(k), n(k);
        write (30, *) r(k), Te(k);
        ! ... etc
    end do

Call Chain

  1. time_evolution.f90 calls get_dql()
  2. get_dql.f90:137 calls update_background_files(path2profs) when irf == 1
  3. path2profs defaults to './profiles/'

The irf flag is set to 1 after the first initialization call, so profiles are overwritten on every subsequent get_dql call during time evolution.

Grid Resampling

The internal grid is determined by:

  • rmin and rmax from balance_conf.nml
  • npoimin (minimum number of grid points)
  • Grid spacing: (rmax - rmin) / (npoimin + 1)

This means:

  • If you change rmax in the config, the output profiles will have a different radial extent
  • The number of grid points may change
  • Profile values are interpolated to the new grid

Practical Implications

Example Scenario

  1. You have profiles extending from 3 to 67 cm with 11,314 points
  2. You change rmax from 67 to 61 in balance_conf.nml
  3. You run ./ql-balance
  4. Your profile files now extend from 3 to 61 cm with ~12,173 points

The profiles are permanently modified!

Recommendations

  1. Keep backups: Always keep a backup of your original profile files before running QL-Balance
  2. Use separate directories: Consider keeping master profiles in a separate location and copying them to the runfolder before each run
  3. Version control: Track profile files in git if they are generated/processed data
  4. Be aware when debugging: If profiles look different after a run, this is expected behavior

Why This Exists

The comment in the code states:

! always keep flag =1, since KiLCA reads profiles from ./profile directory

This suggests the feature exists to ensure KiLCA (which may be called during the run) has access to profiles on the same grid that QL-Balance uses internally.

See Also

  • src/base/wave_code_data_64bit.f90 - Profile I/O implementation
  • src/base/get_dql.f90 - Where update_background_files is called
  • src/base/gengrid.f90 - Grid generation logic

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions