Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SierraEcho

Pages: [1]
Many thanks, got it working now!

Input files and parameters / Re: two different temperatures
« on: April 22, 2022, 02:11:22 PM »
If you are using MC, the temperature is used to calculate the acceptance ratio. For example, the concept of temperature/velocity can not be extracted from MC as the trajectories don't follow physical laws (actually, there is no physical meaningful trajectory at all).

If your fluid-wall interaction is not temperature dependent an the adsorbent itself is rigid, changing the temperature of the adsorbent shouldn't even make a different for the result of your adsorbate.

Open for a fruitful discussion about that :)

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:

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"));
              fprintf(FilePtr,"\t\tcylinder radius :                   %lf\n",Components.RestrictCylinderRadius[j]);

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! :)

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.

Many thanks for your help!

General / Re: High-Pressure Simulations
« on: July 29, 2021, 02:40:33 PM »
Many thanks for the feedback, this really helped me to classify the results. Maybe I am going to try a full-atom model in future, just out of curiosity. In this case, I am going to share my results here for everybody else :)

General / High-Pressure Simulations
« on: July 12, 2021, 03:01:33 PM »
Dear RASPA-Community,

currently I am thinking to use RASPA in order to simulate some High-Pressure isotherms. Before starting with any kind of simulation in pores,
I thought it's a good idea to simulate both a rho-P (GCMC, supercritical) and a rho_T diagramm (Gibbs-Ensemble, subcritical).

To sum the results up: the subcritical results are good (as expected), but the high pressure results tend to have quite pronounced deviations (about 9% at 90 bar).

I was woundering about possible reasons for that, however I couldn't really come to a clear result. So my idea is that a: the mistake comes from the
use of the Peng-Robinson-EOS which is implemented as default EOS as far as I know b: at elevated pressure, it's not a valid assumption to neglect three-body
interactions anymore and/or the forcefield is not optimized for such high pressures. Is there anybody who conducted HP simulations and has an idea if
there is a possible solution or if a mistake of 9% is in spec at those elevated pressures?

Attached, you find my input file and a results plot.

Thanks for your input/help/ideas in advance :)

SimulationType                MonteCarlo
NumberOfCycles 50000
NumberOfInitializationCycles 50000
PrintEvery                    100

ContinueAfterCrash            no

ChargeMethod                  Ewald
Forcefield                    TraPPE
RemoveAtomNumberCodeFromLabel yes
Cutoff 12.8
EwaldPrecision                1e-6

Box 0
BoxLengths 30 30 30
ExternalTemperature 298
ExternalPressure 9e6

Movies no
WriteMoviesEvery 10000

Component 0 MoleculeName             methane
            StartingBead             0
            MolFraction              1
            MoleculeDefinition       TraPPE
            IdealGasRosenbluthWeight 1
            TranslationProbability   1
            RotationProbability      1
            ReinsertionProbability   1
            SwapProbability          1
            CreateNumberOfMolecules  0
            WidomProbability         0

Pages: [1]