ocladock issueshttps://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues2018-09-03T12:15:08Zhttps://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/34Initial genotype for testing should be done with a single work-item2018-09-03T12:15:08ZLeonardo SolisInitial genotype for testing should be done with a single work-itemWhen `DEBUG_INITIAL_2BRT` is enabled, then initialize `genotype` using a single work-item.
[This was initially set using all work-items](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/169ca1f5eafba3c1701733a6b9c053330f...When `DEBUG_INITIAL_2BRT` is enabled, then initialize `genotype` using a single work-item.
[This was initially set using all work-items](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/169ca1f5eafba3c1701733a6b9c053330ffa851b/device/kernel_sd.cl#L169), but it is not necessary.Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-09-07https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/32Wrong read/write configuration of memory object2018-08-13T13:27:46ZLeonardo SolisWrong read/write configuration of memory objectThis error was pointed by [oclgrind](https://github.com/jrprice/Oclgrind/wiki/Using-Oclgrind) in [kernel4](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel4.cl):
```zsh
Invalid write to read-only buf...This error was pointed by [oclgrind](https://github.com/jrprice/Oclgrind/wiki/Using-Oclgrind) in [kernel4](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel4.cl):
```zsh
Invalid write to read-only buffer
Kernel: gpu_gen_and_eval_newpops
Entity: Group(47,0,0)
call spir_func void @_Z17wait_group_eventsiP9ocl_event(i32 1, %opencl.event_t** nonnull %ev171) #9, !dbg !449
At line 2097 (column 3) of input.cl:
wait_group_events(1,&ev);
```
So `mem_dockpars_conformations_current` must be configured as `CL_MEM_READ_WRITE`,
and **NOT** just for reading as in [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/performdocking.cpp#L349)
and in [debugfastergrad](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/host/src/performdocking.cpp#L390)
Although the source code in `kernel4` never updates this memory object, it actually updates it in every other genetic iteration because populations are updated by switching pointers as in [here](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/performdocking.cpp#L710).Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/31Missing synchronization after asynchronous copies?2018-08-13T13:49:56ZLeonardo SolisMissing synchronization after asynchronous copies?This error was found with [oclgrind](https://github.com/jrprice/Oclgrind/wiki/Using-Oclgrind)
and points to the last asynchronous copies in [kernel4](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/devic...This error was found with [oclgrind](https://github.com/jrprice/Oclgrind/wiki/Using-Oclgrind)
and points to the last asynchronous copies in [kernel4](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel4.cl) and
[kernel_gradient](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel_gradient.cl):
```zsh
Work-item finished without waiting for events.
```
Other kernels might suffer from this too:
* See [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel4.cl#L296) -> `kernel3` and `kernel4`.
* See [debugfastergrad](https://git.esa.informatik.tu- darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel4.cl#L311) -> `kernel3`, `kernel4`, `kernel_gradient`, and `kernel_fire`.
Keep in mind the following information from the [v2.0 standard](https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/async_work_group_copy.html):
> **This function does not perform any implicit synchronization of source data such as using a barrier before performing the copy.**
>**The kernel must wait for the completion of all async copies using the wait_group_events built-in function before exiting; otherwise the behavior is undefined.**Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/30Memory space of constant kernel arguments should be re-qualified2018-08-14T18:02:20ZLeonardo SolisMemory space of constant kernel arguments should be re-qualifiedThe maximum allowed size for constant arguments varies for each device, e.g.:
AMD Vega56 GPU has 4.2 GB:
```zsh
ULong attributes ...
1 CL_DEVICE_MAX_MEM_ALLOC_SIZE : 4244635648
1 CL_DEVICE_GLOBAL_MEM_CACHE_SIZE...The maximum allowed size for constant arguments varies for each device, e.g.:
AMD Vega56 GPU has 4.2 GB:
```zsh
ULong attributes ...
1 CL_DEVICE_MAX_MEM_ALLOC_SIZE : 4244635648
1 CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 16384
1 CL_DEVICE_GLOBAL_MEM_SIZE : 8573157376
1 CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 4244635648
1 CL_DEVICE_LOCAL_MEM_SIZE : 32768
```
NVidia M2000 GPU has 16.7 MB:
```zsh
ULong attributes ...
1 CL_DEVICE_MAX_MEM_ALLOC_SIZE : 8589934592
1 CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : 20971520
1 CL_DEVICE_GLOBAL_MEM_SIZE : 31497080832
1 CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE : 16777216
1 CL_DEVICE_LOCAL_MEM_SIZE : 16777216
```
As all constant kernel arguments were qualified as `__constant`, the program might be allocating more data than what fits in the constant buffer. Perhaps this is handle automatically by the compiler, i.e., it might be moving this extra data to global memory.
However, this is signalled as an error by [oclgrind --check-api](https://github.com/jrprice/Oclgrind/wiki/Using-Oclgrind):
```zsh
Oclgrind - OpenCL runtime error detected
Function: clEnqueueNDRangeKernel
Error: CL_OUT_OF_RESOURCES
total constant memory size (252528) exceeds device maximum of 65536
Error: clEnqueueNDRangeKernel() -5
Oclgrind - OpenCL runtime error detected
Function: clEnqueueNDRangeKernel
Error: CL_OUT_OF_RESOURCES
total constant memory size (297680) exceeds device maximum of 65536
Error: clEnqueueNDRangeKernel() -5
```
A solution for this is evaluating the amount of data being passed to kernel, and then re-qualifying arguments either as `__constant` or `__global const`.
For size definitions see [ref1](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/common/defines.h#L42) and [ref2](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/inc/processligand.h#L32).
The calculation of sizes is as follows. Originally, each of these is passed as a separate `__constant` argument from host to kernel. Here, these are listed in groups for convenient data-passing from host to device (see kernel codes in commits below).
_`interintra`_ (subtotal size: 1280)
| Constant array | Size definition | Size calculation | Size in Bytes |
|:-----------------------|:-----------------------------------------------------|:-----------------|--------------:|
| atom_charges | MAX_NUM_OF_ATOMS * sizeof(float) | 256 * 4 | 1024 |
| atom_types | MAX_NUM_OF_ATOMS * sizeof(char) | 256 * 1 | 256 |
_`intracontrib`_
| Constant array | Size definition | Size calculation | Size in Bytes |
|:-----------------------|:-----------------------------------------------------|:-----------------|--------------:|
| intraE_contributors | 3 * MAX_INTRAE_CONTRIBUTORS * sizeof(char) | 3 * 256 * 256 * 1| 196608 |
_`intra`_ (subtotal size: 2032)
| Constant array | Size definition | Size calculation | Size in Bytes |
|:-----------------------|:-----------------------------------------------------|:-----------------|--------------:|
| reqm | ATYPE_NUM * sizeof(float) | 22 * 4 | 88 |
| reqm_hbond | ATYPE_NUM * sizeof(float) | 22 * 4 | 88 |
| atom1_types_reqm | ATYPE_NUM * sizeof(unsigned int) | 22 * 4 | 88 |
| atom2_types_reqm | ATYPE_NUM * sizeof(unsigned int) | 22 * 4 | 88 |
| VWpars_AC | MAX_NUM_OF_ATYPES * MAX_NUM_OF_ATYPES * sizeof(float)| 14 * 14 * 4 | 784 |
| VWpars_BD | MAX_NUM_OF_ATYPES * MAX_NUM_OF_ATYPES * sizeof(float)| 14 * 14 * 4 | 784 |
| dspars_S | MAX_NUM_OF_ATYPES * sizeof(float) | 14 * 4 | 56 |
| dspars_V | MAX_NUM_OF_ATYPES * sizeof(float) | 14 * 4 | 56 |
_`rotlist`_
| Constant array | Size definition | Size calculation | Size in Bytes |
|:-----------------------|:-----------------------------------------------------|:-----------------|--------------:|
| rotlist | MAX_NUM_OF_ROTATIONS * sizeof(int) | 256 * 32 * 4 | 32768 |
_`conform`_ (subtotal size: 19840)
| Constant array | Size definition | Size calculation | Size in Bytes |
|:-----------------------|:-----------------------------------------------------|:-----------------|--------------:|
| ref_coords_x | MAX_NUM_OF_ATOMS * sizeof(float) | 256 * 4 | 1024 |
| ref_coords_y | MAX_NUM_OF_ATOMS * sizeof(float) | 256 * 4 | 1024 |
| ref_coords_z | MAX_NUM_OF_ATOMS * sizeof(float) | 256 * 4 | 1024 |
| rotbonds_moving_vectors| 3 * MAX_NUM_OF_ROTBONDS * sizeof(float) | 3 * 32 * 4 | 384 |
| rotbonds_unit_vectors | 3 * MAX_NUM_OF_ROTBONDS * sizeof(float) | 3 * 32 * 4 | 384 |
| ref_orientation_quats | 4 * MAX_NUM_OF_RUNS * sizeof(float) | 4 * 1000 * 4 | 16000 |
A total of 252528 Bytes is required for constant data, which is a much smaller size than the minimum in the available GPUs.
For debugfastergrad, we require the following arrays as well:
_`gradsrotbonds`_
| Constant array | Size definition | Size calculation | Size in Bytes |
|:---------------------|:-----------------------------------------------------|:-----------------|--------------:|
|rotbonds_atoms |MAX_NUM_OF_ATOMS * MAX_NUM_OF_ROTBONDS * sizeof(int)| 256 * 32 * 4 | 32768 |
_`grads`_ (subtotal size: 12384)
| Constant array | Size definition | Size calculation | Size in Bytes |
|:---------------------|:-----------------------------------------------------|:-----------------|--------------:|
|rotbonds |2 * MAX_NUM_OF_ROTBONDS * sizeof(int) | 2 * 32 * 4 | 256 |
|num_rotating_atoms_per_rotbond |MAX_NUM_OF_ROTBONDS * sizeof(int) | 32 * 4 | 128 |
|angle |1000*sizeof(float) | 1000 * 4 | 4000 |
|dependence_on_theta |1000*sizeof(float) | 1000 * 4 | 4000 |
|dependence_on_rotangle |1000*sizeof(float) | 1000 * 4 | 4000 |
A total of 297680 (252528 + 45152) Bytes is required for constant data, which is a much smaller size than the minimum in the available GPUs.Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-17https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/29Memory object mapped for reading should be unmapped before a kernel writes to it2018-08-13T14:02:52ZLeonardo SolisMemory object mapped for reading should be unmapped before a kernel writes to itDetected with [oclgrind](https://github.com/jrprice/Oclgrind).
According to the [clEnqueueMapBuffer documentation](https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clEnqueueMapBuffer.html):
>>>
If a memory object is curre...Detected with [oclgrind](https://github.com/jrprice/Oclgrind).
According to the [clEnqueueMapBuffer documentation](https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clEnqueueMapBuffer.html):
>>>
If a memory object is currently mapped for reading, the application must ensure that the memory object is unmapped before any enqueued kernels or commands that write to this memory object or any of its associated memory objects (sub-buffer or 1D image buffer objects) or its parent object (if the memory object is a sub-buffer or 1D image buffer object) begin execution; otherwise the behavior is undefined.
>>>
The maps perfomed in [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/performdocking.cpp#L615)
and in [debugfastergrad](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/host/src/performdocking.cpp#L854)
branches are followed by`kernel2` executions as in [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/performdocking.cpp#L689) and
[debugfastergrad](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/host/src/performdocking.cpp#L942).
Such [kernel2](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel2.cl) writes that memory object.
Therefore, the aforementioned map call should be followed by an unmap call before kernel2 is invoked (or any kernel that writes to the memory object being mapped).Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/28Ambiguous usage of native_exp()2018-08-13T12:51:04ZLeonardo SolisAmbiguous usage of native_exp()Detected with [oclgrind](https://github.com/jrprice/Oclgrind).
Large constant coefficients might be considered as of double type by the compiler. Data derived from these coefficients can be treated as double too. If so, such data will n...Detected with [oclgrind](https://github.com/jrprice/Oclgrind).
Large constant coefficients might be considered as of double type by the compiler. Data derived from these coefficients can be treated as double too. If so, such data will not be valid arguments for `native_*()` functions as in [here](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/calcgradient.cl#L712).
Therefore, such constant coefficients have be expressed with fewer decimal points so they are treated as float by any compiler.Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/27Unused variable for gradient-based docking in host code2018-08-13T12:38:07ZLeonardo SolisUnused variable for gradient-based docking in host codeIn debugfastergrad branch, the structure of `Gradientparameters` type declared [here](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/host/src/performdocking.cpp#L475) should be removed.
In debugfastergrad branch, the structure of `Gradientparameters` type declared [here](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/host/src/performdocking.cpp#L475) should be removed.
Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/26Wrong number of elements is copied with async_work_group_copy in kernel12018-08-13T12:26:14ZLeonardo SolisWrong number of elements is copied with async_work_group_copy in kernel1[This instruction in "debugfastergrad" branch](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel1.cl#L85)
copies `GENOTYPE_LENGTH_IN_GLOBMEM` elements from global memory into the local array ...[This instruction in "debugfastergrad" branch](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel1.cl#L85)
copies `GENOTYPE_LENGTH_IN_GLOBMEM` elements from global memory into the local array `genotype[ACTUAL_GENOTYPE_LENGTH]`.
However, such array is [defined with a size smaller than what is copied into it](
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel1.cl#L71).
Therefore, the aforementioned instruction should copy `ACTUAL_GENOTYPE_LENGTH` instead of `GENOTYPE_LENGTH_IN_GLOBMEM`.Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/25Excessively large array in kernel22018-08-13T12:16:04ZLeonardo SolisExcessively large array in kernel2The array `__local int local_evals_of_new_entities[MAX_POPSIZE]` used in [master](
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel2.cl#L50) and
[debugfastergrad](https://git.esa.informatik.tu-darmst...The array `__local int local_evals_of_new_entities[MAX_POPSIZE]` used in [master](
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/device/kernel2.cl#L50) and
[debugfastergrad](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel2.cl#L44) is excessively large:
[2048 elements](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/common/defines.h#L47).
Such array should be removed, and related accesses should be performed from global memory directly.
Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/24Remove unnecessary local memory declaration2018-07-31T13:33:59ZLeonardo SolisRemove unnecessary local memory declarationhttps://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel_gradient.cl#L155https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/debugfastergrad/device/kernel_gradient.cl#L155Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-08-03https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/15Add smoothing to internal-energy potentials2018-05-10T11:43:45ZLeonardo SolisAdd smoothing to internal-energy potentialsExplanation:
Just checked the effect of the smooth parameter on the intra energy.
On a large ligand (2er7) in an fairly extended conformation (i.e. the
ligand is not folding onto itself), the intra energy with smooth=0.5
is -9 kcal. How...Explanation:
Just checked the effect of the smooth parameter on the intra energy.
On a large ligand (2er7) in an fairly extended conformation (i.e. the
ligand is not folding onto itself), the intra energy with smooth=0.5
is -9 kcal. However, using smooth=0.0 the intra energy is -5
kcal. This explains the different results between autodock and
ocladock for ligands with many torsions.
----
Q:
Do you mind running some more tests on other bigger complexes too
(e.g. 2er7, 3er5, 4er4) to see if that happens as well? Let me know if
you can do it. Also, I assume you would need the atom-contributor
pairs for each complex, wouldn't you?
By the way, I have just checked (in *.gpf and *.gpf) that I created
the grids with the default smooth parameter (=0.5A) so I guess this
would explain why we had no significant discrepancies on that.
A:
I don't need the pairs because I'm using the original AutoDock4.2 - I
just change the smooth parameter in the .dpf file. It only affects the
pairwise contributions, the grids remain unchanged.
Here are the intra energies for the complexes you asked about:
complex, smooth=0.5, smooth=0.0
2vaa, -7.64, -5.45
3er5, +12.66, +93.78
4er4, -9.84, -6.51
-----
Q:
I see the difference. Did you implement this in autodockdevpy?. If so, I
could reuse for ocladock ... thanks!
A:
Yes, it's implemented, but it's disabled in branch "ocladockenergy". Look in branch "dev".
In files pairwise_energies.py and pairwise_derivatives.py, it's implemented in function "_calc_smooth()", which modifies the distance before evaluating 'vdw' and 'hb' energy contributions.
I don't know how important it is to implement this smooth parameter. I'll try to figure it out with Stefano and gather other opinions from other people in the lab.
-----
Q:
I have just checked the python code of "_calc_smooth()", and doesn't seem complex to implement in OpenCL. The only doubt I have is the meaning of "r" and "rij" and their relationship.
Anyway, let me know what you guys think about including this function.
A1:
"r" is a variable: it's the current distance between two atoms during the docking.
"rij" is a parameter: it's the optimum distance for the pair (e.g.: "rij" for C - C is 4 angstroms).
A2:
I just talked with Stefano and David about the smooth parameter.
The smooth parameter is important for the grids, we know that for sure. However, it is unclear how important it is for the pairwise interactions. According to the user guide (*), it was only added to pairwise interactions in version 4.2.5.
However, for the sake of publication, it would be beneficial to have a direct comparison with the current AutoDock version, so we recommend it's implementation. It would be even better if it could be a user specified argument either at run time or a compilation argument.
(*) http://autodock.scripps.edu/faqs-help/manual/autodock-4-2-user-guide/AutoDock4.2_UserGuide.pdf (see page 6)
------
Q:
Ok, then I will start implementing it.
A technical question: I assume "rij" (optimum distance) depends on the atoms types, doesn't it?
Do you know where, either in "autodockdevpy" or AD4, I can find the "rij" values ?
A:
Yes, rij is the sum of vdW radii for the atom pair. It's calculated as 0.5 * rii + 0.5 * rjj, because rii an rjj are twice the vdW radii. The rij values must be already present in OCLADock, because they are needed to calculate C12 and C6 for vdW, and C12 and C10 for hydrogen bonds. It's probably a matter of storing them along C12, C10 and C6 for use in the energy evaluation.
------
Q:
Regarding the smooth parameter to be specified as a user-specified argument:
In the AD4.2 documentation, it says the force field has been optimized
for a smooth value = 0.5A. So, I am setting this as the default smooth
value.
But, I was wondering it such parameter has lower and upper bounds. Can
you suggest these values? This would prevent any crazy smooth inputs ...
A:
in theory there wouldn't be any limits, and in the current AutoDock there isn't a check for values provided.
If you want to include one, I would say that 5.0 is a pretty high upper bound, while the minimum can't go lower than 0.0 (it's a distance).
Optimize gradient-based local searchLeonardo SolisLeonardo Solis2018-05-31https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/60Intel OpenCL driver test on multicore CPUs2019-06-14T15:43:18ZLeonardo SolisIntel OpenCL driver test on multicore CPUsSimilar to #5.Similar to #5.https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/33Define an appropriate size for MAX_INTRAE_CONTRIBUTORS2018-08-13T12:57:05ZLeonardo SolisDefine an appropriate size for MAX_INTRAE_CONTRIBUTORSNot consistently defined in debugfastergrad due to preliminar `calcgradient` implementation.
In debugfastergrad:
```zsh
#define MAX_INTRAE_CONTRIBUTORS 8192
```
In master, which is more consistent and scalable:
```zsh
#define MAX_IN...Not consistently defined in debugfastergrad due to preliminar `calcgradient` implementation.
In debugfastergrad:
```zsh
#define MAX_INTRAE_CONTRIBUTORS 8192
```
In master, which is more consistent and scalable:
```zsh
#define MAX_INTRAE_CONTRIBUTORS MAX_NUM_OF_ATOMS * MAX_NUM_OF_ATOMS
```Leonardo SolisLeonardo Solis2018-08-17https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/23Program option -lsrat should accept 1002018-08-13T15:52:23ZLeonardo SolisProgram option -lsrat should accept 100For the -lsrat argument, ocladock should accept 100, but it tests for "< 100" instead of "<= 100" in getparameters.cpp:
* [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/543310ccfe73d3ccc1ce7d7a0ae691559a495eeb...For the -lsrat argument, ocladock should accept 100, but it tests for "< 100" instead of "<= 100" in getparameters.cpp:
* [master](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/543310ccfe73d3ccc1ce7d7a0ae691559a495eeb/host/src/getparameters.cpp#L262) branch
* [debugfaster](https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/af2688673b0e07646c1b90b1cbaa3a34f52c494c/host/src/getparameters.cpp#L267) branchLeonardo SolisLeonardo Solis2018-08-10https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/18Add FIRE local search2018-09-03T12:15:45ZLeonardo SolisAdd FIRE local searchFIRE: Fast Inertial Relaxation Engine
* [FIRE paper](https://www.math.uni-bielefeld.de/~gaehler/papers/fire.pdf)
* [FIRE presentation slides](http://users.jyu.fi/~pekkosk/resources/pdf/FIRE.pdf)FIRE: Fast Inertial Relaxation Engine
* [FIRE paper](https://www.math.uni-bielefeld.de/~gaehler/papers/fire.pdf)
* [FIRE presentation slides](http://users.jyu.fi/~pekkosk/resources/pdf/FIRE.pdf)Leonardo SolisLeonardo Solis2018-08-06https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/17Using -lsrat 0 causes clEnqueueNDRangeKernel() -542018-07-21T10:33:31ZLeonardo SolisUsing -lsrat 0 causes clEnqueueNDRangeKernel() -54Program currently accepts lsrat equal to 0 and stores its value into `dockpars.num_of_lsentities`, which in turn is used to define the work-group size of LS kernel.
A work-group of size zero leads to OpenCL error code -54.
In `master`...Program currently accepts lsrat equal to 0 and stores its value into `dockpars.num_of_lsentities`, which in turn is used to define the work-group size of LS kernel.
A work-group of size zero leads to OpenCL error code -54.
In `master` branch:
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/getparameters.cpp#L262
In `fastergrad` branch:
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/fastergrad/host/src/getparameters.cpp#L267
2018-06-30https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/16Behavior when using -lsit 0 requires redefinition2018-07-03T09:54:03ZLeonardo SolisBehavior when using -lsit 0 requires redefinitionShould this disable local search or be ignored?
This is currently being ignored.
In `master` branch:
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/getparameters.cpp#L358
In `fastergrad` branch:
https...Should this disable local search or be ignored?
This is currently being ignored.
In `master` branch:
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/master/host/src/getparameters.cpp#L358
In `fastergrad` branch:
https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/blob/fastergrad/host/src/getparameters.cpp#L392
Leonardo SolisLeonardo Solis2018-06-30https://git.esa.informatik.tu-darmstadt.de/docking/ocladock/-/issues/11Add support for 256 wi2018-01-18T18:22:30ZLeonardo SolisAdd support for 256 wiLeonardo SolisLeonardo Solis2018-01-31