Messages

Histograms do not really have units on the y-axis. The x-axis, for energy, would be Kelvin.
You can easily figure these things out by checking the source, and check what is exactly counted and how it is written out.
See source file: sample.c, and the function 'void SampleEnergyHistogram(int Switch)'.

Saving of snapshots is more easily done by adding them to a movie. But you could run short simulations and copy the restart-file saved at the end to another directory if the goal is to create many restart-files.

That is not possible. The atoms for the molecule file needs to be defined and the charge is taken from the pseudo_atoms.def file.
So, currently, the same type of atom of a molecule must have the same properties.

You could add your way of computing the pressure in the source code, or modify the implemented calculation of the pressure.

To reliably model adsorption/diffusion, the mobility of the cations needs to be taken into account. For example, in FAU there are many different cation-sites with certain "occupancy" ratios. Your cation model needs to be able to reproduce that.
That is why it is hard to reach an equilibrated system and it is a good idea to, when you have generated that, to store these positions in a restart-file.
Since cations are charged, the usual CBMC biasing can lead to numerical issues, but for single-atom cations you can achieve the same with a random-translation that tries to place the cation randomly in the box.
Look in the literature for papers on modeling of zeolites with cations for more pointers.

What do you mean with "there were no more than 2 number of adsorbent in each cycle", do you have multiple frameworks? do you mean "adsorbent" which is the framework, or "adsorbate" which means the molecules inside the framework.
"So I think something wrong about the water, maybe the increased charge of it in the MC simulation.", have you tried making it charge-neutral?

Are you comparing your simulation to other simulations or your simulations to experiments?
For the latter you need a bigger picture view and compare the simulated isotherm to the experimental one. Usually at some pressure the isotherm shoots up due to water-water clustering, but the details of where that happens depends on many factors (especially defects).
Also, the water-model is never perfect, nor is the force field in general.

Just use a cif-file describing your carbon-nanotube.

For combining VTK-densities and other VTK-files use the appropriate number of unit cells.

The simulation-length is set by specifying the NumberOfCycles (see the manual).

[pair]

The FH-LJ is a potential between a pair of atoms. There are no mixing rules for atoms that defined using different potential forms. But you can straightforwardly define the interactions of all pairs of atoms that you would like (see the manual).

Use the restart-file to start from the equilibrated systems (see manual).
You can take the results from different simulations and average them.

P1 is safer. Specifying the spacegroup is not unique, unless the Hall-symbols are used. Materials Studio and other codes do not do that. So, yes you can use symmetry, but if it does not work, it is usually because the space group is not set properly.
Using P1 avoids these issues.

You could change the source code to achieve that.
Look at the function 'int VolumeMove(void)' in mc_moves.c and change the isotropic scaling into only scaling in the z-direction.

In RASPA, the ensemble follows from the MC-moves.
So for NPT Gibbs you would use:
1) VolumeChangeProbability
2) GibbsSwapProbability
3) GibbsIdentityChangeProbability (assuming you have more than one component, otherwise you would use NVT-Gibbs).
4) thermalization moves like TranslationProbability, RotationProbability, ReinsertionProbability etc.

So the difference between NVT-Gibbs and NPT-Gibbs is that NVT-Gibbs uses a special volume move 'GibbsVolumeChangeProbability' so that the total volume is fixed. NPT-Gibbs uses the normal volume 'VolumeChangeProbability' that adjust each simulation box according to the specified pressure.