Refinement Tutorial
Before you start: AmberTools for every case, Gaussian 16 for Cases 2 and 3
Every case needs AmberTools on PATH; Case 1 needs nothing else. Cases 2 and 3 also need Gaussian 16 — g16 and its formchk utility — which evaluates the ESP for the RESP charges and runs the QM reference. Check before the first run: type tleap antechamber g16 formchk must not report not found (Case 1 needs only the first two).
MAPLE does not check for Gaussian at launch; it looks for g16 only when the first Gaussian job starts, so a missing g16 stops Case 2 or 3 partway through. Each Gaussian job requests qm_nproc=8 cores and qm_mem=24 GB by default; set lower values in the sidecar config on a smaller machine (see the hub’s General Settings). The hub’s Requirements and QM Reference sections explain when each program is needed.
Overview
This tutorial walks through the Refinement route of parmfit(method=refinement) in four runs on o-iodophenol (choi001), a FreeSolv hydration-benchmark solute, supplied as the GAFF2 (General AMBER Force Field)-typed choi001_gaff2.mol2, already assigned abcg2 charges by antechamber. Case 1 refines bonded terms and torsions with every default; Case 2 derives RESP (restrained electrostatic potential) charges and adds a Gaussian reference; Case 3 walks the TorsionFit QM (quantum-mechanical) modes 2 and 3 (Refine3, Refine4). The iodine also raises one detail that light molecules never encounter: Gaussian's built-in Merz–Kollman radius table has no fifth-row entries, and you will see exactly how ParmFit supplies them. Every excerpt below is taken from verified runs of the inputs shown here (Refine1–4.inp plus their sidecar configs).
Every run writes a <base>.parmfitrun.in file next to the output that echoes your configuration with defaults filled in; use it to confirm the keys ParmFit actually read, and watch the log for Unknown left-hand warnings, which flag keys that no builder consumed. The reference definition of every key lives in the Refinement manual page and the shared sections of the ParmFit hub; software and input requirements are summarized in the hub's Requirements section.
Example Files
Follow the cases below and save the files you need from their links, or download the complete run archive, including every _work/ directory, from Zenodo: 10.5281/zenodo.23126271. It has one zip per case — Case1.zip (30 KB), Case2.zip (62 MB), and Case3.zip (1.7 GB; Refine3 and Refine4) — and each unpacks to a folder of the same name. The NCAA and MetalAA archives use the same zip names, so keep each tutorial in its own folder. To rerun a case, start from its input files in a new folder: inside an unpacked archive folder, TorsionFit would read the archived scans instead of running its own scan (see the hub’s Scan Reuse).
Case 1 — The basic input: bonded refinement
Goal. Refine the bonded terms and torsions of a small molecule provided as a GAFF2-typed mol2, keeping its original charges. This is entirely default behavior: chg_fit=none, bonded=mseminario, torsionfit=true.
Input. The inline coordinates are the working geometry; the mol2 file supplies topology, atom types, and charges, and the single key is set in the sidecar. The coordinate block and the mol2 must list the same atoms in the same order, hydrogens included: MAPLE checks only that the atom counts match and then pairs atoms by position, so it cannot reconcile two files whose atom orders differ. The coordinate values themselves need not match the mol2. The header declares the route with method=refinement:
No typed mol2 at hand?
This tutorial ships choi001_gaff2.mol2, but mol2= is optional: omit it and ParmFit writes the inline coordinates to <base>_work/ante.pdb, types them with antechamber -at gaff2 into <base>_work/<base>_ff.mol2 (residue LIG), and fills the charge column with zero placeholders — chg_fit then defaults to abcg2, so the final charges still come from the charge stage rather than the placeholders.
#model=uma(size=uma-s-1p1,task=omol)
#parmfit(method=refinement,input=Refine1.in)
#device=gpu0
I 3.54000000 1.42000000 0.00000000
C 3.55600000 1.47900000 -2.08800000
C 4.63400000 0.90600000 -2.76200000
H 5.45500000 0.43700000 -2.22200000
C 4.67700000 0.92700000 -4.15700000
H 5.51600000 0.48000000 -4.68200000
C 3.64100000 1.52200000 -4.87700000
H 3.67400000 1.53800000 -5.96300000
C 2.56300000 2.09500000 -4.20400000
H 1.76000000 2.55700000 -4.77200000
C 2.52000000 2.07400000 -2.80900000
O 1.44800000 2.64500000 -2.18900000
H 1.53600000 2.56400000 -1.22800000Refine1.in
# Refinement route settings; declare method=refinement in #parmfit(...) and reference this file via input=
# Only non-default entries are listed; the generated parmfitrun.in shows every resolved value.
mol2=choi001_gaff2.mol2Run. In the folder that holds Refine1.inp, Refine1.in, and choi001_gaff2.mol2:
maple Refine1.inp Refine1.out # or simply: maple Refine1.inpThe second argument names the log; without it, MAPLE derives the log name from the input, so both forms write Refine1.out. The run also writes the resolved configuration Refine1.parmfitrun.in and the work directory Refine1_work/. A run has finished normally when the result block reads Status: completed and the log ends with a TOTAL RUN TIME line; on the tutorial hardware Case 1 takes about 22 s.
What happens.
- Initial parameters.
parmchk2 -s gaff2 -a YbuildsRefine1_work/Refine1_original.frcmodfrom the input mol2. - Optimization. The MLIP (machine-learned interatomic potential; LBFGS) relaxes the inline coordinates.
- Bonded refinement. An MLIP Cartesian Hessian feeds mSeminario, which updates the bonded terms — including the GAFF2
i-cabond to the iodine, whose force constant is revised substantially (see the table below). - Charges. With
chg_fit=none, the charges of the input mol2 are kept unchanged; nochargefit/directory is created. - TorsionFit. Auto-selection finds exactly one rotatable torsion — the exocyclic phenol C–O bond
(11, 12), whose rotation swings the hydroxyl over the ortho-iodine; ring torsions are excluded. This bond is scanned a full circle every 10° by default and fitted in two stages. - Export. Amber mol2/frcmod/tleap input and GROMACS top/gro files are written.
The resolved configuration. Next to Refine1.out, MAPLE writes Refine1.parmfitrun.in. For this case almost every entry is a filled-in default:
# parmfitrun.in - resolved parmfit configuration for method=refinement
# Generated by MAPLE parmfit; values are the user config entries with defaults filled in.
# This file is itself a valid parmfit config and can be referenced via input=.
# refinement run
# Site composition, charge source and general refinement settings
# input mol2 with GAFF2 atom types
mol2 = choi001_gaff2.mol2
# (mseminario, seminario, none)
bonded = mseminario
# frequency scaling for Seminario constants
vib_scale = 1.0
# QM reference
# QM reference geometry and Hessian jobs
# run QM reference geometry and Hessian jobs
iqm = false
# (g16, g09, gaussian, orca)
qm_engine = g16
... (open the real file after a run to see every resolved key)Reading the output. The setup header confirms what was consumed — check the QM reference and torsion lines before reading anything else:
======================================================================
Parmfit Refinement Setup
======================================================================
Input mol2: choi001_gaff2.mol2
Initial frcmod: Refine1_work/Refine1_original.frcmod
Topology atoms: 13
Topology bonds: 13
Bonded refinement: mSeminario
QM reference: disabled
QM compare: disabled
TorsionFit: enabled
Torsion backend: cgbs
Torsion constraint:projected
Torsion ensemble:false
Scan grid: 10.0000 deg x 36 steps
Stage2 refine: max_fast_cycles=3, max_iter_per_cycle=256, tol=1e-06
Torsion bonds: auto-select non-ring torsion bonds with proper torsions
Assigned terms:
bonds: 13 (unmatched: 0)
angles: 19 (unmatched: 0)
dihedrals: 26 (unmatched: 0)
impropers: 6 (unmatched: 0)
nonbonds: 13 (unmatched: 0)The stage trace shows the pipeline order. With chg_fit=none, ParmFit deliberately skips the charge-fitting stage:
[Refinement] initial parameter assignment ...
[Refinement] MLIP geometry optimization ...
[Refinement] MLIP Hessian + mSeminario ...
[Refinement] TorsionFit ...
[Refinement] export GROMACS ...
[Refinement] export Amber ...The mSeminario table lists only changed terms, with the old values on the left of | and the new values on the right — the iodine terms first:
(1,2) i-ca k=234.900000 r=2.129000 | k=135.307826 r=2.089184
(2,3) ca-ca k=461.100000 r=1.398000 | k=387.211126 r=1.386447
(1,2,3) i-ca-ca k=57.500000 theta=119.1100 | k=43.159181 theta=119.2977
(1,2,11) i-ca-ca k=57.500000 theta=119.1100 | k=42.841349 theta=119.8516
...The torsion energy trace ends with the number to watch — the MAE (mean absolute error)/RMSE (root-mean-square error) of the fitted profile against the MLIP reference. The rotor profile shows two planar wells (one over the iodine side) separated by twin perpendicular barriers of nearly 6 kcal/mol:
Torsion energy trace:
torsion bond (11, 12):
scan xyz: Refine1_work/torsionfit/Refine1_torsionfit_11-12_scan_final.xyz
angle_deg MLIP_ref orig_ref stage0_ref stage1_ref stage2_ref
359.9226 0.000000 0.000000 0.000000 0.000000 0.000000
369.9226 0.159524 0.185740 0.198823 0.154343 0.159719
389.9226 1.331669 1.618097 1.693869 1.273449 1.316369
419.9226 3.992471 5.133502 5.326029 3.919965 3.982378
459.9226 5.892447 8.307398 8.560909 5.939417 5.911643
539.9226 3.331109 7.509462 7.699650 3.483694 3.367189
...
MLIP_ref vs stage2_final: MAE = 0.016114 kcal/mol, RMSE = 0.019326 kcal/mol
MLIP_ref).Finally, the result block lists the products and the parameter-change counts:
======================================================================
PARMFIT REFINEMENT RESULT
======================================================================
Status: completed
Input mol2: choi001_gaff2.mol2
Main products:
Amber mol2: Refine1_work/Refine1_maple.mol2
Amber frcmod: Refine1_work/Refine1_maple.frcmod
GROMACS top: Refine1_work/Refine1_maple.top
GROMACS gro: Refine1_work/Refine1_maple.gro
Amber tleap: Refine1_work/Refine1_maple_tleap.in
Stage timing:
Hessian + mSeminario 7s
geometry optimization 2s
TorsionFit 0s
initial parameter assignment 0s
export Amber 0s
export GROMACS 0s
charge fitting 0s
Parameter changes:
bonded refinement: mSeminario
bonds changed by bonded refine: 13
angles changed by bonded refine: 19
dihedrals changed by TorsionFit: 2
other changes: none
TorsionFit:
state: enabled
torsion bonds: (11, 12)
scan files:
(11, 12): Refine1_work/torsionfit/Refine1_torsionfit_11-12_scan_final.xyz
stage1: completed
stage2: enabled, max_fast_cycles=3
fast cycles: executed=2, accepted=1, rejected=1
final parameters: Stage2 fast cycle 1
Warnings:
noneTorsionFit 0s is not the cost of the scan: this run found the scan file that an earlier run had left in Refine1_work/torsionfit/ and read it instead of running its own scan (see the hub’s Scan Reuse). A run from an empty folder performs the full scan.
The log closes with MAPLE’s reminder about the hydrogen-bond list of the Amber topology — printed on every Refinement run, because topologies written from MAPLE atom types must be normalized with ParmEd before SHAKE (see the manual’s ParmEd note). This run’s reminder reads:
======================================================================
IMPORTANT
======================================================================
Due to the limitations of custom atom types, the exported topology
must be normalized with ParmEd before use. tleap identifies hydrogens
by the leading character of the atom type, which MAPLE types do not
carry, so it writes an empty BONDS_INC_HYDROGEN section and SHAKE
(ntc=2) would constrain nothing. ParmEd rebuilds that section from
ATOMIC_NUMBER, e.g.:
tleap -f Refine1_maple_tleap.in
parmed -p Refine1_maple_gas.prmtop <<< $'outparm Refine1_maple_gas_parmed.prmtop\nquit'
======================================================================Case 2 — RESP charges and a QM geometry
What changed. The sidecar gains four keys. With chg_fit=resp, charges are derived at runtime — Gaussian evaluates the ESP (electrostatic potential), then AmberTools performs the two-stage RESP fit. With iqm=true and opt_level=B3LYP/def2SVP, the geometry and Hessian references move to Gaussian. With the default qm_mode=1, the torsion scan stays MLIP-driven, with a QM single point at each frame.
One level choice is iodine-specific: the classic RESP basis HF/6-31G(d) does not exist for iodine, so this case sets chg_level=HF/def2SVP — the def2 family carries iodine with its effective core potential. Note also the level spelling: with qm_engine=g16, write B3LYP/def2SVP without the hyphen — the engine-spelling rule is documented in the hub's Levels of Theory.
#model=uma(size=uma-s-1p1,task=omol)
#parmfit(method=refinement,input=Refine2.in)
#device=gpu0
I 3.54000000 1.42000000 0.00000000
C 3.55600000 1.47900000 -2.08800000
C 4.63400000 0.90600000 -2.76200000
H 5.45500000 0.43700000 -2.22200000
C 4.67700000 0.92700000 -4.15700000
H 5.51600000 0.48000000 -4.68200000
C 3.64100000 1.52200000 -4.87700000
H 3.67400000 1.53800000 -5.96300000
C 2.56300000 2.09500000 -4.20400000
H 1.76000000 2.55700000 -4.77200000
C 2.52000000 2.07400000 -2.80900000
O 1.44800000 2.64500000 -2.18900000
H 1.53600000 2.56400000 -1.22800000Refine2.in
# Refinement route settings; declare method=refinement in #parmfit(...) and reference this file via input=
# Only non-default entries are listed; the generated parmfitrun.in shows every resolved value.
mol2=choi001_gaff2.mol2
# Runtime charge derivation: Gaussian ESP + AmberTools two-stage RESP
# (def2SVP instead of the classic HF/6-31G(d): iodine has no 6-31G basis;
# the def2 family carries iodine with its ECP)
chg_fit=resp
chg_level=HF/def2SVP
# QM reference, qm_mode 1: MLIP drives the scan, QM single point per frame
iqm=true
opt_level=B3LYP/def2SVPRun. maple Refine2.inp Refine2.out, as in Case 1; on the tutorial hardware it takes about 7 min, and Refine2.parmfitrun.in shows the four new keys resolved against their defaults.
What happens. The MLIP pre-optimization still runs, then a QM opt+frequency job supersedes it as the reference geometry and Hessian source for mSeminario. Charge derivation runs regardless of the iqm setting — Gaussian supplies the ESP, AmberTools performs the RESP stages; the Gaussian jobs run with the configured qm_nproc/qm_mem.
The iodine radius detail. Open Refine2_work/chargefit/resp.gjf and the route line is not the plain Pop=MK you may know from light molecules:
#P HF/def2SVP Pop(MK,ReadRadii) IOp(6/33=2) SCF=Tight
... (molecule specification)
I 1.875Gaussian's built-in Merz–Kollman radius table stops well before the fifth row, and l602 aborts with GetVDW: no radius for atomic number 53 otherwise. ParmFit therefore writes Pop(MK,ReadRadii) and appends a radius line for every element the built-in table lacks — 1.875 Å for iodine, from its UFF van der Waals radius divided by 1.2. Light molecules never need this fallback; without it, a molecule containing iodine cannot run.
The setup header and stage trace in Refine2.out show the two new stages — the enabled QM reference and the charge-fitting step:
QM reference: enabled, mode=1, engine=g16, opt=B3LYP/def2SVP, sp=B3LYP/def2SVP
...
[Refinement] initial parameter assignment ...
[Refinement] MLIP geometry optimization ...
[Refinement] QM reference optimization ...
[Refinement] QM Hessian + mSeminario ...
[Refinement] atomic charge fitting ...
[Refinement] TorsionFit ...
[Refinement] Using QM reference data for TorsionFit (mode=1) ...
[Refinement] export GROMACS ...
[Refinement] export Amber ...The result block gains a Charge fitting: section:
Charge fitting:
method: resp
RESP level: HF/def2SVP
target charge: 0
actual charge: -0.00000000
work MOL2: Refine2_work/chargefit/qm_route_charged.mol2
final MOL2: Refine2_work/Refine2_maple.mol2
Stage timing:
TorsionFit 5m 23s
Hessian + mSeminario 1m 29s
charge fitting 4s
geometry optimization 2sThe torsion trace now references QM single points — the reference column becomes QM_ref and the scan file is prefixed qm_:
torsion bond (11, 12):
scan xyz: Refine2_work/torsionfit/Refine2_qm_torsionfit_11-12_scan_final.xyz
angle_deg QM_ref orig_ref stage0_ref stage1_ref stage2_ref
359.9837 0.000000 0.000000 0.000000 0.000000 0.000000
369.9837 0.208213 0.148268 0.159940 0.197624 0.197976
389.9837 1.623683 1.167627 1.280879 1.590847 1.591518
...
QM_ref vs stage2_final: MAE = 0.018492 kcal/mol, RMSE = 0.021605 kcal/molThe stage0/stage1/stage2 columns are the fitted MM (molecular-mechanics) profile after each fitting stage; what matters is that the last column tracks the QM reference over the whole profile; which stage ended up final does not matter here.
Checkpoint
Compare target charge: with actual charge: — Refinement never rescales fitted charges, so a mismatch is reported, not hidden (here 0 vs −0.00000000).
Case 3 — Relaxing each frame on the QM surface
What changed. The configuration lives in the external sidecar files referenced with input= — the method itself stays in the inline #parmfit(...) header. Case 2 kept the default qm_mode=1, in which QM single-points score the MLIP scan’s frames; this case makes the choice explicit, running Refinement with qm_mode=2 and qm_mode=3. The Refine4 header declares level=tight: mode 3 hands the frame relaxation to ParmFit’s own optimizer, and level is MAPLE’s global convergence tier, so the run raises that optimizer’s stopping criteria from the default medium tier to tight — the same depth g16’s own optimizer stops at.
Input.
#model=uma(size=uma-s-1p1,task=omol)
#parmfit(method=refinement,input=Refine3.in)
#device=gpu0
I 3.54000000 1.42000000 0.00000000
C 3.55600000 1.47900000 -2.08800000
C 4.63400000 0.90600000 -2.76200000
H 5.45500000 0.43700000 -2.22200000
C 4.67700000 0.92700000 -4.15700000
H 5.51600000 0.48000000 -4.68200000
C 3.64100000 1.52200000 -4.87700000
H 3.67400000 1.53800000 -5.96300000
C 2.56300000 2.09500000 -4.20400000
H 1.76000000 2.55700000 -4.77200000
C 2.52000000 2.07400000 -2.80900000
O 1.44800000 2.64500000 -2.18900000
H 1.53600000 2.56400000 -1.22800000External config. Paths such as mol2 are resolved relative to this file.
Refine3.in
# Refinement route settings; declare method=refinement in #parmfit(...) and reference this file via input=
# Only non-default entries are listed; the generated parmfitrun.in shows every resolved value.
mol2=choi001_gaff2.mol2
# Runtime charge derivation: Gaussian ESP + AmberTools two-stage RESP
# (def2SVP instead of the classic HF/6-31G(d): iodine has no 6-31G basis;
# the def2 family carries iodine with its ECP)
chg_fit=resp
chg_level=HF/def2SVP
# QM reference, qm_mode 2: MLIP pre-optimization, QM constrained opt per frame
iqm=true
qm_mode=2
opt_level=B3LYP/def2SVPRefine4 input. The convergence tier lives in the inline header:
#model=uma(size=uma-s-1p1,task=omol)
#parmfit(method=refinement,input=Refine4.in,level=tight)
#device=gpu0
I 3.54000000 1.42000000 0.00000000
C 3.55600000 1.47900000 -2.08800000
C 4.63400000 0.90600000 -2.76200000
H 5.45500000 0.43700000 -2.22200000
C 4.67700000 0.92700000 -4.15700000
H 5.51600000 0.48000000 -4.68200000
C 3.64100000 1.52200000 -4.87700000
H 3.67400000 1.53800000 -5.96300000
C 2.56300000 2.09500000 -4.20400000
H 1.76000000 2.55700000 -4.77200000
C 2.52000000 2.07400000 -2.80900000
O 1.44800000 2.64500000 -2.18900000
H 1.53600000 2.56400000 -1.22800000Keep method, input, and level in this header: the sidecar rejects method= and input=, and a level= written there is not applied — the log reports it only as an Unknown left-hand key. The reference run’s input, as archived on Zenodo, had a stray comma (input=Refine4.in,,level=tight); the copy on GitHub has it removed. MAPLE ignored that comma: it left only an unnamed : True line under Parsed configuration in Refine4.out.
The sidecar Refine4.in sets the same keys as Refine3.in except qm_mode=3:
Refine4.in
# Refinement route settings; declare method=refinement in #parmfit(...) and reference this file via input=
# Only non-default entries are listed; the generated parmfitrun.in shows every resolved value.
mol2=choi001_gaff2.mol2
# Runtime charge derivation: Gaussian ESP + AmberTools two-stage RESP
# (def2SVP instead of the classic HF/6-31G(d): iodine has no 6-31G basis;
# the def2 family carries iodine with its ECP)
chg_fit=resp
chg_level=HF/def2SVP
# QM reference, qm_mode 3: QM energy/forces with the ParmFit optimizer driving the scan
iqm=true
qm_mode=3
opt_level=B3LYP/def2SVPRun. maple Refine3.inp Refine3.out and maple Refine4.inp Refine4.out, as in Case 1; on the tutorial hardware they take about 28 min and 1 h 36 min, and their resolved configurations Refine3.parmfitrun.in and Refine4.parmfitrun.in differ only in qm_mode, 2 versus 3.
What happens. The charge and reference setup is identical to Case 2; only the way QM data enters TorsionFit changes. In mode 2, each scan frame comes from a QM constrained optimization of the torsion; in mode 3, the QM engine evaluates energies and forces directly and MAPLE's own optimizer drives the scan — see the hub's qm_mode table for the full semantics. The header and stage line always report the active mode — here from Refine3.out:
QM reference: enabled, mode=2, engine=g16, opt=B3LYP/def2SVP, sp=B3LYP/def2SVP
[Refinement] Using QM reference data for TorsionFit (mode=2) ...The three verified runs of this molecule compare like this:
Refine2 (mode 1) Refine3 (mode 2) Refine4 (mode 3)
scan xyz: Refine2_qm_torsionfit_11-12_scan_final.xyz
Refine3_qm_torsionfit_11-12_scan_final.xyz
Refine4_mode3_qm_torsionfit_11-12_scan_final.xyz
frame relaxation: MLIP scan (medium) g16 Opt (defaults) built-in opt (tight)
Gaussian outputs in _work: 39 39 1006
torsion MAE (kcal/mol): 0.018492 0.010873 0.025352
TOTAL RUN TIME: 7m 11s 27m 50s 1h 36m 13sThe three scans compared above are hosted alongside the inputs: Refine2_qm_torsionfit_11-12_scan_final.xyz, Refine3_qm_torsionfit_11-12_scan_final.xyz, and Refine4_mode3_qm_torsionfit_11-12_scan_final.xyz.
QM_ref), not UMA; GAFF2 (revUMA) still names the refitted GAFF2 set.The same B3LYP potential-energy surface and the same frozen dihedral underlie all three references — what differs is who relaxes each frame and where the relaxation stops. The rotor couples to the framework — the C–O bond breathes with conjugation, and the framework angles and the I···O contact absorb the steric load of the hydroxyl swinging past the iodine — so relaxed and unrelaxed frames are genuinely different geometries. Mode 1 scores the MLIP scan’s geometries as they are; modes 2 and 3 relax every frame on the QM surface, and with mode 3’s depth set by level=tight the two relaxed scans stop at the same depth. That is why the three profiles in Fig. 3 differ, and depth is what separates the run times in the table above.
The Gaussian-output totals in the table are job counts, not gradient-evaluation counts: mode 2 submits one Opt=ModRedundant constrained optimization per frame, while mode 3 submits one Force evaluation at a time as ParmFit’s optimizer steps from frame to frame — the tighter the level, the more evaluations.
Checkpoint
Pick the mode by what stands behind the reference and what it costs: mode 1 reuses the MLIP scan at single-point cost, mode 2 replaces each frame with a complete constrained QM optimization, mode 3 hands the scan steps to QM at single-force cost — raise its depth with level=tight as here, or accept the default medium tier and its shallower frames. Every product path above is relative to the run’s <base>_work/ directory.
Where to Go Next
Everything you need for MD is now in Refinen_work/: the Amber mol2 and frcmod (plus GROMACS files) carry the refined parameters. One deployment step remains, and Case 1 demonstrated it: run the exported tleap input, then pass the topology through ParmEd — MAPLE atom types leave tleap’s hydrogen-bond section empty, and SHAKE needs it rebuilt — before you take Refine1_maple_gas_parmed.prmtop into your simulation. The manual’s ParmEd note has the reference wording.
- Refinement manual — parameter reference, output files, and limits.
- ChargeFit, QM reference, and TorsionFit on the ParmFit hub — the stages these routes share, documented once on the hub.
- NCAA (noncanonical amino acid) tutorial and MetalAA tutorial — simple worked examples for the PDB (Protein Data Bank) routes.