@delta-infra/cli 1.1.18 → 1.1.21
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +507 -513
- package/checksums.txt +5 -5
- package/package.json +3 -2
- package/scripts/install-wizard.js +689 -701
- package/scripts/install.js +442 -442
- package/scripts/run.js +65 -65
- package/skills/delta-protein/AGENTS.md +73 -0
- package/skills/delta-protein/SKILL.md +389 -0
- package/skills/delta-protein/agents/openai.yaml +4 -0
- package/skills/delta-protein/references/bfitter.md +64 -0
- package/skills/delta-protein/references/catapro_predict.md +63 -0
- package/skills/delta-protein/references/catpred_predict.md +65 -0
- package/skills/delta-protein/references/caver_tunnel_analyze.md +63 -0
- package/skills/delta-protein/references/consensus_mutation.md +61 -0
- package/skills/delta-protein/references/consurf_predict.md +67 -0
- package/skills/delta-protein/references/crop_sequence.md +69 -0
- package/skills/delta-protein/references/dock.md +82 -0
- package/skills/delta-protein/references/dock_score.md +70 -0
- package/skills/delta-protein/references/easifa_predict_active_site.md +70 -0
- package/skills/delta-protein/references/ephod_predict_mutation.md +66 -0
- package/skills/delta-protein/references/ephod_predict_protein.md +61 -0
- package/skills/delta-protein/references/esmfold2_predict.md +67 -0
- package/skills/delta-protein/references/evcouplings_mutation.md +64 -0
- package/skills/delta-protein/references/fasta_to_sequence.md +59 -0
- package/skills/delta-protein/references/foldseek.md +61 -0
- package/skills/delta-protein/references/generate_msa.md +61 -0
- package/skills/delta-protein/references/interpro_analyze.md +63 -0
- package/skills/delta-protein/references/mpnn_design_sequence.md +71 -0
- package/skills/delta-protein/references/multievolve.md +73 -0
- package/skills/delta-protein/references/pisa_query.md +70 -0
- package/skills/delta-protein/references/plip_analyze.md +65 -0
- package/skills/delta-protein/references/pocket_prediction.md +63 -0
- package/skills/delta-protein/references/protein_design.md +65 -0
- package/skills/delta-protein/references/protein_evolution.md +77 -0
- package/skills/delta-protein/references/protein_sol_predict_mutation.md +66 -0
- package/skills/delta-protein/references/protein_sol_predict_protein.md +61 -0
- package/skills/delta-protein/references/protenix.md +66 -0
- package/skills/delta-protein/references/protrek_search.md +90 -0
- package/skills/delta-protein/references/pubchem_search.md +68 -0
- package/skills/delta-protein/references/pubmed_search.md +79 -0
- package/skills/delta-protein/references/reap_design_primer.md +69 -0
- package/skills/delta-protein/references/rfd3_design.md +65 -0
- package/skills/delta-protein/references/structure_to_sequence.md +61 -0
- package/skills/delta-protein/references/summarize_result.md +68 -0
- package/skills/delta-protein/references/surface_charge.md +84 -0
- package/skills/delta-protein/references/uniprot_batch_query.md +63 -0
- package/skills/delta-protein/references/uniprot_query.md +64 -0
- package/skills/delta-protein/references/zero_shot_mutant_candidates.md +76 -0
- package/skills/delta-protein/scripts/gen_references.py +167 -0
- package/skills/delta-protein/scripts/output_metadata.json +275 -0
- package/skills/delta-sandbox/SKILL.md +388 -388
- package/skills/delta-sandbox/agents/openai.yaml +4 -4
- package/skills/delta-sandbox/references/commands.md +58 -58
- package/skills/delta-sandbox/references/lifecycle.md +100 -100
- package/skills/delta-sandbox/references/recipes.md +138 -138
- package/skills/delta-science/AGENTS.md +47 -47
- package/skills/delta-science/SKILL.md +227 -227
- package/skills/delta-science/agents/openai.yaml +4 -4
- package/skills/delta-science/references/antbo.md +105 -105
- package/skills/delta-science/references/delta-bo.md +92 -92
- package/skills/delta-science/references/gsasii.md +118 -118
- package/skills/delta-science/references/lammps.md +68 -68
- package/skills/delta-science/references/ldm-bo.md +132 -132
- package/skills/delta-science/references/materials-design.md +130 -130
- package/skills/delta-science/references/pubchem.md +128 -128
- package/skills/delta-science/references/pymatgen.md +69 -69
- package/skills/delta-science/references/qe.md +134 -134
- package/skills/delta-science/references/rdkit.md +141 -141
- package/skills/delta-science/references/strbo.md +95 -95
- package/skills/delta-science/references/synbo.md +201 -201
- package/skills/delta-science/references/xrd.md +688 -197
- package/skills/delta-science/scripts/catalog.py +92 -92
- package/skills/delta-science/scripts/generated_catalog.py +69 -69
- package/skills/delta-science/scripts/invoke.py +346 -346
- package/skills/delta-shared/SKILL.md +113 -113
- package/skills/delta-shared/agents/openai.yaml +4 -4
- package/skills/manifest.json +20 -19
|
@@ -1,68 +1,68 @@
|
|
|
1
|
-
# LAMMPS reference
|
|
2
|
-
|
|
3
|
-
Make all calls with `delta-cli science invoke`. LAMMPS does not infer data files, atom types,
|
|
4
|
-
potentials or boundary conditions from a formula, CIF or POSCAR. Successful execution does not
|
|
5
|
-
establish physical convergence or production readiness.
|
|
6
|
-
|
|
7
|
-
## Health
|
|
8
|
-
|
|
9
|
-
Operation: `health`; no request body.
|
|
10
|
-
|
|
11
|
-
Key response fields in `data`: `status`, `service`, `lammps_available`,
|
|
12
|
-
`metadata`, and `limits`.
|
|
13
|
-
|
|
14
|
-
Call this only when the user explicitly asks for a health check; do not add a health call automatically before simulation.
|
|
15
|
-
|
|
16
|
-
## Built-In Lennard-Jones Example
|
|
17
|
-
|
|
18
|
-
Operation: `lj-melt-example`.
|
|
19
|
-
|
|
20
|
-
Returns a complete `request` payload for the `run` operation, plus workflow notes
|
|
21
|
-
showing where pymatgen and GSAS-II fit around LAMMPS.
|
|
22
|
-
|
|
23
|
-
## Run
|
|
24
|
-
|
|
25
|
-
Operation: `run`.
|
|
26
|
-
|
|
27
|
-
```json
|
|
28
|
-
{
|
|
29
|
-
"input_script": "<LAMMPS input script>",
|
|
30
|
-
"files": [
|
|
31
|
-
{"path": "system.data", "content": "<LAMMPS data file text>", "encoding": "text"}
|
|
32
|
-
],
|
|
33
|
-
"timeout_seconds": 30,
|
|
34
|
-
"max_thermo_rows": 1000,
|
|
35
|
-
"log_tail_lines": 200,
|
|
36
|
-
"output_files": ["dump.lammpstrj", "final.data"],
|
|
37
|
-
"include_log": true,
|
|
38
|
-
"include_stdout": false,
|
|
39
|
-
"include_stderr": false
|
|
40
|
-
}
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
`files` are written into a fresh job working directory before LAMMPS starts.
|
|
44
|
-
`encoding` can be `text` or `base64`.
|
|
45
|
-
|
|
46
|
-
The response includes parsed thermo rows, the final thermo row, atom count when
|
|
47
|
-
detectable, log tail, warnings, and requested output files. Text output files
|
|
48
|
-
return `content`; binary output files return `content_base64`.
|
|
49
|
-
|
|
50
|
-
Notes:
|
|
51
|
-
|
|
52
|
-
- Use relative file paths only.
|
|
53
|
-
- The service rejects unsafe commands such as `shell`, `python`, `plugin`, and
|
|
54
|
-
`jump` by default.
|
|
55
|
-
- `include <relative-file>` is allowed when the included file is supplied in
|
|
56
|
-
`files`; absolute paths, parent-directory traversal, URLs, and `jump` loops
|
|
57
|
-
are rejected.
|
|
58
|
-
- Dump/data products are returned as raw requested output files, not structured
|
|
59
|
-
parsed atom-frame objects.
|
|
60
|
-
- The gateway is synchronous; keep interactive runs short.
|
|
61
|
-
- Force-field choice is caller responsibility. The service executes explicit
|
|
62
|
-
LAMMPS input and does not infer potentials from formulas or structures.
|
|
63
|
-
|
|
64
|
-
In the final reply, include only `last_thermo`, the final step/temperature/total energy,
|
|
65
|
-
warnings, and a summary of output files requested by the user from the current business response.
|
|
66
|
-
Do not divide total energy by the atom count, substitute steps, convert units, or infer
|
|
67
|
-
convergence or stability. For the minimal example, call `lj-melt-example` first, then pass its
|
|
68
|
-
`request` from the current business response to `run` unchanged; do not pass the outer CLI envelope.
|
|
1
|
+
# LAMMPS reference
|
|
2
|
+
|
|
3
|
+
Make all calls with `delta-cli science invoke`. LAMMPS does not infer data files, atom types,
|
|
4
|
+
potentials or boundary conditions from a formula, CIF or POSCAR. Successful execution does not
|
|
5
|
+
establish physical convergence or production readiness.
|
|
6
|
+
|
|
7
|
+
## Health
|
|
8
|
+
|
|
9
|
+
Operation: `health`; no request body.
|
|
10
|
+
|
|
11
|
+
Key response fields in `data`: `status`, `service`, `lammps_available`,
|
|
12
|
+
`metadata`, and `limits`.
|
|
13
|
+
|
|
14
|
+
Call this only when the user explicitly asks for a health check; do not add a health call automatically before simulation.
|
|
15
|
+
|
|
16
|
+
## Built-In Lennard-Jones Example
|
|
17
|
+
|
|
18
|
+
Operation: `lj-melt-example`.
|
|
19
|
+
|
|
20
|
+
Returns a complete `request` payload for the `run` operation, plus workflow notes
|
|
21
|
+
showing where pymatgen and GSAS-II fit around LAMMPS.
|
|
22
|
+
|
|
23
|
+
## Run
|
|
24
|
+
|
|
25
|
+
Operation: `run`.
|
|
26
|
+
|
|
27
|
+
```json
|
|
28
|
+
{
|
|
29
|
+
"input_script": "<LAMMPS input script>",
|
|
30
|
+
"files": [
|
|
31
|
+
{"path": "system.data", "content": "<LAMMPS data file text>", "encoding": "text"}
|
|
32
|
+
],
|
|
33
|
+
"timeout_seconds": 30,
|
|
34
|
+
"max_thermo_rows": 1000,
|
|
35
|
+
"log_tail_lines": 200,
|
|
36
|
+
"output_files": ["dump.lammpstrj", "final.data"],
|
|
37
|
+
"include_log": true,
|
|
38
|
+
"include_stdout": false,
|
|
39
|
+
"include_stderr": false
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
`files` are written into a fresh job working directory before LAMMPS starts.
|
|
44
|
+
`encoding` can be `text` or `base64`.
|
|
45
|
+
|
|
46
|
+
The response includes parsed thermo rows, the final thermo row, atom count when
|
|
47
|
+
detectable, log tail, warnings, and requested output files. Text output files
|
|
48
|
+
return `content`; binary output files return `content_base64`.
|
|
49
|
+
|
|
50
|
+
Notes:
|
|
51
|
+
|
|
52
|
+
- Use relative file paths only.
|
|
53
|
+
- The service rejects unsafe commands such as `shell`, `python`, `plugin`, and
|
|
54
|
+
`jump` by default.
|
|
55
|
+
- `include <relative-file>` is allowed when the included file is supplied in
|
|
56
|
+
`files`; absolute paths, parent-directory traversal, URLs, and `jump` loops
|
|
57
|
+
are rejected.
|
|
58
|
+
- Dump/data products are returned as raw requested output files, not structured
|
|
59
|
+
parsed atom-frame objects.
|
|
60
|
+
- The gateway is synchronous; keep interactive runs short.
|
|
61
|
+
- Force-field choice is caller responsibility. The service executes explicit
|
|
62
|
+
LAMMPS input and does not infer potentials from formulas or structures.
|
|
63
|
+
|
|
64
|
+
In the final reply, include only `last_thermo`, the final step/temperature/total energy,
|
|
65
|
+
warnings, and a summary of output files requested by the user from the current business response.
|
|
66
|
+
Do not divide total energy by the atom count, substitute steps, convert units, or infer
|
|
67
|
+
convergence or stability. For the minimal example, call `lj-melt-example` first, then pass its
|
|
68
|
+
`request` from the current business response to `run` unchanged; do not pass the outer CLI envelope.
|
|
@@ -1,132 +1,132 @@
|
|
|
1
|
-
# LDM-BO reference
|
|
2
|
-
|
|
3
|
-
Make all calls with `delta-cli science invoke`; do not use the local PDF2Dock runner. This tool is
|
|
4
|
-
for small-molecule SMILES only. Use the AntBO capability boundary for antibody, CDRH3 or AntBO
|
|
5
|
-
tasks. The server injects the provider, model paths and Vina/ReaSyn/GPU/LLM settings; do not put
|
|
6
|
-
them in the request JSON.
|
|
7
|
-
|
|
8
|
-
## Health
|
|
9
|
-
|
|
10
|
-
Operation: `health`; no request body.
|
|
11
|
-
|
|
12
|
-
The response reports whether the adapter can see the mounted PDF2Dock
|
|
13
|
-
interpreter, `bo_api.py`, Vina binary, ReaSyn repo/interpreter/checkpoints, NN
|
|
14
|
-
model files, cache directory, GPU settings, and LLM configuration. Missing LLM
|
|
15
|
-
settings degrade health because LDM methods need them.
|
|
16
|
-
|
|
17
|
-
## One-Step Recommend
|
|
18
|
-
|
|
19
|
-
Operation: `recommend`.
|
|
20
|
-
|
|
21
|
-
Wraps `bo_api.recommend_next_smiles`.
|
|
22
|
-
|
|
23
|
-
Typical payload:
|
|
24
|
-
|
|
25
|
-
```json
|
|
26
|
-
{
|
|
27
|
-
"method": "bo-tanimoto",
|
|
28
|
-
"pool": ["CCO", "CCN", "CCC"],
|
|
29
|
-
"history": [
|
|
30
|
-
{"smiles": "CCO", "scores": [-7.1]},
|
|
31
|
-
{"smiles": "CCN", "scores": [-6.8]}
|
|
32
|
-
],
|
|
33
|
-
"batch_size": 1
|
|
34
|
-
}
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
Typical business response inside the documented gateway `data`:
|
|
38
|
-
|
|
39
|
-
```json
|
|
40
|
-
{
|
|
41
|
-
"recommendations": ["CCC"],
|
|
42
|
-
"acquisition_values": [0.12],
|
|
43
|
-
"n_objectives": 1
|
|
44
|
-
}
|
|
45
|
-
```
|
|
46
|
-
|
|
47
|
-
LDM methods may include an `llm` diagnostics object.
|
|
48
|
-
|
|
49
|
-
Report `acquisition_values` exactly as returned in the business response. Unless the current
|
|
50
|
-
business response explicitly defines the field, do not describe it as predicted Vina, a predicted
|
|
51
|
-
objective, uncertainty, confidence or expected improvement, and do not infer whether higher or
|
|
52
|
-
lower is better. If the service provides no recommendation rationale, state “The service returned
|
|
53
|
-
no recommendation rationale”; do not add an explanation based on molecular scaffolds, heteroatoms
|
|
54
|
-
or model mechanisms.
|
|
55
|
-
|
|
56
|
-
## Full Trajectory
|
|
57
|
-
|
|
58
|
-
Operation: `trajectory`.
|
|
59
|
-
|
|
60
|
-
Wraps `bo_api.run_search_trajectory`.
|
|
61
|
-
|
|
62
|
-
Small smoke payload:
|
|
63
|
-
|
|
64
|
-
```json
|
|
65
|
-
{
|
|
66
|
-
"method": "bo-tanimoto",
|
|
67
|
-
"seed": 42,
|
|
68
|
-
"seed-smiles": "CCO,CCN,CCC",
|
|
69
|
-
"num-evaluations": 4,
|
|
70
|
-
"batch-size": 1,
|
|
71
|
-
"objective": "vina+nn"
|
|
72
|
-
}
|
|
73
|
-
```
|
|
74
|
-
|
|
75
|
-
Typical business response inside the documented gateway `data`:
|
|
76
|
-
|
|
77
|
-
```json
|
|
78
|
-
{
|
|
79
|
-
"config": {},
|
|
80
|
-
"history": [],
|
|
81
|
-
"summary": {}
|
|
82
|
-
}
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
LDM methods may include `llm_trajectory`.
|
|
86
|
-
|
|
87
|
-
## Error Handling
|
|
88
|
-
|
|
89
|
-
The service maps `bo_api` error JSON to an upstream failure. The gateway
|
|
90
|
-
returns a standard error envelope:
|
|
91
|
-
|
|
92
|
-
```json
|
|
93
|
-
{
|
|
94
|
-
"code": 1,
|
|
95
|
-
"message": "AutoDock Vina executable not found...",
|
|
96
|
-
"data": {
|
|
97
|
-
"endpoint": "/v1/trajectory",
|
|
98
|
-
"ldm_bo_response": {
|
|
99
|
-
"error": "...",
|
|
100
|
-
"error_type": "ValueError",
|
|
101
|
-
"traceback": "Traceback ..."
|
|
102
|
-
}
|
|
103
|
-
}
|
|
104
|
-
}
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
Common causes are missing Vina, missing ReaSyn, wrong Python interpreter, CUDA
|
|
108
|
-
device mismatch, missing LLM credentials for LDM methods, or an unwritable Vina
|
|
109
|
-
cache directory.
|
|
110
|
-
|
|
111
|
-
## Provider Settings
|
|
112
|
-
|
|
113
|
-
Do not send provider settings in request JSON. The adapter reads these from
|
|
114
|
-
deployment config and passes them as Python kwargs to `bo_api`:
|
|
115
|
-
|
|
116
|
-
```text
|
|
117
|
-
vina_bin
|
|
118
|
-
vina_cache_dir
|
|
119
|
-
vina_max_workers
|
|
120
|
-
gp_device
|
|
121
|
-
reasyn_repo
|
|
122
|
-
reasyn_python_bin
|
|
123
|
-
reasyn_model_path
|
|
124
|
-
reasyn_devices
|
|
125
|
-
nn_model_path
|
|
126
|
-
nn_metadata_path
|
|
127
|
-
llm_model
|
|
128
|
-
llm_base_url
|
|
129
|
-
llm_api_key
|
|
130
|
-
```
|
|
131
|
-
|
|
132
|
-
The CLI forwards the user payload; `bo_api` owns business defaults and schema behavior.
|
|
1
|
+
# LDM-BO reference
|
|
2
|
+
|
|
3
|
+
Make all calls with `delta-cli science invoke`; do not use the local PDF2Dock runner. This tool is
|
|
4
|
+
for small-molecule SMILES only. Use the AntBO capability boundary for antibody, CDRH3 or AntBO
|
|
5
|
+
tasks. The server injects the provider, model paths and Vina/ReaSyn/GPU/LLM settings; do not put
|
|
6
|
+
them in the request JSON.
|
|
7
|
+
|
|
8
|
+
## Health
|
|
9
|
+
|
|
10
|
+
Operation: `health`; no request body.
|
|
11
|
+
|
|
12
|
+
The response reports whether the adapter can see the mounted PDF2Dock
|
|
13
|
+
interpreter, `bo_api.py`, Vina binary, ReaSyn repo/interpreter/checkpoints, NN
|
|
14
|
+
model files, cache directory, GPU settings, and LLM configuration. Missing LLM
|
|
15
|
+
settings degrade health because LDM methods need them.
|
|
16
|
+
|
|
17
|
+
## One-Step Recommend
|
|
18
|
+
|
|
19
|
+
Operation: `recommend`.
|
|
20
|
+
|
|
21
|
+
Wraps `bo_api.recommend_next_smiles`.
|
|
22
|
+
|
|
23
|
+
Typical payload:
|
|
24
|
+
|
|
25
|
+
```json
|
|
26
|
+
{
|
|
27
|
+
"method": "bo-tanimoto",
|
|
28
|
+
"pool": ["CCO", "CCN", "CCC"],
|
|
29
|
+
"history": [
|
|
30
|
+
{"smiles": "CCO", "scores": [-7.1]},
|
|
31
|
+
{"smiles": "CCN", "scores": [-6.8]}
|
|
32
|
+
],
|
|
33
|
+
"batch_size": 1
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Typical business response inside the documented gateway `data`:
|
|
38
|
+
|
|
39
|
+
```json
|
|
40
|
+
{
|
|
41
|
+
"recommendations": ["CCC"],
|
|
42
|
+
"acquisition_values": [0.12],
|
|
43
|
+
"n_objectives": 1
|
|
44
|
+
}
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
LDM methods may include an `llm` diagnostics object.
|
|
48
|
+
|
|
49
|
+
Report `acquisition_values` exactly as returned in the business response. Unless the current
|
|
50
|
+
business response explicitly defines the field, do not describe it as predicted Vina, a predicted
|
|
51
|
+
objective, uncertainty, confidence or expected improvement, and do not infer whether higher or
|
|
52
|
+
lower is better. If the service provides no recommendation rationale, state “The service returned
|
|
53
|
+
no recommendation rationale”; do not add an explanation based on molecular scaffolds, heteroatoms
|
|
54
|
+
or model mechanisms.
|
|
55
|
+
|
|
56
|
+
## Full Trajectory
|
|
57
|
+
|
|
58
|
+
Operation: `trajectory`.
|
|
59
|
+
|
|
60
|
+
Wraps `bo_api.run_search_trajectory`.
|
|
61
|
+
|
|
62
|
+
Small smoke payload:
|
|
63
|
+
|
|
64
|
+
```json
|
|
65
|
+
{
|
|
66
|
+
"method": "bo-tanimoto",
|
|
67
|
+
"seed": 42,
|
|
68
|
+
"seed-smiles": "CCO,CCN,CCC",
|
|
69
|
+
"num-evaluations": 4,
|
|
70
|
+
"batch-size": 1,
|
|
71
|
+
"objective": "vina+nn"
|
|
72
|
+
}
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
Typical business response inside the documented gateway `data`:
|
|
76
|
+
|
|
77
|
+
```json
|
|
78
|
+
{
|
|
79
|
+
"config": {},
|
|
80
|
+
"history": [],
|
|
81
|
+
"summary": {}
|
|
82
|
+
}
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
LDM methods may include `llm_trajectory`.
|
|
86
|
+
|
|
87
|
+
## Error Handling
|
|
88
|
+
|
|
89
|
+
The service maps `bo_api` error JSON to an upstream failure. The gateway
|
|
90
|
+
returns a standard error envelope:
|
|
91
|
+
|
|
92
|
+
```json
|
|
93
|
+
{
|
|
94
|
+
"code": 1,
|
|
95
|
+
"message": "AutoDock Vina executable not found...",
|
|
96
|
+
"data": {
|
|
97
|
+
"endpoint": "/v1/trajectory",
|
|
98
|
+
"ldm_bo_response": {
|
|
99
|
+
"error": "...",
|
|
100
|
+
"error_type": "ValueError",
|
|
101
|
+
"traceback": "Traceback ..."
|
|
102
|
+
}
|
|
103
|
+
}
|
|
104
|
+
}
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Common causes are missing Vina, missing ReaSyn, wrong Python interpreter, CUDA
|
|
108
|
+
device mismatch, missing LLM credentials for LDM methods, or an unwritable Vina
|
|
109
|
+
cache directory.
|
|
110
|
+
|
|
111
|
+
## Provider Settings
|
|
112
|
+
|
|
113
|
+
Do not send provider settings in request JSON. The adapter reads these from
|
|
114
|
+
deployment config and passes them as Python kwargs to `bo_api`:
|
|
115
|
+
|
|
116
|
+
```text
|
|
117
|
+
vina_bin
|
|
118
|
+
vina_cache_dir
|
|
119
|
+
vina_max_workers
|
|
120
|
+
gp_device
|
|
121
|
+
reasyn_repo
|
|
122
|
+
reasyn_python_bin
|
|
123
|
+
reasyn_model_path
|
|
124
|
+
reasyn_devices
|
|
125
|
+
nn_model_path
|
|
126
|
+
nn_metadata_path
|
|
127
|
+
llm_model
|
|
128
|
+
llm_base_url
|
|
129
|
+
llm_api_key
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
The CLI forwards the user payload; `bo_api` owns business defaults and schema behavior.
|
|
@@ -1,130 +1,130 @@
|
|
|
1
|
-
# Materials Design reference
|
|
2
|
-
|
|
3
|
-
Materials Design builds surrogate models from experimental or computational materials tables,
|
|
4
|
-
validates models, defines feasible candidate spaces, and ranks candidates with uncertainty
|
|
5
|
-
estimates. Recommendations are hypotheses to validate, not confirmed materials, synthesis routes
|
|
6
|
-
or experimental results.
|
|
7
|
-
|
|
8
|
-
The routing label for this reference is `materials-design`. Use the current output of
|
|
9
|
-
`delta-cli science list` and `delta-cli science endpoints list <tool>` as the authority for
|
|
10
|
-
`tools.name` and `tool_endpoints.name`. The Gateway paths below describe the service contract;
|
|
11
|
-
they are not URLs to construct or access directly.
|
|
12
|
-
|
|
13
|
-
## Service boundary
|
|
14
|
-
|
|
15
|
-
The service provides the following capabilities:
|
|
16
|
-
|
|
17
|
-
| Service path | Purpose | Result boundary |
|
|
18
|
-
| --- | --- | --- |
|
|
19
|
-
| `/chem/materials-design/health` | Gateway-to-service readiness check | `status`, dependency availability, limits |
|
|
20
|
-
| `/chem/materials-design/v1/capabilities` | Input formats, models, validation modes and limits | Capability catalogue |
|
|
21
|
-
| `/chem/materials-design/v1/jobs` | Upload training/candidate tables and create an asynchronous job | `202`, `job_id`, status and links |
|
|
22
|
-
| `/chem/materials-design/v1/jobs/{job_id}` | Read job status | `status`, `result_status`, result, warnings |
|
|
23
|
-
| `/chem/materials-design/v1/jobs/{job_id}/cancel` | Request cancellation | Cancellation request/final state |
|
|
24
|
-
| `/chem/materials-design/v1/jobs/{job_id}/artifacts` | List artifacts | name, size, media_type, SHA-256 |
|
|
25
|
-
| `/chem/materials-design/v1/jobs/{job_id}/artifacts/{path}` | Download one artifact | Raw report/JSON/CSV/figure bytes |
|
|
26
|
-
|
|
27
|
-
Route all JSON/query calls through:
|
|
28
|
-
|
|
29
|
-
```text
|
|
30
|
-
delta-cli science invoke --tool TOOL --endpoint ENDPOINT --data JSON
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
Submit training tables through the controlled file adapter:
|
|
34
|
-
|
|
35
|
-
```text
|
|
36
|
-
delta-cli science file invoke --tool materials-design --endpoint job-submit \
|
|
37
|
-
--file train.xlsx --candidate-file candidates.xlsx --data CONFIG_JSON
|
|
38
|
-
delta-cli science task submit --tool materials-design --operation job-status \
|
|
39
|
-
--input '{"job_id":"mdjob_..."}' --wait
|
|
40
|
-
delta-cli science file download --tool materials-design --endpoint artifact-download \
|
|
41
|
-
--params '{"job_id":"mdjob_...","artifact_path":"report.html"}' --output report.html
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
Use `--params JSON` only for read-only query operations. If a new tool is absent from the
|
|
45
|
-
catalogue, or the catalogue does not return enough request-schema detail, stop and report that it
|
|
46
|
-
is not exposed. Do not guess endpoint names, bodies or compatibility aliases.
|
|
47
|
-
|
|
48
|
-
## CLI capability boundaries
|
|
49
|
-
|
|
50
|
-
The raw service request for `POST /v1/jobs` is `multipart/form-data` and contains at least:
|
|
51
|
-
|
|
52
|
-
```text
|
|
53
|
-
file=<training table>
|
|
54
|
-
candidate_file=<optional candidate table>
|
|
55
|
-
config=<serialized JSON object>
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
`science invoke` accepts only a JSON object body and JSON query parameters; it cannot express
|
|
59
|
-
multipart data. Do not disguise a local path or base64 as a file field. Artifact downloads are
|
|
60
|
-
also raw bytes: save and verify them with `science file download`, and do not treat them as
|
|
61
|
-
ordinary JSON results. Do not call `materials-design-service:8900` or connect directly to the
|
|
62
|
-
preflight Gateway.
|
|
63
|
-
|
|
64
|
-
## Inputs and configuration
|
|
65
|
-
|
|
66
|
-
Before modelling, confirm:
|
|
67
|
-
|
|
68
|
-
- `feature_columns`, `controllable_columns`, `target_column` or `objectives`;
|
|
69
|
-
- identifier, metadata, leakage, post-measurement and group/time columns, and their units;
|
|
70
|
-
- objective direction, feasibility constraints, candidate table or candidate-generation rules;
|
|
71
|
-
- missing values, duplicate samples, measurement conditions, data sources and validation split strategy.
|
|
72
|
-
|
|
73
|
-
Core fields for a single-objective configuration:
|
|
74
|
-
|
|
75
|
-
```json
|
|
76
|
-
{
|
|
77
|
-
"feature_columns": ["Bi", "In", "Ti"],
|
|
78
|
-
"controllable_columns": ["Bi", "In", "Ti"],
|
|
79
|
-
"identifier_columns": ["sample_id"],
|
|
80
|
-
"target_column": "T",
|
|
81
|
-
"target_direction": "maximize",
|
|
82
|
-
"validation": {"strategy": "kfold", "n_splits": 5},
|
|
83
|
-
"model_names": ["ExtraTrees", "GPR", "Ridge"],
|
|
84
|
-
"random_state": 42,
|
|
85
|
-
"recommendation_count": 10
|
|
86
|
-
}
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
For multiple objectives, use `objectives: [{"target_column": "...", "direction": "maximize|minimize"}]`
|
|
90
|
-
and explicit Pareto/EHVI settings. Prefer the user's `candidate_file`. If the service generates
|
|
91
|
-
candidates from observed ranges, explicitly preserve steps, hard constraints, composition
|
|
92
|
-
closure, `max_candidates` and `allow_extrapolation`. Do not optimise identifier, post-measurement
|
|
93
|
-
or leakage columns, or out-of-domain points without authorisation. Do not extrapolate arbitrarily
|
|
94
|
-
to fill the candidate count.
|
|
95
|
-
|
|
96
|
-
## Results handling
|
|
97
|
-
|
|
98
|
-
Assess job `status` and `result_status` separately:
|
|
99
|
-
|
|
100
|
-
- `status`: `pending`, `running`, `completed`, `failed` or `cancelled`;
|
|
101
|
-
- `result_status`: `complete`, `exploratory`, `readiness_only` or `failed`.
|
|
102
|
-
|
|
103
|
-
`202` means only that the service accepted or queued the job; it does not mean model training is
|
|
104
|
-
complete. `completed` does not mean the ranking is reliable. Say that the data and validation
|
|
105
|
-
support candidate ranking only when `result_status` is `complete`. Treat `exploratory` only as a
|
|
106
|
-
learning hypothesis; for `readiness_only`, read the readiness information and request missing
|
|
107
|
-
inputs; report `failed` as returned. Always preserve the returned validation, ranking, warnings
|
|
108
|
-
and error.
|
|
109
|
-
|
|
110
|
-
Keep predictions distinct from observations and cross-validation predictions. At minimum, report
|
|
111
|
-
data coverage, the split, model comparisons, uncertainty calibration, candidate feasibility,
|
|
112
|
-
in-domain/out-of-domain status, EI/PI/UCB or Pareto settings, and the plan for experimental
|
|
113
|
-
validation. Do not present model variance as experimental error or candidate predictions as
|
|
114
|
-
measured values.
|
|
115
|
-
|
|
116
|
-
## Artifacts and errors
|
|
117
|
-
|
|
118
|
-
Read artifacts only when the user asks for them or the workflow requires them. Verify downloaded
|
|
119
|
-
content against the `size`, `media_type` and SHA-256 returned by the listing; do not infer formats
|
|
120
|
-
from filenames. The service may produce `report.html`, `result.json`,
|
|
121
|
-
`data_dictionary.json`, `model_comparison.csv`, OOF/residual/calibration files,
|
|
122
|
-
`search_space.json`, `candidate_predictions.csv`, `shortlist.csv`, `recommendation_views.csv`,
|
|
123
|
-
`pareto_front.csv` and `figures/*`.
|
|
124
|
-
|
|
125
|
-
Common terminal conditions include configuration/file-format errors, a missing target or
|
|
126
|
-
candidate space, upload/row/candidate-count limits being exceeded, an unready backend, or a
|
|
127
|
-
missing job or artifact. Do not retry blindly after a submission timeout or disconnection: a
|
|
128
|
-
multipart upload may already have created a job, so first check whether a `job_id` was returned.
|
|
129
|
-
Do not replace a failure or empty recommendation with local regression, GP, random numbers or a
|
|
130
|
-
manual ranking.
|
|
1
|
+
# Materials Design reference
|
|
2
|
+
|
|
3
|
+
Materials Design builds surrogate models from experimental or computational materials tables,
|
|
4
|
+
validates models, defines feasible candidate spaces, and ranks candidates with uncertainty
|
|
5
|
+
estimates. Recommendations are hypotheses to validate, not confirmed materials, synthesis routes
|
|
6
|
+
or experimental results.
|
|
7
|
+
|
|
8
|
+
The routing label for this reference is `materials-design`. Use the current output of
|
|
9
|
+
`delta-cli science list` and `delta-cli science endpoints list <tool>` as the authority for
|
|
10
|
+
`tools.name` and `tool_endpoints.name`. The Gateway paths below describe the service contract;
|
|
11
|
+
they are not URLs to construct or access directly.
|
|
12
|
+
|
|
13
|
+
## Service boundary
|
|
14
|
+
|
|
15
|
+
The service provides the following capabilities:
|
|
16
|
+
|
|
17
|
+
| Service path | Purpose | Result boundary |
|
|
18
|
+
| --- | --- | --- |
|
|
19
|
+
| `/chem/materials-design/health` | Gateway-to-service readiness check | `status`, dependency availability, limits |
|
|
20
|
+
| `/chem/materials-design/v1/capabilities` | Input formats, models, validation modes and limits | Capability catalogue |
|
|
21
|
+
| `/chem/materials-design/v1/jobs` | Upload training/candidate tables and create an asynchronous job | `202`, `job_id`, status and links |
|
|
22
|
+
| `/chem/materials-design/v1/jobs/{job_id}` | Read job status | `status`, `result_status`, result, warnings |
|
|
23
|
+
| `/chem/materials-design/v1/jobs/{job_id}/cancel` | Request cancellation | Cancellation request/final state |
|
|
24
|
+
| `/chem/materials-design/v1/jobs/{job_id}/artifacts` | List artifacts | name, size, media_type, SHA-256 |
|
|
25
|
+
| `/chem/materials-design/v1/jobs/{job_id}/artifacts/{path}` | Download one artifact | Raw report/JSON/CSV/figure bytes |
|
|
26
|
+
|
|
27
|
+
Route all JSON/query calls through:
|
|
28
|
+
|
|
29
|
+
```text
|
|
30
|
+
delta-cli science invoke --tool TOOL --endpoint ENDPOINT --data JSON
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Submit training tables through the controlled file adapter:
|
|
34
|
+
|
|
35
|
+
```text
|
|
36
|
+
delta-cli science file invoke --tool materials-design --endpoint job-submit \
|
|
37
|
+
--file train.xlsx --candidate-file candidates.xlsx --data CONFIG_JSON
|
|
38
|
+
delta-cli science task submit --tool materials-design --operation job-status \
|
|
39
|
+
--input '{"job_id":"mdjob_..."}' --wait
|
|
40
|
+
delta-cli science file download --tool materials-design --endpoint artifact-download \
|
|
41
|
+
--params '{"job_id":"mdjob_...","artifact_path":"report.html"}' --output report.html
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Use `--params JSON` only for read-only query operations. If a new tool is absent from the
|
|
45
|
+
catalogue, or the catalogue does not return enough request-schema detail, stop and report that it
|
|
46
|
+
is not exposed. Do not guess endpoint names, bodies or compatibility aliases.
|
|
47
|
+
|
|
48
|
+
## CLI capability boundaries
|
|
49
|
+
|
|
50
|
+
The raw service request for `POST /v1/jobs` is `multipart/form-data` and contains at least:
|
|
51
|
+
|
|
52
|
+
```text
|
|
53
|
+
file=<training table>
|
|
54
|
+
candidate_file=<optional candidate table>
|
|
55
|
+
config=<serialized JSON object>
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
`science invoke` accepts only a JSON object body and JSON query parameters; it cannot express
|
|
59
|
+
multipart data. Do not disguise a local path or base64 as a file field. Artifact downloads are
|
|
60
|
+
also raw bytes: save and verify them with `science file download`, and do not treat them as
|
|
61
|
+
ordinary JSON results. Do not call `materials-design-service:8900` or connect directly to the
|
|
62
|
+
preflight Gateway.
|
|
63
|
+
|
|
64
|
+
## Inputs and configuration
|
|
65
|
+
|
|
66
|
+
Before modelling, confirm:
|
|
67
|
+
|
|
68
|
+
- `feature_columns`, `controllable_columns`, `target_column` or `objectives`;
|
|
69
|
+
- identifier, metadata, leakage, post-measurement and group/time columns, and their units;
|
|
70
|
+
- objective direction, feasibility constraints, candidate table or candidate-generation rules;
|
|
71
|
+
- missing values, duplicate samples, measurement conditions, data sources and validation split strategy.
|
|
72
|
+
|
|
73
|
+
Core fields for a single-objective configuration:
|
|
74
|
+
|
|
75
|
+
```json
|
|
76
|
+
{
|
|
77
|
+
"feature_columns": ["Bi", "In", "Ti"],
|
|
78
|
+
"controllable_columns": ["Bi", "In", "Ti"],
|
|
79
|
+
"identifier_columns": ["sample_id"],
|
|
80
|
+
"target_column": "T",
|
|
81
|
+
"target_direction": "maximize",
|
|
82
|
+
"validation": {"strategy": "kfold", "n_splits": 5},
|
|
83
|
+
"model_names": ["ExtraTrees", "GPR", "Ridge"],
|
|
84
|
+
"random_state": 42,
|
|
85
|
+
"recommendation_count": 10
|
|
86
|
+
}
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
For multiple objectives, use `objectives: [{"target_column": "...", "direction": "maximize|minimize"}]`
|
|
90
|
+
and explicit Pareto/EHVI settings. Prefer the user's `candidate_file`. If the service generates
|
|
91
|
+
candidates from observed ranges, explicitly preserve steps, hard constraints, composition
|
|
92
|
+
closure, `max_candidates` and `allow_extrapolation`. Do not optimise identifier, post-measurement
|
|
93
|
+
or leakage columns, or out-of-domain points without authorisation. Do not extrapolate arbitrarily
|
|
94
|
+
to fill the candidate count.
|
|
95
|
+
|
|
96
|
+
## Results handling
|
|
97
|
+
|
|
98
|
+
Assess job `status` and `result_status` separately:
|
|
99
|
+
|
|
100
|
+
- `status`: `pending`, `running`, `completed`, `failed` or `cancelled`;
|
|
101
|
+
- `result_status`: `complete`, `exploratory`, `readiness_only` or `failed`.
|
|
102
|
+
|
|
103
|
+
`202` means only that the service accepted or queued the job; it does not mean model training is
|
|
104
|
+
complete. `completed` does not mean the ranking is reliable. Say that the data and validation
|
|
105
|
+
support candidate ranking only when `result_status` is `complete`. Treat `exploratory` only as a
|
|
106
|
+
learning hypothesis; for `readiness_only`, read the readiness information and request missing
|
|
107
|
+
inputs; report `failed` as returned. Always preserve the returned validation, ranking, warnings
|
|
108
|
+
and error.
|
|
109
|
+
|
|
110
|
+
Keep predictions distinct from observations and cross-validation predictions. At minimum, report
|
|
111
|
+
data coverage, the split, model comparisons, uncertainty calibration, candidate feasibility,
|
|
112
|
+
in-domain/out-of-domain status, EI/PI/UCB or Pareto settings, and the plan for experimental
|
|
113
|
+
validation. Do not present model variance as experimental error or candidate predictions as
|
|
114
|
+
measured values.
|
|
115
|
+
|
|
116
|
+
## Artifacts and errors
|
|
117
|
+
|
|
118
|
+
Read artifacts only when the user asks for them or the workflow requires them. Verify downloaded
|
|
119
|
+
content against the `size`, `media_type` and SHA-256 returned by the listing; do not infer formats
|
|
120
|
+
from filenames. The service may produce `report.html`, `result.json`,
|
|
121
|
+
`data_dictionary.json`, `model_comparison.csv`, OOF/residual/calibration files,
|
|
122
|
+
`search_space.json`, `candidate_predictions.csv`, `shortlist.csv`, `recommendation_views.csv`,
|
|
123
|
+
`pareto_front.csv` and `figures/*`.
|
|
124
|
+
|
|
125
|
+
Common terminal conditions include configuration/file-format errors, a missing target or
|
|
126
|
+
candidate space, upload/row/candidate-count limits being exceeded, an unready backend, or a
|
|
127
|
+
missing job or artifact. Do not retry blindly after a submission timeout or disconnection: a
|
|
128
|
+
multipart upload may already have created a job, so first check whether a `job_id` was returned.
|
|
129
|
+
Do not replace a failure or empty recommendation with local regression, GP, random numbers or a
|
|
130
|
+
manual ranking.
|