Box in cylindrical shape

[azam cheraghi]

I need a cylindrical shape box for my system and I found this:

classmethod from_matrix(box_matrix)

Create a box from an upper triangular matrix.

My question is that for making 

[[Lx, Ly * xy, Lz * xz],
[0,  Ly,      Lz * yz],
[0,  0,       L

does xy, xz and yz has to be tilits and L variables the length? Or it can be any upper triangular matrix? I need help with that because when I use cylindrical coordination, I can't get the second element of first column to be 0.

[Eric Irrgang]

> On May 5, 2023, at 10:44 AM, azam cheraghi <azamche...@gmail.com> wrote:
>
> I need a cylindrical shape box for my system and I found this:
> classmethod from_matrix(box_matrix)
> Create a box from an upper triangular matrix.
> My question is that for making
> [[Lx, Ly * xy, Lz * xz],
> [0, Ly, Lz * yz],
> [0, 0, L
>
> does xy, xz and yz has to be tilits and L variables the length? Or it can be any upper triangular matrix?

You can think of this sort of box matrix as the transformation matrix from lattice coordinates to cartesian coordinates. The periodic boundary conditions in simulators like HOOMD mimic the repeating unit cells in a crystal lattice. For convenience, and by convention, you are required to align your preferred simulation box geometry such that the first basis vector is aligned with the first Cartesian dimension, and such that the second basis vector is in the xy plane.

If you are embedding a cylindrical boundary in an orthonormal box, you shouldn't need to worry about such transformations.

> I need help with that because when I use cylindrical coordination, I can't get the second element of first column to be 0.

The box matrix is not a generalized coordinate transformation. It is specifically for relating crystallographic / lattice-like coordinate systems to the Cartesian coordinate system in which HOOMD does its computation. If you want to work in cylindrical coordinates, you will have to convert to and from Cartesian coordinates when interacting with hoomd.

[azam cheraghi]

Thanks  for the clarification. My box is not tilted so all xy, xz and yz are zero. It is aligned such that the circle is in the xy plane and the cylinder length is aligned with the z direction. The starting point is in the middle of the cylinder (0,0,0). Now based on that, if I just use Lx=r cos(\theta) and Ly = r sin(theta), It won't give me the circle if \theta doesn't change. I know I should give a range of 0 - 2\pi degree to the angle but I don't know how to merge it with hoomd.box, because in hoomd. from_matrix(box_matrix) there is only one matrix for the box, not a group of them.   

--
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/957F5576-1C23-415D-A5C1-37BF44F48774%40gmail.com.

[Eric Irrgang]

There is some sort of miscommunication here.

All HOOMD-blue simulation boxes are parallelepipeds representing "right-handed" coordinate systems, with the first edge aligned with the x axis. The simulation box is just used to apply periodic boundary conditions.

There is no cylindrical "box".

If you are trying to confine your system within a cylinder, you can embed a cylindrical "wall" in your simulation box: https://hoomd-blue.readthedocs.io/en/v3.11.0/module-hoomd-wall.html#hoomd.wall.Cylinder

Is this what you were looking at?

It sounds like what you want is a Cylinder aligned with the z axis in a tetragonal box. Using `axis=(0,0,1)`, the cylinder will be periodic on Lz. Make sure that Lx and Ly are sufficiently large compared to the cylinder radius that periodic images will not interact across the box boundaries with particles in the cylinder.

To perform any calculations (such as for generating your initial configuration), you will need to convert between your cylindrical coordinates and the HOOMD Cartesian coordinates.

If you were considering a different feature, I apologize for misunderstanding. Could you please clarify and provide links to the relevant documentation or sample code?

> To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/CAKfCtROgcn75vo1RYnszZF0qU_dD1aH%2BZp6nATSSPy23YRCfrw%40mail.gmail.com.

[azam cheraghi]

You are right, I wanted to confine my particle in a cylinder, but I am doing HPMC_NPT and when I change the volume of the box, the program totally skips the confinement and I am finding particles out of my cylindrical confinement. I asked about the issue before and one of the members said because the wall won't change by changing the box and you can't have it in your NPT, so you have to write your own code to confine particles. Well based on that I thought that if I define the shape of a box as a cylinder, that might help me, because I don't know where to start if I am going to write my own code while I am using Hoomd. The following is my current code that is not considering walls in my equilibrium configuration.

walls = [hoomd.wall.Cylinder(radius = 12, axis = (0, 0, 1), origin = (0.0, 0.0, 0.0), inside = True, open = True)]
wall_potential = hoomd.hpmc.external.wall.WallPotential(walls)
mc.external_potential = wall_potential
snapshot.configuration.box = [110, 110, 110, 0, 0, 0]
BoxMC = hoomd.hpmc.update.BoxMC(trigger = hoomd.trigger.Periodic(10), betaP = 1)
BoxMC.length = {'weight':0.2,'delta': (0, 0, 0.5)}
sim.operations.updaters.append(BoxMC)
periodic = hoomd.trigger.Periodic(10)

To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/3A8D49AC-36A0-45A8-BC53-A2995390D0D8%40gmail.com.

[Eric Irrgang]

Hi Azam.

> On May 5, 2023, at 6:48 PM, azam cheraghi <azamche...@gmail.com> wrote:
> ...

> I asked about the issue before and one of the members said

Ref: https://groups.google.com/g/hoomd-users/c/WyILaUMzAhw/m/R7mx6q28BQAJ

> because the wall won't change by changing the box and you can't have it in your NPT, so you have to write your own code to confine particles.

Yup.

> Well based on that I thought that if I define the shape of a box as a cylinder, that might help me

Nope. Sorry.

The suggestions you received previously look good, but non-trivial. After looking through the various examples/tutorials, you're probably going to have to spend some time reading the source code.

Good luck!

Best,
Eric

[Joshua Anderson]

Azam,

Your previous questions was on QuickCompress, this question is on NPT. While I suggested a QuickCompress implementation in Python, I do not think it is possible to implement NPT volume moves from the Python interface.

As Eric already explained, HOOMD-blue performs all simulations in periodic triclinic boxes. To enable the most general and flexible solution for the most users, walls are external potentials applied to the system and exist in a *non-periodic* space. The walls in HOOMD-blue are *not* connected to the box. The wall parameters do not change when the box changes and HOOMD-blue has no knowledge of the volume of the enclosed space - or whether you are using walls to even enclose a space. This is documented clearly as the wall documentation gives the surface of the wall as a function of the parameters you set.

You are asking for a completely different system where the parameters of the wall are somehow a function of the box size, there is a known enclosed volume, and walls share the periodicity of the box. HOOMD-blue does not implement such a scheme. If you wish to use one, you must write your own code to do so.

------

Joshua A. Anderson, Ph.D.

Research Area Specialist, Chemical Engineering, University of Michigan

--
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/327B0678-C4A7-401A-B6B7-206BE2B607A2%40gmail.com.