Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixed bugs with kernel (re)compiling when the global device got clear and reinitialized #1752
This PR is to fix the bugs caused by the last PR #1735 when the global device is cleared (e.g., triggered by the clear command in the input script) and then initialized for a new run, as reported by @rbberger in #1748.
Trung Nguyen (Northwestern)
By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under either the GNU General Public License version 2 (GPL v2) or the GNU Lesser General Public License version 2.1 (LGPL v2.1).
Initialize ucl_device with NULL in the constructor of the base classes and then check if it is changed from the last value in init_atomic() after the device is (re)initialied: if so, recompile the kernels, otherwise skip the kernel recompilation.
Note: the OpenCL build still show a gradual increase in memory allocation if multiple consecutive runs are called. massif shows this is associated with libopencl.so, which is not so helpful. The recommended practice with this case (OpenCL builds and multiple consecutive runs) is to add "pre no" to the run command.
Note: the base classes (BaseAtomic, BaseCharge, etc.) need to be refactored to reduce duplicated codes.
Post Submission Checklist
Please check the fields below as they are completed after the pull request has been submitted. Delete lines that don't apply
@rbberger sorry I still don't understand why the example crashed with the latest changes for the jenkins regression. I have tried the changes on my machines, or applied them manually to the master branch, and it runs through in either cases. Is there anything I can do to resolve the issue? @akohlmey do you have any suggestions to move things forward? Thanks!
@sjplimp @rbberger @ndtrung81 since i cannot reproduce the reported remaining crashes on my machine, we are out of options to track this down by ourselves and have effectively the choice between two not perfect version. So it seems to me it would be best to merge this anyway and hope for getting some reports from other users or not(!) and then track things down with that input.