The model’s training accuracy is 0. What should I do?

[li-shining]

My system is ɑ–Bi₂Mo₃O₁₂, a metal oxide. My current initial dataset consists of AIMD data at 1100 K and 725 K, including the bulk, surface and oxygen vacancies. Although the dataset is not yet complete, surely the model’s accuracy cannot be zero. Could it be that my parameter settings are incorrect? If I wish to train a Bi-Mo-O machine learning force field (which also includes the adsorption of oxygen molecules), how should I construct the corresponding initial dataset?

This is my param.json:

{
"type_map": ["O","Mo","Bi"],
"mass_map": [16,96,209],
"init_data_prefix": "/home/jmhan/gdata/DPGen/AN/DFT/PBE_D3/dataset",
"init_data_sys": ["bulk/725/training_data",
"bulk/1100/training_data",
"surface/surface_0/training_data",
"surface/surface_0.5/training_data",
"OV/ov1/training_data",
"OV/ov12/training_data",
"OV/ov5/training_data",
"OV/ov9/training_data"],
"seed":12345,
"lmp_cmd": "lmp -var seed 12345",
"init_batch_size": [1,1,1,1,1,1,1,1],
"sys_configs_prefix": "/home/jmhan/gdata/DPGen/AN/DFT/PBE_D3/dataset",
"sys_configs": [
["bulk/1100/extracted_poscars/POSCAR_",
"bulk/725/extracted_poscars/POSCAR_"],
["surface/surface_0/1100/extracted_poscars/POSCAR_",
"surface/surface_0/725/extracted_poscars/POSCAR_"],
["surface/surface_0.5/1100/extracted_poscars/POSCAR_",
"surface/surface_0.5/725/extracted_poscars/POSCAR_"],
["OV/ov1/1100/extracted_poscars/POSCAR_",
"OV/ov1/725/extracted_poscars/POSCAR_"],
["OV/ov12/1100/extracted_poscars/POSCAR_",
"OV/ov12/725/extracted_poscars/POSCAR_"],
["OV/ov5/1100/extracted_poscars/POSCAR_",
"OV/ov5/725/extracted_poscars/POSCAR_"],
["OV/ov9/1100/extracted_poscars/POSCAR_",
"OV/ov9/725/extracted_poscars/POSCAR_"]
],
"sys_batch_size": [1,1,1,1,1,1,1],
"_comment": " that's all ",
"numb_models": 4,
"train_backend":"pytorch",
"default_training_param": {
"model": {
"type_map": ["O","Mo","Bi"],
"descriptor": {
"type": "se_e2_a",
"sel": [34,10,8],
"rcut_smth": 0.5,
"rcut": 5.0,
"neuron": [25,50,100],
"resnet_dt": true,
"axis_neuron": 12,
"seed": 12345
},
"fitting_net": {
"neuron": [240,240,240],
"resnet_dt": false,
"seed": 12345
}
},
"learning_rate": {
"type": "exp",
"start_lr": 0.001,
"stop_lr": 1e-8,
"decay_steps": 5000
},
"loss": {
"start_pref_e": 0.02,
"limit_pref_e": 2,
"start_pref_f": 1000,
"limit_pref_f": 1,
"start_pref_v": 0.0,
"limit_pref_v": 0.0
},
"training": {
"seed":12345,
"stop_batch": 60000,
"disp_file": "lcurve.out",
"disp_freq": 1000,
"numb_test": 20,
"save_freq": 1000,
"save_ckpt": "model.ckpt",
"disp_training": true,
"time_training": true,
"profiling": false,
"profiling_file": "timeline.json",
"_comment": "that's all"
}
},
"model_devi_dt": 0.002,
"model_devi_skip": 0,
"model_devi_f_trust_lo": [0.06,0.08,0.08,0.10,0.10,0.10,0.10],
"model_devi_f_trust_hi": [0.18,0.25,0.25,0.30,0.30,0.30,0.30],
"model_devi_clean_traj": false,
"model_devi_jobs": [
{"sys_idx": [0],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "00"},
{"sys_idx": [1],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "01"},
{"sys_idx": [2],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "02"},
{"sys_idx": [3],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "03"},
{"sys_idx": [4],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "04"},
{"sys_idx": [5],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "05"},
{"sys_idx": [6],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "06"}

 ],
 "fp_style": "vasp",
 "shuffle_poscar": false,
 "fp_task_max": 50,
 "fp_task_min": 8,
 "fp_pp_path": "./",
 "fp_pp_files": ["POTCAR_O_s","POTCAR_Mo_pv","POTCAR_Bi_d"],
 "fp_incar": "./INCAR",
 "fp_kpoints": "./KPOINTS"

}

[dosubot[bot]]

Hi @li-shining! I'm Dosu and I’m helping the dpgen team.

Zero training accuracy typically indicates a data or type_map configuration issue rather than a model parameter problem. Here are the most likely causes and how to fix them:

Most Likely Causes:

1. Type_map mismatch - Verify your type_map: ["O","Mo","Bi"] exactly matches the atom types in your training data files. Mismatches between type_map and actual atom types are a leading cause of training failures.

2. Data quality issues - Check your dataset for:

   • Extreme force values (outside -222 to 222 eV/Å) or coordinates near 10⁻⁷–10⁻⁸ Å indicate DFT calculation errors
   • Empty data files or systems with no frames
   • Corrupted data format

3. Insufficient frames - Ensure your AIMD simulations produced enough frames for each system

For Constructing Your Bi-Mo-O + O₂ Adsorption Dataset:

Create three separate AIMD datasets:

• Bulk Bi-Mo-O phases
• Bulk O₂ molecules (gas phase)
• Interface configurations (surface + oxygen adsorption at various sites)

Additional tips:

• Skip initial equilibration frames (first ~50 steps) to avoid non-equilibrium configurations
• Do NOT fix atom positions during AIMD - this introduces artificial forces that harm training
• Each AIMD simulation should run ~1-2 ps, extracting 5-10 frames

Immediate Steps:

1. Inspect your lcurve.out file for any clues
2. Verify type_map matches your data exactly
3. Check for extreme values in forces/coordinates
4. Ensure data files aren't empty or corrupted

Your other parameters (sel, loss function, descriptor) look reasonable and are unlikely to cause zero accuracy.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

Good clarification — so all vacancy systems have the same number of atoms (one O removed from different positions), and the same amount of initial data. In that case, you shouldn't need to train them separately.

But the fact that ov1 works well while ov10/ov12/ov5 don't — despite identical data quantity and atom counts — suggests the local environments around different vacancy sites are very different. Some vacancy positions may create much more complex local chemistry than others.

Possible explanations:

1. Structurally different vacancy sites — In α-Bi₂Mo₃O₁₂, oxygen atoms can be bonded to Mo, Bi, or bridging between them. Removing an oxygen bridging Mo-O-Bi creates a very different local environment than removing a terminal Mo=O. The model finds some sites much harder to describe than others.

2. The exploration POSCARs matter — Your sys_configs for ov10/ov12/ov5 start MD from AIMD-extracted frames. If those starting configurations are already in unusual geometries (e.g., significant surface reconstruction around the vacancy), the MD quickly drifts into hard-to-learn territory.

Recommended approach:

1. Don't train separately — since they have the same composition, they should be combined. But widen trust levels more for this first iteration: trust_lo: 0.30, trust_hi: 0.60

2. Let DP-GEN iterate — The high candidate ratios (31-53%) for the struggling systems mean useful data IS being selected for DFT labeling. After a few iterations, the model should improve on those sites.

3. Check if the issue persists after 2-3 iterations — If ov10/ov12/ov5 still show >50% failed after incorporating labeled data, those specific vacancy sites may need more initial AIMD data at additional temperatures.

The key insight: not all vacancy sites are equally "easy" — the model will converge on different sites at different rates, which is normal for structurally diverse systems.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[li-shining]

@dosu, I modified trust_lo and trust_hi, but it doesn't seem to have solved the problem.
param.json:
"model_devi_f_trust_lo": [0.30,0.30,0.18,0.18,0.12,0.12,0.10,0.10],
"model_devi_f_trust_hi": [0.60,0.60,0.40,0.40,0.35,0.35,0.30,0.30],
"model_devi_clean_traj": false,
"model_devi_jobs": [
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "00"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "01"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "02"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "03"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "04"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "05"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "06"},
{"sys_idx": [0,2,4,6],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "07"}
dpgen.log:
INFO:dpgen:start running
INFO:dpgen:=============================iter.000000==============================
INFO:dpgen:-------------------------iter.000000 task 00--------------------------
INFO:dpgen:-------------------------iter.000000 task 01--------------------------
INFO:dpgen:-------------------------iter.000000 task 02--------------------------
INFO:dpgen:-------------------------iter.000000 task 03--------------------------
INFO:dpgen:-------------------------iter.000000 task 04--------------------------
INFO:dpgen:-------------------------iter.000000 task 05--------------------------
INFO:dpgen:-------------------------iter.000000 task 06--------------------------
INFO:dpgen:system 000 candidate : 126 in 410 30.73 %
INFO:dpgen:system 000 failed : 66 in 410 16.10 %
INFO:dpgen:system 000 accurate : 218 in 410 53.17 %
INFO:dpgen:system 000 accurate_ratio: 0.5317 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 100
INFO:dpgen:system 002 candidate : 148 in 410 36.10 %
INFO:dpgen:system 002 failed : 231 in 410 56.34 %
INFO:dpgen:system 002 accurate : 31 in 410 7.56 %
INFO:dpgen:system 002 accurate_ratio: 0.0756 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 100
INFO:dpgen:system 004 candidate : 162 in 410 39.51 %
INFO:dpgen:system 004 failed : 248 in 410 60.49 %
INFO:dpgen:system 004 accurate : 0 in 410 0.00 %
INFO:dpgen:system 004 accurate_ratio: 0.0000 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 100
INFO:dpgen:system 006 candidate : 218 in 410 53.17 %
INFO:dpgen:system 006 failed : 192 in 410 46.83 %
INFO:dpgen:system 006 accurate : 0 in 410 0.00 %
INFO:dpgen:system 006 accurate_ratio: 0.0000 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 100
INFO:dpgen:-------------------------iter.000000 task 07--------------------------

[dosubot[bot]]

I found your issue! Your trust level arrays are being applied incorrectly.

When model_devi_f_trust_lo is a list, each element corresponds to a sys_configs index (system), NOT to each iteration.

You have 8 sys_configs entries (indices 0-7), and your trust_lo array [0.30, 0.30, 0.18, 0.18, 0.12, 0.12, 0.10, 0.10] maps as:

sys_configs index	System	trust_lo	trust_hi
0	ov1/725	0.30	0.60
1	ov1/1100	0.30	0.60
2	ov10/725	0.18	0.40
3	ov10/1100	0.18	0.40
4	ov12/725	0.12	0.35
5	ov12/1100	0.12	0.35
6	ov5/725	0.10	0.30
7	ov5/1100	0.10	0.30

So systems 004 and 006 (ov12 and ov5) have extremely tight trust_lo of 0.12 and 0.10 — far below their force RMSE! That's why they show 0% accurate.

Fix: Set uniform wide trust levels for all systems first:

"model_devi_f_trust_lo": 0.30,
"model_devi_f_trust_hi": 0.60

Or if you want per-iteration tightening, specify them inside each model_devi_jobs entry instead.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[li-shining]

@dosu, I'm currently running dpgen for the adsorption part. The initial dataset includes oxygen atoms, oxygen adsorption on the surface, and some single-point data for oxygen atoms and molecules, but the results are very poor. How should I adjust it?
param.json:
"init_data_sys": ["o2_adsorption/surface/1100/merged_dataset/training_data",
"o2_adsorption/surface/725/merged_dataset/training_data",
"o_adsorption/surface/1100/merged_dataset/training_data",
"o_adsorption/surface/725/merged_dataset/training_data",
"O/training_data",
"O2/O2_pull_1_450/training_data",
"O2/O2_pull_2_450/training_data"],
"seed":12345,
"lmp_cmd": "lmp -var seed 12345",
"init_batch_size": ["auto","auto","auto","auto","auto","auto","auto"],
"sys_configs_prefix": "/home/jmhan/gdata/DPGen/AN/DFT/PBE_D3/dataset",
"sys_configs": [
["o2_adsorption/surface/725/merged_dataset/extracted_poscars_1/POSCAR_"],
["o2_adsorption/surface/725/merged_dataset/extracted_poscars_2/POSCAR_"],
["o_adsorption/surface/725/merged_dataset/extracted_poscars_1/POSCAR_"],
["o_adsorption/surface/725/merged_dataset/extracted_poscars_2/POSCAR_"]
"model_devi_jobs": [
{"sys_idx": [0,2],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "00"},
{"sys_idx": [0,2],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "01"},
{"sys_idx": [0,2],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "02"},
{"sys_idx": [0,2],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "03"},
{"sys_idx": [1,3],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "04"},
{"sys_idx": [1,3],"temps": [725],"trj_freq": 10,"nsteps": 400,"ensemble": "nvt","_idx": "05"},
{"sys_idx": [1,3],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "06"},
{"sys_idx": [1,3],"temps": [725],"trj_freq": 10,"nsteps": 600,"ensemble": "nvt","_idx": "07"}
dpgen.log:
2026-04-11 08:45:30,039 - INFO : start running
2026-04-11 08:45:30,046 - INFO : =============================iter.000000==============================
2026-04-11 08:45:30,046 - INFO : -------------------------iter.000000 task 00--------------------------
2026-04-11 08:45:30,179 - INFO : -------------------------iter.000000 task 01--------------------------
2026-04-11 14:41:18,674 - INFO : -------------------------iter.000000 task 02--------------------------
2026-04-11 14:41:18,677 - INFO : -------------------------iter.000000 task 03--------------------------
2026-04-11 14:41:18,898 - INFO : -------------------------iter.000000 task 04--------------------------
2026-04-11 14:44:25,990 - INFO : -------------------------iter.000000 task 05--------------------------
2026-04-11 14:44:25,991 - INFO : -------------------------iter.000000 task 06--------------------------
2026-04-11 14:44:26,016 - INFO : system 000 candidate : 246 in 410 60.00 %
2026-04-11 14:44:26,016 - INFO : system 000 failed : 163 in 410 39.76 %
2026-04-11 14:44:26,016 - INFO : system 000 accurate : 1 in 410 0.24 %
2026-04-11 14:44:26,023 - INFO : system 000 accurate_ratio: 0.0024 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 100
2026-04-11 14:44:26,195 - INFO : system 002 candidate : 59 in 410 14.39 %
2026-04-11 14:44:26,195 - INFO : system 002 failed : 351 in 410 85.61 %
2026-04-11 14:44:26,195 - INFO : system 002 accurate : 0 in 410 0.00 %
2026-04-11 14:44:26,200 - INFO : system 002 accurate_ratio: 0.0000 thresholds: 1.0000 and 1.0000 eff. task min and max -1 100 number of fp tasks: 59
2026-04-11 14:44:28,823 - INFO : -------------------------iter.000000 task 07--------------------------

[dosubot[bot]]

This is a challenging training scenario because you're mixing very different system types with vastly different sizes and chemistry. Let me identify the issues:

1. Huge composition diversity in init_data_sys

Your training data includes:

• Surface + O₂ adsorption (~70+ atoms)
• Surface + O adsorption (~70+ atoms)
• Single O atom (1 atom)
• O₂ molecule (2 atoms)

These have completely different numbers of atoms and very different physics. The tiny O and O₂ systems are fundamentally different from the surface systems, making it hard for the model to balance them.

2. Trust levels — same issue as before

You're using the default trust_lo: 0.15? With adsorption systems being inherently harder (reactive, under-coordinated atoms), you need wider trust levels:

"model_devi_f_trust_lo": 0.30,
"model_devi_f_trust_hi": 0.60

3. System 002 (o_adsorption) has 86% failed

Atomic oxygen on a surface is extremely reactive — forces are large and the model has high uncertainty. This needs more initial data and gentler exploration.

Recommended adjustments:

1. Widen trust levels to 0.30/0.60 as above

2. Include your bulk and clean surface data in init_data_sys — the model needs a stable foundation before learning adsorption. Add your converged bulk DP-GEN data and surface data.

3. Reduce nsteps for early iterations — start with nsteps: 200 instead of 400. Adsorption systems are unstable with an immature model; shorter trajectories prevent the MD from crashing into unphysical configurations.

4. Check lcurve.out — what's the force RMSE? With this many diverse systems, 90k steps may not be enough. Consider increasing stop_batch to 200k.

5. Consider training adsorption separately from isolated O/O₂ — The gas-phase molecules can be added to init_data_sys for training, but don't explore them with LAMMPS MD (which you're already doing correctly by only using sys_idx [0,2] and [1,3]).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.