- Welcome to iRASPA Community.
Recent posts
#1
General / Re: No VDW interaction for my ...
Last post by dubbelda - August 17, 2026, 07:09:24 PMThe warning is not that UFF/DREIDING/OPLS are incomplete. RASPA2 never matched your framework atoms to the types in the force field, so CO2 has no van der Waals interaction with the MOF. The results are not usable until this is fixed. Do not silence those pairs with "none".
RASPA2 takes the force-field type from _atom_site_label, not from _atom_site_type_symbol. Your CIF is:
Cu1 Cu ...
O1 O_MOF ...
C1 C_MOF ...
so the types RASPA actually uses are Cu1, O1, C1, C2, C3, H1. That is exactly what the warning prints (O_CO2-Cu1, O_CO2-O1, ...). The mixing-rule types Cu, C_MOF, O_MOF, H_MOF are never applied. Unknown CIF labels are added as new pseudo-atoms with no Lennard-Jones parameters (and, if UseChargesFromCIFFile is no, charge 0). Check the pseudo-atom table in the output: you will see Cu1, O1, C1 listed separately from Cu, O_MOF, C_MOF.
You do not need a unique charge on every atom of every MOF. For a typed UFF/DREIDING-style model, give each chemical type one epsilon, sigma, and charge in pseudo_atoms.def / force_field_mixing_rules.def, then make the CIF labels match those type names. UseChargesFromCIFFile no is the right choice if conversion to IL-modified structures is wiping _atom_site_charge.
Two practical ways to make the names match, depending on how you generate CIFs.
1. Keep C_MOF / O_MOF / H_MOF / Cu in the force field (good if you want MOF atoms distinct from CO2, water, and the IL). Rewrite the CIF labels to those names. Labels do not have to be unique:
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
Cu Cu 0.2853 0.2853 0.0000
O_MOF O 0.3166 0.2431 0.9478
C_MOF C 0.2968 0.2032 0.9313
H_MOF H 0.3802 0.2280 0.8802
Keep O_CO2 and C_CO2 only for the guest.
2. Better for many CoRE-style CIFs that already use Cu1, O1, C1, C2. Rename the framework types in the force field to Cu, O, C, H and put this in simulation.input:
RemoveAtomNumberCodeFromLabel yes
That maps Cu1 → Cu, O1 → O, C1/C2/C3 → C, H1 → H. Leave the guests as O_CO2 / C_CO2 so they do not collide with framework O and C. Do not use RemoveAtomNumberCodeFromLabel with types named O_MOF: O1 becomes O, which still will not match O_MOF.
After the names match, the warning should disappear for CO2–framework pairs. Framework–framework missing VDW (Cu–O, C–H, ...) is normal for a rigid framework and can be left undefined, or listed as none if you want a clean log.
Charges for high-throughput: one charge per type in pseudo_atoms.def is enough; you do not assign a charge per MOF. UseChargesFromCIFFile no. Make sure every framework type you actually use is in pseudo_atoms.def, otherwise RASPA adds it with charge 0. The CIF charges you showed (Cu 1.248, O −0.624, ...) are not the same as the pseudo_atoms.def values (Cu 0.836, O_MOF −0.834, C_MOF 0.417, H_MOF 0.417). Pick one consistent set. H_MOF = 0.417 looking identical to C_MOF is worth checking; that is not a typical DREIDING hydrogen charge.
Also fix the mixing-rules header. RASPA2 expects:
# general rule for shifted vs truncated
shifted no
# general rule tailcorrections
no
not the word "truncated" on its own.
Once types match, confirm in the output that (1) the warning is gone for O_CO2/C_CO2 vs Cu/C/O/H, (2) the framework net charge is what you expect, and (3) Movies/System_0/Framework_0_initial_P1.cif has the charges you intended. Mixing UFF/DREIDING (framework), OPLS (IL), and TraPPE-style CO2 is then a force-field choice: Lorentz–Berthelot will run, but Cu-BTC open-metal-site CO2 uptake is often still low with generic Cu parameters. That is a separate issue from this warning.
RASPA2 takes the force-field type from _atom_site_label, not from _atom_site_type_symbol. Your CIF is:
Cu1 Cu ...
O1 O_MOF ...
C1 C_MOF ...
so the types RASPA actually uses are Cu1, O1, C1, C2, C3, H1. That is exactly what the warning prints (O_CO2-Cu1, O_CO2-O1, ...). The mixing-rule types Cu, C_MOF, O_MOF, H_MOF are never applied. Unknown CIF labels are added as new pseudo-atoms with no Lennard-Jones parameters (and, if UseChargesFromCIFFile is no, charge 0). Check the pseudo-atom table in the output: you will see Cu1, O1, C1 listed separately from Cu, O_MOF, C_MOF.
You do not need a unique charge on every atom of every MOF. For a typed UFF/DREIDING-style model, give each chemical type one epsilon, sigma, and charge in pseudo_atoms.def / force_field_mixing_rules.def, then make the CIF labels match those type names. UseChargesFromCIFFile no is the right choice if conversion to IL-modified structures is wiping _atom_site_charge.
Two practical ways to make the names match, depending on how you generate CIFs.
1. Keep C_MOF / O_MOF / H_MOF / Cu in the force field (good if you want MOF atoms distinct from CO2, water, and the IL). Rewrite the CIF labels to those names. Labels do not have to be unique:
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
Cu Cu 0.2853 0.2853 0.0000
O_MOF O 0.3166 0.2431 0.9478
C_MOF C 0.2968 0.2032 0.9313
H_MOF H 0.3802 0.2280 0.8802
Keep O_CO2 and C_CO2 only for the guest.
2. Better for many CoRE-style CIFs that already use Cu1, O1, C1, C2. Rename the framework types in the force field to Cu, O, C, H and put this in simulation.input:
RemoveAtomNumberCodeFromLabel yes
That maps Cu1 → Cu, O1 → O, C1/C2/C3 → C, H1 → H. Leave the guests as O_CO2 / C_CO2 so they do not collide with framework O and C. Do not use RemoveAtomNumberCodeFromLabel with types named O_MOF: O1 becomes O, which still will not match O_MOF.
After the names match, the warning should disappear for CO2–framework pairs. Framework–framework missing VDW (Cu–O, C–H, ...) is normal for a rigid framework and can be left undefined, or listed as none if you want a clean log.
Charges for high-throughput: one charge per type in pseudo_atoms.def is enough; you do not assign a charge per MOF. UseChargesFromCIFFile no. Make sure every framework type you actually use is in pseudo_atoms.def, otherwise RASPA adds it with charge 0. The CIF charges you showed (Cu 1.248, O −0.624, ...) are not the same as the pseudo_atoms.def values (Cu 0.836, O_MOF −0.834, C_MOF 0.417, H_MOF 0.417). Pick one consistent set. H_MOF = 0.417 looking identical to C_MOF is worth checking; that is not a typical DREIDING hydrogen charge.
Also fix the mixing-rules header. RASPA2 expects:
# general rule for shifted vs truncated
shifted no
# general rule tailcorrections
no
not the word "truncated" on its own.
Once types match, confirm in the output that (1) the warning is gone for O_CO2/C_CO2 vs Cu/C/O/H, (2) the framework net charge is what you expect, and (3) Movies/System_0/Framework_0_initial_P1.cif has the charges you intended. Mixing UFF/DREIDING (framework), OPLS (IL), and TraPPE-style CO2 is then a force-field choice: Lorentz–Berthelot will run, but Cu-BTC open-metal-site CO2 uptake is often still low with generic Cu parameters. That is a separate issue from this warning.
#2
General / Re: Need Advice on GCMC Simula...
Last post by dubbelda - August 17, 2026, 07:02:24 PMThis is very common, and "too low" is usually a comparison problem (units, absolute vs excess, unfinished sampling) or a setup problem (no working swap moves, missing charges, force field / cutoff / box size). A single parameter almost never explains it on its own.
RASPA2 uses simulation.input (not JSON). A minimal GCMC setup looks like:
SimulationType MonteCarlo
NumberOfCycles 50000
NumberOfInitializationCycles 10000
PrintEvery 1000
Forcefield YourForceField
CutOffVDW 12.0
Framework 0
FrameworkName YourMOF
UnitCells 2 2 2
HeliumVoidFraction 0.7
ExternalTemperature 298.0
ExternalPressure 1e5
ChargeMethod Ewald
UseChargesFromCIFFile yes
Component 0 MoleculeName CO2
MoleculeDefinition TraPPE
TranslationProbability 0.5
RotationProbability 0.5
ReinsertionProbability 0.5
SwapProbability 1.0
CreateNumberOfMolecules 0
1. Confirm you are actually running GCMC, and that insertions work
You need insertion/deletion: SwapProbability (CBMC). Translation / rotation / reinsertion alone is NVT: the number of molecules never changes.
In the output, check the swap statistics. If insertions are almost never constructed or accepted, the loading will sit too low. That is typical at high loading or in tight pores with ordinary CBMC. Switch to CFCMC (CFCMCProbability and/or CBCFCMCProbability) and give NumberOfEquilibrationCycles so the lambda biasing can be learned.
Also check that the five block averages of the loading have actually flattened. If they are still climbing, the run is not equilibrated.
CreateNumberOfMolecules 0 is correct for GCMC starting from an empty framework. Starting with a guessed loading is optional; it does not replace swap moves.
2. Check units and which loading you are comparing
- ExternalPressure is in pascal. 1 bar is 1e5, not 1.0.
- RASPA reports both absolute and excess loading, in several units, for example:
Average loading absolute [molecules/unit cell]
Average loading absolute [mol/kg framework]
Average loading absolute [milligram/gram framework]
Average loading absolute [cm^3 (STP)/gr framework]
Average loading absolute [cm^3 (STP)/cm^3 framework]
and the same set for excess.
- Experiments almost always report excess adsorption. Absolute is the actual number of molecules in the pores; excess subtracts the amount that would already be in the pore volume at the bulk-gas density.
- Excess adsorption needs HeliumVoidFraction from a separate helium Widom run (the Talu–Myers probe, typically helium at room temperature). Without it, excess is not meaningful. At MOF-relevant pressures (often several bar), absolute and excess already differ; at high pressure excess can even fall while absolute stays high.
- molecules/unit cell is per crystallographic unit cell, not per simulation supercell. With UnitCells 2 2 2 the supercell is 8 unit cells, but RASPA already reports per unit cell in that line. Still, do not mix mol/kg, mg/g, cm3 STP/g, and molecules/uc without converting.
3. Force field, charges, cutoff, and box size
The usual suspects for mismatch with literature are simulation length, system size, cutoff, shifted vs truncated+tail, electrostatics, the crystal structure, and unit conversion.
For polar adsorbates (CO2, N2, H2O, ...):
- ChargeMethod Ewald (not None)
- framework charges either from the CIF (UseChargesFromCIFFile yes, via _atom_site_charge) or from pseudo_atoms.def (UseChargesFromCIFFile no). Use the same choice as the published model.
- guest charges from pseudo_atoms.def
- check Movies/System_0/Framework_0_initial_P1.cif: the _atom_site_charge column is what was actually used. The output should also show a near-zero net framework charge.
A typical Van der Waals setup is CutOffVDW 12.0, with shifted yes / tailcorrections no (or truncated with tail corrections) in force_field_mixing_rules.def. The supercell must satisfy shortest box length > 2 × cutoff. A 1 1 1 MOF cell is often too small.
CIF atom labels are a frequent silent failure: O1, O2, C1 often do not match O, C in pseudo_atoms.def, so those atoms get no Lennard-Jones parameters and/or charge 0, and uptake comes out far too low. Use RemoveAtomNumberCodeFromLabel yes, or map the labels explicitly, and confirm every framework type appears in the force-field output.
Generic MOF force fields (UFF/DREIDING plus TraPPE) also often underpredict uptake at open metal sites, especially for CO2 and water. That is a model limitation, not a RASPA setting.
4. Fugacity and Rosenbluth weight
- If FugacityCoefficient is omitted (or 0), RASPA converts pressure to fugacity with Peng–Robinson using Tc, Pc, and the acentric factor from the molecule file. FugacityCoefficient 1.0 treats the input as fugacity, i.e. the ideal-gas approximation. At high pressure that changes the imposed chemical potential.
- IdealGasRosenbluthWeight must be 1.0 for rigid molecules. For flexible chains it must be precomputed (Widom in an empty box at the same temperature). A wrong value shifts the chemical-potential reference and can systematically lower the loading.
Check in the output that the computed fugacity coefficient, bulk density, and "amount of excess molecules" look sensible, and that the fluid is still a gas (not past the vapor pressure).
5. Structure
Use a solvent-free, correctly bonded CIF. Block inaccessible pockets with BlockPockets / BlockPocketsFileName if the structure has them (sodalite cages, etc.). Leftover solvent, missing hydrogens, or a non-P1 cell read with the wrong symmetry will all change the pore volume and the loading.
6. Quick health checks in the output
- Energy drift should be ~1e-5 or better (running energy vs fully recomputed energy). Larger drift means the energies, and therefore the loading, are not trustworthy.
- Swap acceptance should be non-zero; at high loading prefer CFCMC.
- Measured chemical potential / fugacity from Widom should be close to the imposed value once the system is equilibrated.
- NumberOfCycles is the production run. A RASPA cycle is max(20, N) move attempts, so "50000 cycles" is not 50000 insertions. Trust the block averages and error bars, not the cycle count.
7. Validating against experiment
Match the quantity first, then the physical model.
What to plot against the isotherm
- Use excess loading, in the same units as the paper (usually mmol/g, mg/g, or cm3 STP/g). RASPA already prints these if HeliumVoidFraction is set.
- Compare at the same temperature. Pressure: at low P, fugacity ≈ pressure; at several bar you should convert experimental pressure to fugacity (Peng–Robinson, or the EOS the paper used) or let RASPA do that conversion and plot vs the experimental pressure consistently.
- The cleanest check is the Henry regime (low P): slope of loading vs pressure, or a separate Widom Henry coefficient. If Henry is already too low, the high-pressure isotherm will be too low as well.
- Do not compare above the adsorbate vapor pressure. Experimental gas-phase isotherms stop there; beyond it you are in a different regime and excess can even become negative.
- Convert units using the simulated framework mass, not a formula-unit mass that omits extra-framework species or includes solvent.
What must match the experimental sample
- Same crystal structure: solvent-free CIF, correct topology, no collapsed or desolvated phase unless that is what was measured. If the experimental BET area or pore volume is much larger/smaller than the perfect-crystal helium void volume, the loadings will not match even with a perfect force field.
- Activation, leftover solvent, defects, missing linkers, and extra-framework ions in the real sample are the most common reasons experiment sits above or below a perfect-crystal GCMC run.
- Open metal sites, humidity, and polar adsorbates: a generic force field without extra site–guest parameters will usually underpredict. That is expected, not a sign that SwapProbability is wrong.
- Framework flexibility: a rigid GCMC run can miss extra uptake from breathing or linker rotation. If the experimental isotherm is temperature- or pressure-stepped, you may need a flexible model.
- Mixture or impure feed gas in experiment (especially water) will not match a dry single-component GCMC run.
A practical validation sequence
1. Reproduce a published simulation for the same MOF + adsorbate + force field (not the experiment yet). If you cannot match the paper, the input is wrong.
2. Check Henry coefficient / low-pressure slope against experiment.
3. Check the full excess isotherm, with HeliumVoidFraction from a helium Widom run, in the experimental units.
4. Check a second observable if available (isosteric heat, preferential binding site). Loading alone can be right for the wrong reasons.
5. Only then decide whether remaining disagreement is force field, flexibility, or the real sample.
A practical order of checks: (1) pressure in Pa and excess vs absolute / matching units, (2) swap move actually accepting, (3) charges + Ewald for polar gases and CIF labels mapped to the force field, (4) box ≥ 2×cutoff, (5) force field and CIF matching the paper you compare to, (6) helium void fraction and experimental excess. If you post simulation.input, the force-field files, the molecule definition, and the loading table from the output, the failure mode is usually visible in a few lines.
RASPA2 uses simulation.input (not JSON). A minimal GCMC setup looks like:
SimulationType MonteCarlo
NumberOfCycles 50000
NumberOfInitializationCycles 10000
PrintEvery 1000
Forcefield YourForceField
CutOffVDW 12.0
Framework 0
FrameworkName YourMOF
UnitCells 2 2 2
HeliumVoidFraction 0.7
ExternalTemperature 298.0
ExternalPressure 1e5
ChargeMethod Ewald
UseChargesFromCIFFile yes
Component 0 MoleculeName CO2
MoleculeDefinition TraPPE
TranslationProbability 0.5
RotationProbability 0.5
ReinsertionProbability 0.5
SwapProbability 1.0
CreateNumberOfMolecules 0
1. Confirm you are actually running GCMC, and that insertions work
You need insertion/deletion: SwapProbability (CBMC). Translation / rotation / reinsertion alone is NVT: the number of molecules never changes.
In the output, check the swap statistics. If insertions are almost never constructed or accepted, the loading will sit too low. That is typical at high loading or in tight pores with ordinary CBMC. Switch to CFCMC (CFCMCProbability and/or CBCFCMCProbability) and give NumberOfEquilibrationCycles so the lambda biasing can be learned.
Also check that the five block averages of the loading have actually flattened. If they are still climbing, the run is not equilibrated.
CreateNumberOfMolecules 0 is correct for GCMC starting from an empty framework. Starting with a guessed loading is optional; it does not replace swap moves.
2. Check units and which loading you are comparing
- ExternalPressure is in pascal. 1 bar is 1e5, not 1.0.
- RASPA reports both absolute and excess loading, in several units, for example:
Average loading absolute [molecules/unit cell]
Average loading absolute [mol/kg framework]
Average loading absolute [milligram/gram framework]
Average loading absolute [cm^3 (STP)/gr framework]
Average loading absolute [cm^3 (STP)/cm^3 framework]
and the same set for excess.
- Experiments almost always report excess adsorption. Absolute is the actual number of molecules in the pores; excess subtracts the amount that would already be in the pore volume at the bulk-gas density.
- Excess adsorption needs HeliumVoidFraction from a separate helium Widom run (the Talu–Myers probe, typically helium at room temperature). Without it, excess is not meaningful. At MOF-relevant pressures (often several bar), absolute and excess already differ; at high pressure excess can even fall while absolute stays high.
- molecules/unit cell is per crystallographic unit cell, not per simulation supercell. With UnitCells 2 2 2 the supercell is 8 unit cells, but RASPA already reports per unit cell in that line. Still, do not mix mol/kg, mg/g, cm3 STP/g, and molecules/uc without converting.
3. Force field, charges, cutoff, and box size
The usual suspects for mismatch with literature are simulation length, system size, cutoff, shifted vs truncated+tail, electrostatics, the crystal structure, and unit conversion.
For polar adsorbates (CO2, N2, H2O, ...):
- ChargeMethod Ewald (not None)
- framework charges either from the CIF (UseChargesFromCIFFile yes, via _atom_site_charge) or from pseudo_atoms.def (UseChargesFromCIFFile no). Use the same choice as the published model.
- guest charges from pseudo_atoms.def
- check Movies/System_0/Framework_0_initial_P1.cif: the _atom_site_charge column is what was actually used. The output should also show a near-zero net framework charge.
A typical Van der Waals setup is CutOffVDW 12.0, with shifted yes / tailcorrections no (or truncated with tail corrections) in force_field_mixing_rules.def. The supercell must satisfy shortest box length > 2 × cutoff. A 1 1 1 MOF cell is often too small.
CIF atom labels are a frequent silent failure: O1, O2, C1 often do not match O, C in pseudo_atoms.def, so those atoms get no Lennard-Jones parameters and/or charge 0, and uptake comes out far too low. Use RemoveAtomNumberCodeFromLabel yes, or map the labels explicitly, and confirm every framework type appears in the force-field output.
Generic MOF force fields (UFF/DREIDING plus TraPPE) also often underpredict uptake at open metal sites, especially for CO2 and water. That is a model limitation, not a RASPA setting.
4. Fugacity and Rosenbluth weight
- If FugacityCoefficient is omitted (or 0), RASPA converts pressure to fugacity with Peng–Robinson using Tc, Pc, and the acentric factor from the molecule file. FugacityCoefficient 1.0 treats the input as fugacity, i.e. the ideal-gas approximation. At high pressure that changes the imposed chemical potential.
- IdealGasRosenbluthWeight must be 1.0 for rigid molecules. For flexible chains it must be precomputed (Widom in an empty box at the same temperature). A wrong value shifts the chemical-potential reference and can systematically lower the loading.
Check in the output that the computed fugacity coefficient, bulk density, and "amount of excess molecules" look sensible, and that the fluid is still a gas (not past the vapor pressure).
5. Structure
Use a solvent-free, correctly bonded CIF. Block inaccessible pockets with BlockPockets / BlockPocketsFileName if the structure has them (sodalite cages, etc.). Leftover solvent, missing hydrogens, or a non-P1 cell read with the wrong symmetry will all change the pore volume and the loading.
6. Quick health checks in the output
- Energy drift should be ~1e-5 or better (running energy vs fully recomputed energy). Larger drift means the energies, and therefore the loading, are not trustworthy.
- Swap acceptance should be non-zero; at high loading prefer CFCMC.
- Measured chemical potential / fugacity from Widom should be close to the imposed value once the system is equilibrated.
- NumberOfCycles is the production run. A RASPA cycle is max(20, N) move attempts, so "50000 cycles" is not 50000 insertions. Trust the block averages and error bars, not the cycle count.
7. Validating against experiment
Match the quantity first, then the physical model.
What to plot against the isotherm
- Use excess loading, in the same units as the paper (usually mmol/g, mg/g, or cm3 STP/g). RASPA already prints these if HeliumVoidFraction is set.
- Compare at the same temperature. Pressure: at low P, fugacity ≈ pressure; at several bar you should convert experimental pressure to fugacity (Peng–Robinson, or the EOS the paper used) or let RASPA do that conversion and plot vs the experimental pressure consistently.
- The cleanest check is the Henry regime (low P): slope of loading vs pressure, or a separate Widom Henry coefficient. If Henry is already too low, the high-pressure isotherm will be too low as well.
- Do not compare above the adsorbate vapor pressure. Experimental gas-phase isotherms stop there; beyond it you are in a different regime and excess can even become negative.
- Convert units using the simulated framework mass, not a formula-unit mass that omits extra-framework species or includes solvent.
What must match the experimental sample
- Same crystal structure: solvent-free CIF, correct topology, no collapsed or desolvated phase unless that is what was measured. If the experimental BET area or pore volume is much larger/smaller than the perfect-crystal helium void volume, the loadings will not match even with a perfect force field.
- Activation, leftover solvent, defects, missing linkers, and extra-framework ions in the real sample are the most common reasons experiment sits above or below a perfect-crystal GCMC run.
- Open metal sites, humidity, and polar adsorbates: a generic force field without extra site–guest parameters will usually underpredict. That is expected, not a sign that SwapProbability is wrong.
- Framework flexibility: a rigid GCMC run can miss extra uptake from breathing or linker rotation. If the experimental isotherm is temperature- or pressure-stepped, you may need a flexible model.
- Mixture or impure feed gas in experiment (especially water) will not match a dry single-component GCMC run.
A practical validation sequence
1. Reproduce a published simulation for the same MOF + adsorbate + force field (not the experiment yet). If you cannot match the paper, the input is wrong.
2. Check Henry coefficient / low-pressure slope against experiment.
3. Check the full excess isotherm, with HeliumVoidFraction from a helium Widom run, in the experimental units.
4. Check a second observable if available (isosteric heat, preferential binding site). Loading alone can be right for the wrong reasons.
5. Only then decide whether remaining disagreement is force field, flexibility, or the real sample.
A practical order of checks: (1) pressure in Pa and excess vs absolute / matching units, (2) swap move actually accepting, (3) charges + Ewald for polar gases and CIF labels mapped to the force field, (4) box ≥ 2×cutoff, (5) force field and CIF matching the paper you compare to, (6) helium void fraction and experimental excess. If you post simulation.input, the force-field files, the molecule definition, and the loading table from the output, the failure mode is usually visible in a few lines.
#3
Bug reports / Re: Software won't work unless...
Last post by dubbelda - August 17, 2026, 06:58:07 PMThis is a windows problem plus Qt problem. The windows port has now been rewritten in WinUI3 and DirectX12.
#4
General / Re: Generating Adsorbate Densi...
Last post by dubbelda - August 17, 2026, 06:53:54 PMThese are two different "grids." Energy interpolation grids only speed up host–guest energy evaluation. Adsorbate density plots come from a separate histogram, ComputeDensityGrid, which is sampled over many production configurations. A restart file is one snapshot; it is a good starting point for a new production run, not a density profile by itself.
Yes — restart from the JSON restart and run production with density grids on. You do not need energy/interpolation grids for that.
A density cube is an ensemble average: every SampleDensityGridEvery production cycles, adsorbate positions are binned onto a 3D grid and written as Gaussian cube files under density_grids/. One final configuration (or one restart) only shows where the molecules happened to sit at that moment.
Energy interpolation grids (UseInterpolationGrids in force_field.json) are optional and unrelated. They precompute framework–adsorbate energies. Turning them on later does not create density plots, and you can compute density grids without them.
Do not use RestartFromBinaryFile. That restores the original run's full state and ignores new simulation.json settings, so you cannot switch on density grids that way.
Use the JSON restart instead:
Copy the restart out of output/ so the next run does not overwrite it:
cp output/restart_<T>_<P>.s0.json .
Point the system at it with "RestartFileName", set "CreateNumberOfMolecules": 0, and enable density grids.
Because the configuration is already equilibrated, you can use few (or zero) initialization cycles, then enough production cycles for a converged histogram.
{
"SimulationType": "MonteCarlo",
"NumberOfInitializationCycles": 0,
"NumberOfProductionCycles": 100000,
"PrintEvery": 5000,
"Systems": [
{
"Type": "Framework",
"Name": "YourFramework",
"NumberOfUnitCells": [2, 2, 2],
"ExternalTemperature": 298.0,
"ExternalPressure": 1.0e5,
"RestartFileName": "restart_298_0.s0",
"ComputeDensityGrid": true,
"SampleDensityGridEvery": 10,
"WriteDensityGridEvery": 5000,
"DensityGridSize": [128, 128, 128]
}
],
"Components": [
{
"Name": "CO2",
"TranslationProbability": 0.5,
"RotationProbability": 0.5,
"ReinsertionProbability": 0.5,
"SwapProbability": 1.0,
"CreateNumberOfMolecules": 0
}
]
}
Output goes to density_grids/ as .cube files (view in VMD, iRASPA, etc.). Optional extras: "DensityGridPseudoAtomsList" for site-resolved maps (e.g. C_co2 vs O_co2), and "DensityGridBinning": "Equitable" for smoother histograms.
No — not from the final configuration alone. RASPA3 has no "make a density cube from this restart/PDB" step. If you already wrote a PDB movie (OutputPDBMovie) with many frames, you can histogram that trajectory yourself (for example VMD volmap). That is a post-processing substitute, not a built-in RASPA3 feature, and a single last frame is still not enough.
Practical recommendation: copy the JSON restart, enable ComputeDensityGrid, and run a production-only continuation. Add interpolation grids only if you want that continuation to run faster.
Yes — restart from the JSON restart and run production with density grids on. You do not need energy/interpolation grids for that.
A density cube is an ensemble average: every SampleDensityGridEvery production cycles, adsorbate positions are binned onto a 3D grid and written as Gaussian cube files under density_grids/. One final configuration (or one restart) only shows where the molecules happened to sit at that moment.
Energy interpolation grids (UseInterpolationGrids in force_field.json) are optional and unrelated. They precompute framework–adsorbate energies. Turning them on later does not create density plots, and you can compute density grids without them.
Do not use RestartFromBinaryFile. That restores the original run's full state and ignores new simulation.json settings, so you cannot switch on density grids that way.
Use the JSON restart instead:
Copy the restart out of output/ so the next run does not overwrite it:
cp output/restart_<T>_<P>.s0.json .
Point the system at it with "RestartFileName", set "CreateNumberOfMolecules": 0, and enable density grids.
Because the configuration is already equilibrated, you can use few (or zero) initialization cycles, then enough production cycles for a converged histogram.
{
"SimulationType": "MonteCarlo",
"NumberOfInitializationCycles": 0,
"NumberOfProductionCycles": 100000,
"PrintEvery": 5000,
"Systems": [
{
"Type": "Framework",
"Name": "YourFramework",
"NumberOfUnitCells": [2, 2, 2],
"ExternalTemperature": 298.0,
"ExternalPressure": 1.0e5,
"RestartFileName": "restart_298_0.s0",
"ComputeDensityGrid": true,
"SampleDensityGridEvery": 10,
"WriteDensityGridEvery": 5000,
"DensityGridSize": [128, 128, 128]
}
],
"Components": [
{
"Name": "CO2",
"TranslationProbability": 0.5,
"RotationProbability": 0.5,
"ReinsertionProbability": 0.5,
"SwapProbability": 1.0,
"CreateNumberOfMolecules": 0
}
]
}
Output goes to density_grids/ as .cube files (view in VMD, iRASPA, etc.). Optional extras: "DensityGridPseudoAtomsList" for site-resolved maps (e.g. C_co2 vs O_co2), and "DensityGridBinning": "Equitable" for smoother histograms.
No — not from the final configuration alone. RASPA3 has no "make a density cube from this restart/PDB" step. If you already wrote a PDB movie (OutputPDBMovie) with many frames, you can histogram that trajectory yourself (for example VMD volmap). That is a post-processing substitute, not a built-in RASPA3 feature, and a single last frame is still not enough.
Practical recommendation: copy the JSON restart, enable ComputeDensityGrid, and run a production-only continuation. Add interpolation grids only if you want that continuation to run faster.
#5
Input files and parameters / British English vs American En...
Last post by infinitewordle - August 12, 2026, 04:27:34 PMThere is nothing that infuriates the players of word games
more than entering a word they have been using their whole lives, and receiving a message that it is not a word. And that is what happens to British, Irish, Australian, Indian and Canadian players in most word games – and it is not a bug, but a problem yet to be solved.
The point where the two varieties diverge
The differences are consistent and predictable, which means you can learn them and stop spending a guess on this issue.
The last row is what causes most problems in five-letter word games. Both GREY and GRAY are acceptable, common, five letters long and potential solutions. If you submit GREY and receive grey tiles, you are learning a wrong lesson about the word.
Why word games handle it differently
Almost all word games use some of the public word lists as the basis for their operation, and those lists have a preference for a certain regional variety programmed in them.
Some of the games accept both versions, but use only one of them as the answer. This is the most common solution, and also the most sensible, even though it means occasional wasted guess in learning about the variety of the answer list.
Some games accept only one variety, and this is just annoying.
Fewer still allow you to choose your variety, and this is the right solution, and much less common than it should be.
The effect of the difference on your game
If you do not know what variety of the game you are playing, there are several ways to protect yourself from problems.
First of all, do not use ambiguous words as openers. GREY is a bad opener not because of its letters, but because of its ambiguity. Pick something else.
Second, be suspicious of OUR and RE endings. If you are playing the American variety, you will never see COLOUR and CENTRE among the possible answers, so do not waste your guesses trying to use structures that won't be there.
Third, remember that both varieties are acceptable as guesses, even if only one variety is used as the answer. You can test your letters using British spelling; it is just a word you will never submit.
Fourth, pay attention to Z. If you use ISE endings as your answers, Z will not be nearly as valuable in British English as in American word frequencies.
Why the regional variety is so important
The ability to choose your variety is not a matter of taste. It will affect your answer list and therefore your strategy.
Wordle Unlimited has a regional variety and language settings in the settings menu, under the gear icon. This setting is especially important for people from countries outside the USA, who have to spend part of each game submitting their spelling and getting the message it is incorrect.
But this setting is even more important for teachers. Class learning English according to the British curriculum, but playing an American word game will find their students submitting their spelling and being frustrated because of it being marked as incorrect.
The wider issue of word lists
All word games use two word lists. First, the long list of words which can be used as your guesses. Second, the small list of words that can be used as answers.
Guess list has to be sufficiently large to include the obscure words, because they can be used as guesses. Answer list has to be limited to words known by most people, because a puzzle with an obscure word as an answer is not very exciting.
That is why sometimes you can submit an obscure word and have it confirmed, but never see it as an answer. And that is why most disputes about correct words end up here. The game will confirm the existence of the word, but it will never use it as an answer.
What is reasonable to expect
No word game can satisfy everybody on this question, because English language has several standard varieties, and the puzzle has to choose between them.
What is reasonable to expect is acceptance of both spellings as guesses, indication or configurability of the choice of the variety of the answer and lack of flagging one of the varieties as an error. Wordle Unlimited solves this issue by providing a regional variety setting in the gear menu at wordleunlimited.dev, along with word length, theme and hard mode.
Apart from that, it is something you need to know rather than argue about. Knowing that GREY and GRAY are both valid options is just playing a word game in a language with two spelling varieties.
more than entering a word they have been using their whole lives, and receiving a message that it is not a word. And that is what happens to British, Irish, Australian, Indian and Canadian players in most word games – and it is not a bug, but a problem yet to be solved.
The point where the two varieties diverge
The differences are consistent and predictable, which means you can learn them and stop spending a guess on this issue.
The last row is what causes most problems in five-letter word games. Both GREY and GRAY are acceptable, common, five letters long and potential solutions. If you submit GREY and receive grey tiles, you are learning a wrong lesson about the word.
Why word games handle it differently
Almost all word games use some of the public word lists as the basis for their operation, and those lists have a preference for a certain regional variety programmed in them.
Some of the games accept both versions, but use only one of them as the answer. This is the most common solution, and also the most sensible, even though it means occasional wasted guess in learning about the variety of the answer list.
Some games accept only one variety, and this is just annoying.
Fewer still allow you to choose your variety, and this is the right solution, and much less common than it should be.
The effect of the difference on your game
If you do not know what variety of the game you are playing, there are several ways to protect yourself from problems.
First of all, do not use ambiguous words as openers. GREY is a bad opener not because of its letters, but because of its ambiguity. Pick something else.
Second, be suspicious of OUR and RE endings. If you are playing the American variety, you will never see COLOUR and CENTRE among the possible answers, so do not waste your guesses trying to use structures that won't be there.
Third, remember that both varieties are acceptable as guesses, even if only one variety is used as the answer. You can test your letters using British spelling; it is just a word you will never submit.
Fourth, pay attention to Z. If you use ISE endings as your answers, Z will not be nearly as valuable in British English as in American word frequencies.
Why the regional variety is so important
The ability to choose your variety is not a matter of taste. It will affect your answer list and therefore your strategy.
Wordle Unlimited has a regional variety and language settings in the settings menu, under the gear icon. This setting is especially important for people from countries outside the USA, who have to spend part of each game submitting their spelling and getting the message it is incorrect.
But this setting is even more important for teachers. Class learning English according to the British curriculum, but playing an American word game will find their students submitting their spelling and being frustrated because of it being marked as incorrect.
The wider issue of word lists
All word games use two word lists. First, the long list of words which can be used as your guesses. Second, the small list of words that can be used as answers.
Guess list has to be sufficiently large to include the obscure words, because they can be used as guesses. Answer list has to be limited to words known by most people, because a puzzle with an obscure word as an answer is not very exciting.
That is why sometimes you can submit an obscure word and have it confirmed, but never see it as an answer. And that is why most disputes about correct words end up here. The game will confirm the existence of the word, but it will never use it as an answer.
What is reasonable to expect
No word game can satisfy everybody on this question, because English language has several standard varieties, and the puzzle has to choose between them.
What is reasonable to expect is acceptance of both spellings as guesses, indication or configurability of the choice of the variety of the answer and lack of flagging one of the varieties as an error. Wordle Unlimited solves this issue by providing a regional variety setting in the gear menu at wordleunlimited.dev, along with word length, theme and hard mode.
Apart from that, it is something you need to know rather than argue about. Knowing that GREY and GRAY are both valid options is just playing a word game in a language with two spelling varieties.
#6
General / Re: Limit on the number of ato...
Last post by ramika - July 29, 2026, 08:19:37 AMComplicated booking processes ruin the mood before you even begin. We keep everything simple from your first message to the final goodbye. Elegant companions, zero stress. Choose High Class Call Girls Service in Delhi for experiences that feel natural and effortless.
#7
General / What Makes Clash Royale Enduri...
Last post by Joycefiore - July 17, 2026, 04:36:32 AMClash Royale is a standout strategy game on mobile platforms. Despite launching years ago, it retains a massive player base and consistently ranks among the most beloved strategy games. With its innovative gameplay, high level of competition, and constantly updated content, Clash Royale offers an engaging experience for both newcomers and veteran gamers.
#8
General / Need Advice on GCMC Simulation...
Last post by AubrielleCruz - July 07, 2026, 09:13:06 AMHi everyone, war the knights
I'm currently running a GCMC simulation for gas adsorption in a metal–organic framework (MOF), but I'm unsure whether my simulation parameters are appropriate. The adsorption results seem lower than expected, and I'd like to verify that my setup is correct.
Has anyone experienced something similar? Are there any key parameters or best practices I should check to improve the accuracy of my simulation?
Any suggestions would be greatly appreciated.
Thanks!
I'm currently running a GCMC simulation for gas adsorption in a metal–organic framework (MOF), but I'm unsure whether my simulation parameters are appropriate. The adsorption results seem lower than expected, and I'd like to verify that my setup is correct.
Has anyone experienced something similar? Are there any key parameters or best practices I should check to improve the accuracy of my simulation?
Any suggestions would be greatly appreciated.
Thanks!
#9
General / No VDW interaction for my made...
Last post by alice - July 06, 2026, 12:28:05 PMHello people, so I am working on MOFs adsoprtion on CO2 but the issues lies that the forcefield file which I made by taking UFF/Dreiding and OPLS Parameters is giving me no vdw warnings. For an example, check my cubtc test files: cif file portion
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_charge
Cu1 Cu 0.2853 0.2853 0.0000 1.248
O1 O_MOF 0.3166 0.2431 0.9478 -0.624
C1 C_MOF 0.2968 0.2032 0.9313 0.494
C2 C_MOF 0.3220 0.1780 0.8870 0.130
C3 C_MOF 0.3655 0.1994 0.8655 -0.156
H1 H_MOF 0.3802 0.2280 0.8802 0.156
forcefield mixing:# general rule for shifted vs truncated
truncated
# general rule tailcorrections
no
# number of defined interactions
33
# type interaction
O_CO2 lennard-jones 79.0 3.05
C_CO2 lennard-jones 27.0 2.80
Cu lennard-jones 2.5161 3.11369
C_MOF lennard-jones 47.8562 3.47299
O_MOF lennard-jones 48.1581 3.03315
H_MOF lennard-jones 7.64893 2.84642
N_BMIM lennard-jones 85.55 3.25
C_BMIM_CR lennard-jones 35.22 3.55
C_BMIM_CW lennard-jones 35.22 3.55
H_BMIM_HR lennard-jones 15.10 2.42
H_BMIM_HW lennard-jones 15.10 2.42
C_BMIM_CM lennard-jones 33.21 3.50
H_BMIM_HM lennard-jones 15.10 2.50
C_BMIM_CA lennard-jones 33.21 3.50
H_BMIM_HA lennard-jones 15.10 2.50
C_BMIM_CS lennard-jones 33.21 3.50
H_BMIM_HS lennard-jones 15.10 2.50
C_BMIM_CT lennard-jones 33.21 3.50
H_BMIM_HT lennard-jones 15.10 2.50
B_BF4 lennard-jones 47.81 3.581
F_BF4 lennard-jones 30.70 3.118
OwH2O_TIP4P lennard-jones 78.0 3.154
HwH2O_TIP4P none
MwH2O_TIP4P none
OwH2O_TIP4PEW lennard-jones 81.9 3.164
HwH2O_TIP4PEW none
MwH2O_TIP4PEW none
OwH2O_TIP5P lennard-jones 80.52 3.12
HwH2O_TIP5P none
MwH2O_TIP5P none
OwH2O_TIP5PEW lennard-jones 89.57 3.097
HwH2O_TIP5PEW none
MwH2O_TIP5PEW none
# general mixing rule for Lennard-Jones
Lorentz-Berthelot
pseudo atoms def
#number of pseudo atoms
33
#type print as chem oxidation mass charge polarization B-factor radii connectivity anisotropic anisotropic-type tinker-type
O_CO2 yes O O 0 15.9996 -0.350 0.0 1.0 1.0 1 0 absolute 0
C_CO2 yes C C 0 12.0110 0.700 0.0 1.0 1.0 2 0 absolute 0
Cu yes Cu Cu 0 63.5460 0.8360 0.0 1.0 1.0 5 0 absolute 0
C_MOF yes C C 0 12.0110 0.4170 0.0 1.0 1.0 3 0 absolute 0
O_MOF yes O O 0 15.9996 -0.8340 0.0 1.0 1.0 3 0 absolute 0
H_MOF yes H H 0 1.0080 0.4170 0.0 1.0 1.0 1 0 absolute 0
N_BMIM yes N N 0 14.0070 0.1760 0.0 1.0 1.0 3 0 absolute 0
C_BMIM_CR yes C C 0 12.0110 -0.0720 0.0 1.0 1.0 3 0 absolute 0
C_BMIM_CW yes C C 0 12.0110 -0.1920 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HR yes H H 0 1.0080 0.1680 0.0 1.0 1.0 1 0 absolute 0
H_BMIM_HW yes H H 0 1.0080 0.2160 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CM yes C C 0 12.0110 -0.2800 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HM yes H H 0 1.0080 0.1440 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CA yes C C 0 12.0110 -0.1360 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HA yes H H 0 1.0080 0.1440 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CS yes C C 0 12.0110 -0.0960 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HS yes H H 0 1.0080 0.0480 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CT yes C C 0 12.0110 -0.1920 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HT yes H H 0 1.0080 0.0640 0.0 1.0 1.0 1 0 absolute 0
B_BF4 yes B B 0 10.8110 1.1340 0.0 1.0 1.0 3 0 absolute 0
F_BF4 yes F F 0 18.9980 -0.5335 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP4P yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP4P yes H H 0 1.0008 0.5200 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP4P yes M - 0 0.0000 -1.0400 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP4PEW yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP4PEW yes H H 0 1.0008 0.52422 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP4PEW yes M - 0 0.0000 -1.04844 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP5P yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP5P yes H H 0 1.0008 0.2410 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP5P yes M - 0 0.0000 -0.2410 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP5PEW yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP5PEW yes H H 0 1.0008 0.2410 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP5PEW yes M - 0 0.0000 -0.2410 0.0 1.0 1.0 1 0 absolute 0
and in output getting:
WARNING: THERE ARE ATOM-PAIRS WITH NO VDW INTERACTION O_CO2-Cu1 O_CO2-O1 O_CO2-C1 O_CO2-C2 O_CO2-C3 O_CO2-H1 C_CO2-Cu1 C_CO2-O1 C_CO2-C1 C_CO2-C2 C_CO2-C3 C_CO2-H1 Cu1-O_CO2 Cu1-C_CO2 Cu1-O1 Cu1-C1 Cu1-C2 Cu1-C3 Cu1-H1 O1-O_CO2 O1-C_CO2 O1-Cu1 O1-C1 O1-C2 O1-C3 O1-H1 C1-O_CO2 C1-C_CO2 C1-Cu1 C1-O1 C1-C2 C1-C3 C1-H1 C2-O_CO2 C2-C_CO2 C2-Cu1 C2-O1 C2-C1 C2-C3 C2-H1 C3-O_CO2 C3-C_CO2 C3-Cu1 C3-O1 C3-C1 C3-C2 C3-H1 H1-O_CO2 H1-C_CO2 H1-Cu1 (maximum 50 interactions shown)
I will be working on many mofs so assigning each one a charge might not be efficient. I am using no charges from cif file itself as modifying many MOFs with ILs liquid and such reduces the charges to zero with conversions.
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_charge
Cu1 Cu 0.2853 0.2853 0.0000 1.248
O1 O_MOF 0.3166 0.2431 0.9478 -0.624
C1 C_MOF 0.2968 0.2032 0.9313 0.494
C2 C_MOF 0.3220 0.1780 0.8870 0.130
C3 C_MOF 0.3655 0.1994 0.8655 -0.156
H1 H_MOF 0.3802 0.2280 0.8802 0.156
forcefield mixing:# general rule for shifted vs truncated
truncated
# general rule tailcorrections
no
# number of defined interactions
33
# type interaction
O_CO2 lennard-jones 79.0 3.05
C_CO2 lennard-jones 27.0 2.80
Cu lennard-jones 2.5161 3.11369
C_MOF lennard-jones 47.8562 3.47299
O_MOF lennard-jones 48.1581 3.03315
H_MOF lennard-jones 7.64893 2.84642
N_BMIM lennard-jones 85.55 3.25
C_BMIM_CR lennard-jones 35.22 3.55
C_BMIM_CW lennard-jones 35.22 3.55
H_BMIM_HR lennard-jones 15.10 2.42
H_BMIM_HW lennard-jones 15.10 2.42
C_BMIM_CM lennard-jones 33.21 3.50
H_BMIM_HM lennard-jones 15.10 2.50
C_BMIM_CA lennard-jones 33.21 3.50
H_BMIM_HA lennard-jones 15.10 2.50
C_BMIM_CS lennard-jones 33.21 3.50
H_BMIM_HS lennard-jones 15.10 2.50
C_BMIM_CT lennard-jones 33.21 3.50
H_BMIM_HT lennard-jones 15.10 2.50
B_BF4 lennard-jones 47.81 3.581
F_BF4 lennard-jones 30.70 3.118
OwH2O_TIP4P lennard-jones 78.0 3.154
HwH2O_TIP4P none
MwH2O_TIP4P none
OwH2O_TIP4PEW lennard-jones 81.9 3.164
HwH2O_TIP4PEW none
MwH2O_TIP4PEW none
OwH2O_TIP5P lennard-jones 80.52 3.12
HwH2O_TIP5P none
MwH2O_TIP5P none
OwH2O_TIP5PEW lennard-jones 89.57 3.097
HwH2O_TIP5PEW none
MwH2O_TIP5PEW none
# general mixing rule for Lennard-Jones
Lorentz-Berthelot
pseudo atoms def
#number of pseudo atoms
33
#type print as chem oxidation mass charge polarization B-factor radii connectivity anisotropic anisotropic-type tinker-type
O_CO2 yes O O 0 15.9996 -0.350 0.0 1.0 1.0 1 0 absolute 0
C_CO2 yes C C 0 12.0110 0.700 0.0 1.0 1.0 2 0 absolute 0
Cu yes Cu Cu 0 63.5460 0.8360 0.0 1.0 1.0 5 0 absolute 0
C_MOF yes C C 0 12.0110 0.4170 0.0 1.0 1.0 3 0 absolute 0
O_MOF yes O O 0 15.9996 -0.8340 0.0 1.0 1.0 3 0 absolute 0
H_MOF yes H H 0 1.0080 0.4170 0.0 1.0 1.0 1 0 absolute 0
N_BMIM yes N N 0 14.0070 0.1760 0.0 1.0 1.0 3 0 absolute 0
C_BMIM_CR yes C C 0 12.0110 -0.0720 0.0 1.0 1.0 3 0 absolute 0
C_BMIM_CW yes C C 0 12.0110 -0.1920 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HR yes H H 0 1.0080 0.1680 0.0 1.0 1.0 1 0 absolute 0
H_BMIM_HW yes H H 0 1.0080 0.2160 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CM yes C C 0 12.0110 -0.2800 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HM yes H H 0 1.0080 0.1440 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CA yes C C 0 12.0110 -0.1360 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HA yes H H 0 1.0080 0.1440 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CS yes C C 0 12.0110 -0.0960 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HS yes H H 0 1.0080 0.0480 0.0 1.0 1.0 1 0 absolute 0
C_BMIM_CT yes C C 0 12.0110 -0.1920 0.0 1.0 1.0 3 0 absolute 0
H_BMIM_HT yes H H 0 1.0080 0.0640 0.0 1.0 1.0 1 0 absolute 0
B_BF4 yes B B 0 10.8110 1.1340 0.0 1.0 1.0 3 0 absolute 0
F_BF4 yes F F 0 18.9980 -0.5335 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP4P yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP4P yes H H 0 1.0008 0.5200 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP4P yes M - 0 0.0000 -1.0400 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP4PEW yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP4PEW yes H H 0 1.0008 0.52422 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP4PEW yes M - 0 0.0000 -1.04844 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP5P yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP5P yes H H 0 1.0008 0.2410 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP5P yes M - 0 0.0000 -0.2410 0.0 1.0 1.0 1 0 absolute 0
OwH2O_TIP5PEW yes O O 0 15.9996 0.0000 0.0 1.0 1.0 3 0 absolute 0
HwH2O_TIP5PEW yes H H 0 1.0008 0.2410 0.0 1.0 1.0 1 0 absolute 0
MwH2O_TIP5PEW yes M - 0 0.0000 -0.2410 0.0 1.0 1.0 1 0 absolute 0
and in output getting:
WARNING: THERE ARE ATOM-PAIRS WITH NO VDW INTERACTION O_CO2-Cu1 O_CO2-O1 O_CO2-C1 O_CO2-C2 O_CO2-C3 O_CO2-H1 C_CO2-Cu1 C_CO2-O1 C_CO2-C1 C_CO2-C2 C_CO2-C3 C_CO2-H1 Cu1-O_CO2 Cu1-C_CO2 Cu1-O1 Cu1-C1 Cu1-C2 Cu1-C3 Cu1-H1 O1-O_CO2 O1-C_CO2 O1-Cu1 O1-C1 O1-C2 O1-C3 O1-H1 C1-O_CO2 C1-C_CO2 C1-Cu1 C1-O1 C1-C2 C1-C3 C1-H1 C2-O_CO2 C2-C_CO2 C2-Cu1 C2-O1 C2-C1 C2-C3 C2-H1 C3-O_CO2 C3-C_CO2 C3-Cu1 C3-O1 C3-C1 C3-C2 C3-H1 H1-O_CO2 H1-C_CO2 H1-Cu1 (maximum 50 interactions shown)
I will be working on many mofs so assigning each one a charge might not be efficient. I am using no charges from cif file itself as modifying many MOFs with ILs liquid and such reduces the charges to zero with conversions.
#10
General / Training / Consulting preferab...
Last post by charlesfradley - July 01, 2026, 12:33:15 PMDoes anybody provide Ruptura Training / Consulting preferably in USA ?
Please send details to me at:
cradley@micro-a.net
Please send details to me at:
cradley@micro-a.net
SMF spam blocked by CleanTalk