Add missing entries to balance_conf.nml blueprint

[zandivx]

plus add commata at the end of lines where they were missing

[qodo-code-review]

Review Summary by Qodo

Fix balance_conf.nml blueprint with missing commas and parameters

🐞 Bug fix

Walkthroughs

Description

• Add missing commas to balance_conf.nml configuration entries
• Add five missing configuration parameters to blueprint
• Remove unnecessary blank line in balance_conf.py class

Diagram

flowchart LR
  A["balance_conf.nml<br/>incomplete entries"] -- "add missing commas" --> B["properly formatted<br/>configuration lines"]
  A -- "add missing parameters" --> C["complete parameter<br/>set"]
  D["balance_conf.py<br/>with blank line"] -- "remove blank line" --> E["clean class<br/>definition"]

Loading

File Changes

1. QL-Balance/namelists/balance_conf.nml 🐞 Bug fix +12/-7

Add missing commas and parameters to configuration

• Add trailing commas to seven configuration entries (type_of_run, wave_code, kim_config_path,
 kim_profiles_from_balance, kim_n_modes, kim_m_list, kim_n_list)
• Add five missing configuration parameters: I_par_toroidal, jpar_method, set_constant_time_step,
 constant_time_step, urelax

QL-Balance/namelists/balance_conf.nml

---

2. python/balance_interface/balance_conf.py Formatting +0/-1

Remove blank line in class definition

• Remove unnecessary blank line after class definition

python/balance_interface/balance_conf.py

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. Forces constant timestep 🐞 Bug ≡ Correctness

Description

balance_conf.nml now sets set_constant_time_step = .true., which makes TimeEvolution always use
constant_time_step and bypass the adaptive timestep calculation described for TimeEvolution runs.
With the blueprint’s constant_time_step = 0.5, the runtime will no longer respond to the computed
timstep_arr-based constraints and the timestep < stop_time_step stopping path becomes
ineffective for the default stop_time_step value.

Code

QL-Balance/namelists/balance_conf.nml[R66-67]

+ set_constant_time_step = .true. ,
+ constant_time_step = 0.5 ,

Evidence

The blueprint explicitly enables constant time stepping. In the Fortran implementation,
set_time_step uses adaptive logic only when set_constant_time_step is false; when true it
assigns timstep = constant_time_step. Separately, stop_if_time_step_too_small only stops when
timstep < stop_time_step, which cannot happen with the blueprint’s fixed timstep=0.5 and
stop_time_step=1e-06. This also conflicts with the repo documentation that characterizes
TimeEvolution as using adaptive stepping.

QL-Balance/namelists/balance_conf.nml[57-69]
QL-Balance/src/base/time_evolution.f90[778-800]
QL-Balance/src/base/time_evolution.f90[666-683]
Data.md[184-190]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`QL-Balance/namelists/balance_conf.nml` enables constant time stepping by default (`set_constant_time_step = .true.`), which bypasses the adaptive timestep logic used in TimeEvolution and contradicts the documented behavior.

### Issue Context
TimeEvolution’s timestep selection in `QL-Balance/src/base/time_evolution.f90` uses adaptive logic only when `set_constant_time_step` is false.

### Fix Focus Areas
- QL-Balance/namelists/balance_conf.nml[66-68]

### Proposed fix
- Change the blueprint default to `set_constant_time_step = .false.`.
- Keep `constant_time_step` present (so the variable is initialized) but only used when explicitly enabled.
- (Optional but recommended) Update docs to mention `set_constant_time_step` / `constant_time_step` if they are intended user-facing options.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more