Messages

The form of OPLS_DIHEDRAL in the manual (eqn 3.52) and in the code has a constant term: (1/2)p0 and has three 1 +/- cos() terms with periodicities 1,2,3. All of the OPLS dihedral forms I see in the literature have no constant term and either the 3 cos terms or 4. Why the difference? If implementing OPLS FF / molecules, does anyone use the OPLS_DIHEDRAL form or do they use, e.g. the FOURIER_SERIES_DIHEDRAL (with p4 = p5 = 0 and usually p3 = 0 since only a few dihedrals have been published using the periodicity=4 term) form? Am I missing something?

Thanks for any help.

Hello Kajum,

It seems to me that block pockets only has an effect during Monte Carlo moves. So, in an MD simulation, when raspa is initially adding molecules to a framework to give the desired number, it will not allow their creation in blocked pockets. During MD however, if a molecule is able get into a pocket (a "side-pocket"), it will spend time there.

Why would want to block pockets in MD if the molecules are able to move into the pockets under normal circumstances given the structure, the force-field, and the conditions?

Blocking pockets is normally done on isolated pockets that don't communicate with accessible channels. If you want to block regions of a framework that are actually accessible during MD, then you have to decide where the boundary of the pocket is and your results will depend on the exact nature of what you block with. The blocking of isolated pockets during MC is somewhat different. If you fill the pocket with a hard-sphere, there will be a range of hard spheres that all give the same effect and do not modify anything happening outside the pockets.

The iRASPA-QT project is visible on github. What is the status? Is it usable on linux at this time?
Thanks.

Similar to my other post on .cif files, I'll report that I was only able to solve my .cif file problems by using the header from a working P1 .cif file (e.g. from the structures directory in the distribution), cutting out the coordinates, pasting in fractional coordinates for my system of interest, and modifying the cell parameters. I still do not know why some .cif files which work in other codes do not work in raspa, but it mentions somewhere in the manual or other documentation, that they can be tricky.

In the interest of closure, I'll report that I was only able to solve my .cif file problems by using the header from a working P1 .cif file (e.g. from the structures directory in the distribution), cutting out the coordinates, pasting in fractional coordinates for my system of interest, and modifying the cell parameters. Error messages of the type: "unknown: x" where x is one of the x,y, or z coordinates in the .cif file can occur when something is wrong (not compatible with raspa) with the other lines in the .cif.

What software do people use to successfully manipulate .cif files and get them to work with raspa? I've tried fairly simple things (like read in the FAU_SI.cif provided with raspa, convert it to P1, and export it back to .cif) and they seem to not work; sometimes with useful error messages and sometimes not. Besides Materials Studio which I don't have access to, what software works reliably? I've tried Avogadro and VESTA without success. They usually read each other's exported files or those included with raspa, but raspa does not read theirs. Does anyone have any tricks, hints, reports of idiosyncrasies, recommendations, or things to watch out for?

As an example (but I am really looking for general help), the FAU --> P1 in VESTA exercise above yielded the .cif shown below (and attached), but gave "ERROR in cif-file: no proper space group definition found" (after reporting tons of "unknown" lines) even though it has two lines relating to the space group. (Sorry: I couldn't get attachments to work).

#======================================================================

# CRYSTAL DATA

#----------------------------------------------------------------------

data_VESTA_phase_1


_chemical_name_common                  'FAU'
_cell_length_a                         24.34500
_cell_length_b                         24.34500
_cell_length_c                         24.34500
_cell_angle_alpha                      90
_cell_angle_beta                       90
_cell_angle_gamma                      90
_space_group_name_H-M_alt              'P 1'
_space_group_IT_number                 1

loop_
_space_group_symop_operation_xyz
   'x, y, z'

loop_
   _atom_site_label
   _atom_site_occupancy
   _atom_site_fract_x
   _atom_site_fract_y
   _atom_site_fract_z
   _atom_site_adp_type
   _atom_site_B_iso_or_equiv
   _atom_site_type_symbol
   O1         1.0     0.895800      0.104200      0.000000     Biso  1.000000 O
...

Thanks for any help.

Thanks for looking into this. The input and .cif files can be taken from my original post (the three atoms shown give similar behavior as a larger number of atoms). This force-field.def file is the one supplied in the latest version of the download. I've done nothing to modify any .def file.

I converted to fractional coordinates by hand, removed the "ReadCIFAsCartesian yes" command, and the same behavior occurs: lots of "unknown" lines to stderr and only one FW atom appears @ 0,0,0. Any other advice? Thanks.

Maybe. The manual says you can use Cartesian coordinates for P1 and I've used the "ReadCIFAsCartesian yes" command in the input file. It is off-topic, but I can't get openbabel to convert this file to fractional coordinates.  Thanks.

[one can see that only one framework atom (@ 0,0,0) was used in the simulation]

Summary: Large number of FW atoms in .cif file, but simulation only uses 1 of them and at position 0,0,0. What is wrong with .cif or input file?
Warning: Stage 0 Newbie with respect to raspa.

I'm using a bunch of Argon atoms in a P1 40x40x40 box as a "Framework": just a bunch of fixed LJ atoms via the Garcia Perez FF. The simulation attempts gcmc of methane in this framework.  The .cif was made in Avogadro / openbabel after creating the atom positions elsewhere. Here is the top of the .cif:
--------------------------------------------------------------------------------------------
# CIF file generated by openbabel 2.3.2, see http://openbabel.sf.net
data_I
_chemical_name_common 'box6_ar.pdb'
_cell_length_a 40
_cell_length_b 40
_cell_length_c 40
_cell_angle_alpha 90
_cell_angle_beta 90
_cell_angle_gamma 90
_space_group_name_H-M_alt 'P 1'
_space_group_name_Hall 'P 1'
loop_
    _symmetry_equiv_pos_as_xyz
    'x,y,z'
loop_
    _atom_site_type_symbol
    _atom_site_label
    _atom_site_Cartn_x
    _atom_site_Cartn_y
    _atom_site_Cartn_z
     Ar   Ar1    19.87500    0.95800   36.89600
     Ar   Ar2    29.92900    6.71600   36.71700
     Ar   Ar3     6.11900    9.36600    1.67600
...
--------------------------------------------------------------------------------------------

And I'm using this simple input file (which started life as one of the Basic examples):

--------------------------------------------------------------------------------------------
SimulationType                MonteCarlo
NumberOfCycles                5000
NumberOfInitializationCycles  1000
PrintEvery                    1000

Forcefield                    GarciaPerez2006

RemoveAtomNumberCodeFromLabel yes
ReadCIFAsCartesian yes
UseChargesFromCIFFile no

Framework 0
FrameworkName box6_ar
ExternalTemperature 300.0
ExternalPressure 1e8

Component 0 MoleculeName             methane
            MoleculeDefinition       TraPPE
            TranslationProbability   0.5
            ReinsertionProbability   0.5
            SwapProbability          1.0
            CreateNumberOfMolecules  0
--------------------------------------------------------------------------------------------

When the simulation is run, this is the start of what is printed to stderr:

--------------------------------------------------------------------------------------------
_cell_length_a: 40.000000
_cell_length_b: 40.000000
_cell_length_c: 40.000000
_cell_length_alpha: 90.000000
_cell_length_beta: 90.000000
_cell_length_gamma: 90.000000
space group found from symmetry elements: 1 (nr elements: 1)
unknown: 19.87500
unknown: 0.95800
unknown: 36.89600
unknown: 29.92900
unknown: 6.71600
...
--------------------------------------------------------------------------------------------

There is a separate one of these "unknown" lines for each x, y, and z coordinate in the .cif file.

The simulation runs "fine", but from the _final.pdb etc. files in the Movies directory or from the output, one can see that only one framework atom (@ 0,0,0) was used in the simulation.

What is my problem (at least related to this simulation...)?
Thanks.