Posts

• ---

  Out of Memory Error during CPKS Calculation for Large System (400+ atoms)
  undefined GiacomoAmbrogio

  Hi Gryffindor,

  The only way to improve memory management without compromising the calculation parameters, as Alessandro correctly pointed out, would be to run with a lower number of MPI processes.

  If you don’t want to "waste" CPU cores in the process, the openMP version of the code shoud be compatible with CPHF/CPKS. You just need to export OMP_NUM_THREADS according to the number of MPI processes used, ensuring that:

  CPU cores = MPI processes × OMP_NUM_THREADS

  By doing so, you should be able to fully exploit all resources while optimizing memory usage more effectively. Some references can be found in the tutorial and on the CRYSTAL23 paper.

  Hope this helps!

• ---

  Out of Memory Error during CPKS Calculation for Large System (400+ atoms)
  undefined aerba

  Hi,

  The CPKS implementation in PCRYSTAL is parallelized according to a replicated-data strategy, which means that each process has a copy of the main arrays. Assume that each process (usually coinciding with each CPU core) allocates X GB of memory. If you run the job over n CPU cores in the same node, the total amount of required memory on the node will be nX.

  So, one way to reduce the memory requirement of a replicated-data calculation is to lower the number of used CPU cores per node.

  As an example, if you have a node with 128 CPU cores, try running the calculation on just 64 or 32 cores, making sure no other processes are executed on the node at the same time. This would effectively increase the available memory.

  Hope this helps.

• ---

  Error reading end of file when visualizing Raman vibrational modes
  undefined aerba

  Hi,

  We have found a workaround that allows you to visualize animations of normal modes from CRYSPLOT also from a FRAGMENT calculation.

  1. Go to CRYSPLOT and from the "Make a Plot" menu select "Geometry Structure" (bottom-right)

  

  2. Select and upload your output file (.out)

  3. By right-clicking with your mouse select "Vibration" and set it to "On":

  

  4. At this point, by right-clicking with your mouse select "Model x/23" and select desired Mode from list to animate it:

  

  Hope this helps

• ---

  R2SCAN not implemented with UHF or incompatible with EOS?
  undefined GiacomoAmbrogio

  Hi job314,

  I tried to run your input (without the RESTART keyword), and it seems to work fine.
  Can you double-check the file used for the restart? Or eventually, can you try run the code without RESTART?

  Anyway, the proper way to perform a spin-polarized calculation in DFT is to use the SPIN keyword in the DFT block instead of UHF (but technically, both should work):

  [...]
  DFT
  SPIN
  R2SCAN
  XLGRID
  ENDdft
  [...]
  

• ---

  Error reading end of file when visualizing Raman vibrational modes
  undefined aerba

  job314 only for FRAGMENT calculations. See my reply below/above.

• ---

  Error reading end of file when visualizing Raman vibrational modes
  undefined aerba

  Hi,

  We've been running some tests. This is what we found: Vibration Mode Animations on CRYSPLOT are run through JSmol, which does not seem to correctly read a CRYSTAL output file if the option FRAGMENT is used. Without FRAGMENT everything works fine.

  We could read your FRAGMENT output file and correctly visualize animations of the modes by using the MOLDRAW package instead.

• ---

  Frequency calculation of very large systems
  undefined aerba

  Hi,

  I think that the best way to proceed in this case would be to restart the calculation one or more times. To do this, you just have to make sure that the scratch folder is not deleted when the calculation stops. Basically, you would run a first job with:

  FREQCALC
  END
  

  Then, after the first calculation stops (maybe because you reached a wall clock time limit) you would run a second job restarting from the first as:

  FREQCALC
  RESTART
  END
  

  In order to make this restart work, you need a few files from the previous job to be placed in the scratch folder of the new job: FREQINFO.DAT, fort.13 and fort.9 (to be renamed fort.20 in the new folder).

  If needed, you can repeat this restart process multiple times until completion of the frequency calculation.

  Hope this helps,

• ---

  geometry optimization runs out of cycles
  undefined aerba

  Hi,

  I have looked at the code and figured out what is going on. Let me explain what is happening first. I'll then offer a solution below.

  You are running a pre-optimization within a frequency calculation + Raman intensity calculation (via the CPHF/KS approach):

  FREQCALC
  FRAGMENT
  19
  9 106 131 175 191 192 193  194 195 196 197 198 199 200 201 202 203 204 205
  PREOPTGEOM
  RESTART
  MAXCYCLE
  700
  ATOMONLY
  END
  INTENS
  INTRAMAN
  INTCPHF
  END
  END
  

  It turns out that the same variable is used in the code to define the maximum number of optimization steps and the maximum number of cycles in the CPHF/KS process. The default maximum number of cycles for CPHF/KS for intensity calculations is 200. Thus what happens is that with MAXCYCLE you set it to 700 but when the INTCPHF keyword is read it is internally re-set to the default of 200.

  Clearly, this is not ideal! We are going to fix it in future versions.

  Luckily, there is a simple workaround. Everything is fine if you run a geometry optimization first, then followed by a subsequent frequency calculation starting from the optimized geometry.

  The first calculation would look something like:

  OPTGEOM
  ATOMONLY
  MAXCYCLE
  700
  END
  

  And the second one (from the optimized geometry obtained at the previous step) would be:

  FREQCALC
  FRAGMENT
  19
  9 106 131 175 191 192 193  194 195 196 197 198 199 200 201 202 203 204 205
  INTENS
  INTRAMAN
  INTCPHF
  END
  END
  

  Hope this helps

• ---

  Input MOF geometry problem
  undefined GiacomoAmbrogio

  Hi ywang,

  We managed to resolve the problem with your input file. The issue was that the system was not standardized according to the space group.

  It should be possible to tell the program that the structure is not standard through a specific keyword. However, an alternative approach is to manually modify the CIF file. This can be done using VESTA, please refer to the image.

  

  The new input geometry look like this:

  Fe_complex
  CRYSTAL
  0 0 0
  225
  26.7506
  6
  8  0.05353    0.18260    0.24189
  26 0.50000    0.21143    0.21143
  6  0.20297    0.20297    0.07018
  6  0.17805    0.17805    0.11438
  6  0.13562    0.13562    0.19929
  1  0.12115    0.12115    0.22832
  ENDgeom
  

  Fe.d12

  This has also reduced the number of symmetry-irreducible atoms, so the calculation should be a bit faster.

• ---

  Input MOF geometry problem
  undefined GiacomoAmbrogio

  Hi ywang,
  I managed to print the error for your input, which is:

  ERROR **** GROTA1 **** ERROR IN SYMMETRY EQUIVALENCE - CHECK INPUT COORDINATES
  
  

  Unfortunately, it is not very descriptive.

  It seems there may be an issue with the initial geometry. Could you share more details about your system? Do you have a .cif file from which you generated the CRYSTAL input?