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 - Julian Schneider

Pages: [1] 2 3 ... 11
1
Hi Nils,

which version of QuantumATK are you using?
We have tested it among others on A100 and V100 GPUs without problems, therefore I would say it is unlikely the compute version, but we need to investigate more.

Best regards,
Julian

2
General Questions and Answers / Re: M3GNet error
« on: April 25, 2024, 08:49 »
Hi Asif,

this is a known problem when using the CombinedCalculator with 2 FF calculators, unfortunately. We have also encountered it recently.
We will fix it for the next release, by integrating the M3GNet and D3 dispersion more closely.

Unfortuntely we don't know of a real workaround for it right now.


3
Dear Asif,

We will check and get back to you.

4
Hi Nils,

You are correct that ML-FFs are commonly based on the assumption that the total energy is a sum of the energies of each atomic environment.
Unfortunately, we currently do not support atomic energy as an analysis quantity that can be extracted from the calculation.
In order to make a better decision if we should support this analysis in the future, could you maybe give us more input into the application for which you would like to use it?

Best regards,
Julian

5
General Questions and Answers / Re: M3GNET
« on: February 28, 2024, 22:26 »
The log shows only the CPU processes and threads, not the CUDA cores.

If you have more CPU cores, you can increase the OMP_NUM_THREADS to use more threads, which will normally speed-up the CPU part simulation, but it does not neccessarily speed-up the GPU part.

6
It is our experience that the MTP trained on crystal displacements alone is sufficient, and can describe crystals in MD at moderate temperatures very well without active learning in almost all cases.

If you are unsure, you could run some MTP simulations of small systems, check that the simulation runs stable, and compare the forces from MTP with forces from DFT on a few snapshots from this simulations. The error should be similar to the training / testing error of the MTP.

7
This is a bug that we have fixed for the upcoming service pack.
To work around it in the current version please use the calculator in the attached file (which has been egenrated by exporting to script with "Report All" and in the script replacing Angstrom**4 by Angstrom**5 in the Stiwe2Potential() definitions).

8
General Questions and Answers / Re: Error on Cluster
« on: February 9, 2024, 17:47 »
The M3GNet implementation in QuantumATK currently only supports running on a single GPU and with a 1 MPI process (the case that works nicely for you).

When running on CPU only you should set device='cpu'. We found an issue when running on a node that does not support CUDA with device='cuda', the automatic fallback to CPU does not work. We will fix that in the upcoming service pack.

9
General Questions and Answers / Re: Phonon spectrum error
« on: February 5, 2024, 10:24 »
We could run the calculation on our side without error, so it does not seem like a bug. It looks like in your case it goes wrong when using the symmetries. We are still investigating what it could be.

In the meantime, I would recommend to run the calculation with setting
Code
use_symmetry=False
in the DynamicalMatrix.

You can actually try to run it on the same file, ideally it should only do the missing displacement calculations of the equivalent atoms, but re-.use the already calculated atom displacements.

10
General Questions and Answers / Re: M3GNET
« on: January 30, 2024, 09:01 »


To include vdW interactions, it is posssible to combine the M3GNet calculator with a D3-dispersion correction (in analogy to what one would in a DFT calculation for such a system). The calculator would look like this:



Code
calculator_m3gnet = TremoloXM3GNetDirectPESCalculator(device='cpu') 
calculator_d3 = TremoloXCalculator(parameters=DispersionD3Z(xc='PBE'))
calculator = CombinedCalculator([calculator_m3gnet,calculator_d3])

11
General Questions and Answers / Re: M3GNET
« on: January 30, 2024, 08:59 »
With OMP-threading I mean multi-core threading, so using as many cores as you have threads. Then you should see an increase in performace. I have tested it and I could see a decrease in simulation time with increasing number of cores / OMP-threads. The actual speedup may depend on the size of the system.

12
I tried running your script and it seems to run ok in principle. So it could be that it just runs out of memory on your computer and it looks like this is happening during the DFT calculations of the training data.
It looks like you have already tried most of the options to reduce memory by distributing across more nodes.
Apart from that it might be possible to reduce the memory a bit by deleting the calculator state of the optimized configurations, as shown in the attached script.
Also, it seems that the ParallelCG solver you use for the poisson equation uses a bit more memory than the default FFT solver, so changing that could also help a bit, unless you have a specific reason for using that solver.


13
General Questions and Answers / Re: M3GNET
« on: January 16, 2024, 09:41 »
Dear Asif,

The M3GNet calculator does currently not support parallelization over multiple cores via MPI. Instead you could use OMP threading to parallelize over the cores.
In the job manager you can do it as shown in the attached screenshot (assuming you are running on 8 cores).

From the terminal, one would do it like this:
Code
# Define the number of threads to use
export OMP_NUM_THREADS=8
export MKL_NUM_THREADS=8
mpiexec -n 1 atkpython my_script.py


14
General Questions and Answers / Re: M3GNET
« on: January 12, 2024, 22:07 »
Good to hear that it works!
I can understand that the warning can be misleading and we will work on improving that.

Best regards,
Julian

15
General Questions and Answers / Re: M3GNET
« on: January 11, 2024, 20:55 »
Dear Asif,

this message is not necessarily pointing towards an error in the calculation, it just means that the CUDA drivers cannot be initialized.
It could still be that the calculation ran through fine, especially since your calculation ran M3GNet on CPU only.
Could you please double check if the calculations completed ok (meaning that the results files are there and no other error message is written to the log)?
If there are other error messages or a traceback in the log, could you please report them here, then we can let you know how to fix it?

Pages: [1] 2 3 ... 11