News:

SMF - Just Installed!

Main Menu
Menu

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.

Show posts Menu

Messages - SierraEcho

#1
Many thanks, got it working now!
#2
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 :)



#3
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"));
              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! :)

#4
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!
#5
General / Re: High-Pressure Simulations
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 :)
#6
General / High-Pressure Simulations
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