File size: 4,186 Bytes
818964a
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
# Optimization guide

LAMPSUI uses Optuna for parameter sweeps. The "Optimize" tab exposes the same
controls as `optuna.create_study` plus a UI for the search space.

## Picking a metric

The agent should match the user's goal to a thermo column + reduction:

| Goal | Metric | Reduce | Direction |
|------|--------|--------|-----------|
| "Find params where pressure converges to zero" | `Press` | `abs_last` | minimize |
| "Find the most stable parameter set" | `Press` | `stability` | minimize |
| "Find the highest mean pressure" | `Press` | `mean` | maximize |
| "Find params that minimize numerical noise in temperature" | `Temp` | `stability` | minimize |
| "Settle quickly" (proxy: low energy late in run) | `TotEng` | `last` | minimize |

`stability` = stdev of the second half of the trace. Useful when the run
has a transient + steady state and you want the steady state to be quiet.

## Picking a sampler

| Sampler | Use when |
|---------|----------|
| **TPE** (default) | 1 objective, ≤10 trials, mixed continuous/integer params |
| **Random** | Baseline / smoke testing |
| **CMA-ES** | 1 objective, all-continuous params, ≥30 trials |
| **NSGA-II** (default for multi-obj) | 2+ objectives, ≥20 trials |
| **NSGA-III** | 3+ objectives with structured reference points |

Constraints:
- NSGA-II/III require ≥2 objectives — submit will reject otherwise
- CMA-ES is single-objective only — submit will reject otherwise

## Picking a search space

For HF free tier, keep budgets small:

```json
{
  "dh":     {"type": "float", "low": 0.18, "high": 0.25, "step": 0.01},
  "sigmao": {"type": "float", "low": 0.5,  "high": 2.0}
}
```

with `n_trials=10`, `prodRun=1000` per trial → ~10–15 minutes total on free
tier.

For real research:

```json
{
  "dh":     {"type": "float", "low": 0.10, "high": 0.30, "log": true},
  "sigmao": {"type": "float", "low": 0.1,  "high": 5.0,  "log": true},
  "F":      {"type": "categorical", "choices": [1, 2, 3]}
}
```

with `n_trials=50–100`, `prodRun=20 000+` → run on a workstation overnight.

## Using `step` for discretization

If you want `prodRun` to stay on a coarse grid (cost varies linearly with it),
set `step=100` and `low=100, high=1000` — Optuna will only try
`{100, 200, …, 1000}`. Without step, it picks any integer.

For floats, `step=0.05` on `dh` means trials sample only `0.10, 0.15, 0.20…`.

## Multi-objective: typical pairs

| Pair | What it tells you |
|------|-------------------|
| `Press abs_last` ↓ + `Temp stability` ↓ | Find params with both small final pressure error AND low numerical noise |
| `prodRun` ↓ + `Press abs_last` ↓ | Cheap settings that still converge — Pareto front is the cost-quality trade-off |
| `Press mean` ↑ + `Press stability` ↓ | High mean pressure but quiet steady state |

The Pareto front in the UI shows the non-dominated trials. For 2 objectives
it renders as a scatter plot with grey dots = all trials and a blue dashed
line + dots = Pareto front.

## Reading the analysis report

Once a study has ≥3 completed trials, the bottom of the Optimize tab shows:

- **Parameter importance** (fANOVA): which knobs actually moved the
  objective. <5% means the parameter could be removed from the search.
- **Optimization history**: best-so-far per trial. Flat line late in the
  run = converged or stuck.
- **Correlations** (Pearson r): linear sensitivity. High |r| but low
  importance means the relationship is monotonic but the search didn't
  explore variation in that param.
- **Slice plots**: per-parameter scatter of objective vs that knob.
  Trends visible by eye.

A combination of low importance (<10%) and low |r| (<0.3) means the parameter
is essentially noise for the chosen objective — drop it from the search.

## When to start an optimization vs a single run

The agent should start a single run when:
- The user asks to verify behaviour at known parameters
- The user is debugging a setup
- Compute budget is tight (HF free tier)

The agent should start an optimization when:
- The user wants to find the best parameters
- The user is doing a sensitivity study
- The user mentions "sweep", "scan", "find the best", "trade-off"