### Author Topic: Reduction of calculation effort by usage of block-pockets  (Read 1003 times)

#### SierraEcho

• Newbie
• Posts: 6
##### Reduction of calculation effort by usage of block-pockets
« on: April 12, 2022, 08:28:20 AM »
Dear raspa community,

currently, I am working on simulations within cylindrical pores. Due to the fact that I have a cylinder inside a cartesian cell, the corners, filled with framework atoms, contribute quite a lot
to the overall volume of the unit cell.

I assume that this non-void volume highly increases the necessary calculation time because an adsorptiv molecule could be placed there which results in the calculation of the LJ-potential for all atoms within the surrounding area. Obviously, this move will be rejected due to the high potential energy.
Here comes the idea: would it be possible to reduce the calculation effort by using a block-pocket file (exemplary marked as red circles). The necessary key information actually is if the block-pocket criteria is checked before the LJ-potential is calculated for a given MC-move.

#### David Dubbeldam

• Full Member
• Posts: 214
##### Re: Reduction of calculation effort by usage of block-pockets
« Reply #1 on: April 18, 2022, 07:47:20 PM »
Many of the moves use biasing (Multiple-first beads method). As soon as overlap is detected the move will be rejected.

Do you really need all the atoms outside the first cylindrical ring? If not, then you could
RestrictMovesToCylinder yes
and define a cylinder. Everything outside the cylinder will be considered an overlap.

#### SierraEcho

• Newbie
• Posts: 6
##### Re: Reduction of calculation effort by usage of block-pockets
« Reply #2 on: April 20, 2022, 05:14:09 PM »
My idea was to imitate the steel potential inside a cylindrical pore, however I agree that not so many layers are necessary.

With regard to computational effort, of course it would be way more elegant to define a fluid-wall forcefield like steel potential directly instead of calculating it through the backdoor by summing up
two-body interactions between an adsorbant molecule and the wall.  Nethertheless, directly using steel potential for slit, cylinder and sphere is not possible in raspa, right? Otherwise, I would highly appreciate any hints how I could make my simulation more elegant

Regarding "RestrictMovesToCylinder", this sounds reasonable to reduce CPU times. I couldn't find an example, neither in the manual nor in the internet. Therefore, I had a look at the plain C-Code.
For the sake of completeness:

Output-Creation:
fprintf(FilePtr,"\t\tcylinder center :                   %lf,%lf,%lf\n",Components.RestrictCylinderCenter[j].x,Components.RestrictCylinderCenter[j].y,Components.RestrictCylinderCenter[j].z);
fprintf(FilePtr,"\t\tcylinder direction :                %s\n",Components.RestrictCylinderDirection[j]==X_DIR?"X":(Components.RestrictCylinderDirection[j]==Y_DIR?"Y":"Z"));

I can't really figure out how to define a cylinder, I guess it should look somehow like:

RestrictMovesToCylinder yes
cylinder x y z x_dir y_dir radius

Your help with the cylinder definition would be highly appreciated!

#### David Dubbeldam

• Full Member
• Posts: 214
##### Re: Reduction of calculation effort by usage of block-pockets
« Reply #3 on: May 27, 2022, 02:06:08 PM »
With
grep RestrictMovesToCylinder *.c
you can see the files where it is used. Input is in 'input.c'.

So something like:
RestrictMovesToCylinder yes
Cylinder 0
CylinderCenter 0.5 0.5 0.5
CylinderDirection X

It is used in molecule.c
(grep RestrictCylinderDirection *.c)
In the routine:
int ValidCartesianPoint(int i, POINT pos);

#### SierraEcho

• Newbie
• Posts: 6
##### Re: Reduction of calculation effort by usage of block-pockets
« Reply #4 on: July 08, 2022, 11:18:05 AM »
Many thanks, got it working now!