Allow to omit --ligand and --batch when writing maps.

[pslacerda]

There's some redundant code and it was barely tested.

May fix #382.

[diogomart]

Many thanks for this!

About not allowing to read and write maps simultaneously: even though the only reason to do that might be testing the parser and the writer, I think we should not forbid it.

[pslacerda]

Hey, just removed the last commit...

[pslacerda]

@diogomart I think it's done.

[rwxayheee]

v.grid_dimensions_from_ligand(buffer_size) needs m_model to be a ligand, although m_model could possibly store a receptor as well.. So this if block won't be a valid condition, without a ligand. I think we might want to delete this if block.

[rwxayheee]

In the "batch" mode, v.grid_dimensions_from_ligand(buffer_size) cannot be called before a ligand is set. I think the addition of if ((score_only || local_only) && autobox) block here is not valid.

[pslacerda]

It was my attempt to allow ad4 in batch mode, but I was wrong.

[pslacerda]

@rwxayheee, Brute force is something I'm good at, but can't get me very far. Hope I'm not very inconvenient you.

[rwxayheee]

Hi, I think batch mode is allowed with ad4. It will go to the if (vm.count("maps")) { v.load_maps(maps); } condition just a little above this. You can run a test and tell us if it's broken. The only difference is: with ad4, we will provide the maps beforehand, instead of asking it to compute the maps. Since you suggested that the read maps flag should not coexist with write maps flag, there will be no usage case of write maps for ad4. See this tutorial for the expected procedure: https://autodock-vina.readthedocs.io/en/latest/docking_basic.html#a-using-autodock4-forcefield

[rwxayheee]

Here when people have ligand and write_maps, the ligand will be set twice. To avoid this, you can keep the code structure in 4d37e15. This means: (1) we can have the previous structure if ligand ... elseif batch ... elseif write_maps (2) we can call write_maps at the end of each condition (3) for the last condition, when there's no ligand and not batch mode, we can use the simple v.compute_vina_maps(center_x, center_y, center_z, size_x, size_y, size_z, grid_spacing, force_even_voxels); to write maps. In other words, deleting https://github.com/pslacerda/AutoDock-Vina/blob/4d37e15412b7fb45c2df4bb9f74aeb067e3e1c40/src/main/main.cpp#L532-L537 from commit 4d37e15 could be an easy fix, to avoid the undefined behaviors in the invalid condition

[rwxayheee]

Many thanks for this!

About not allowing to read and write maps simultaneously: even though the only reason to do that might be testing the parser and the writer, I think we should not forbid it.

Previously, --write_maps was never called when --maps were supplied for both the --batch and --ligand modes.
However, the functions for --write_maps require an initialized receptor, which must be from --receptor not --maps. Therefore, --maps and --write_maps are implicitly conflicting.

@pslacerda Would it be ok if we apply some more edits, and supersede this PR with a new one? Your commits in this PR will be merged with edits.

Here's the difference - my edit vs. the current state of your develop branch:
pslacerda/AutoDock-Vina@develop...rwxayheee:AutoDock-Vina:383_edited

Here's the difference - my edit vs. the current official develop branch:
develop...rwxayheee:AutoDock-Vina:383_edited

I have also added the error handling (ERROR: --maps (argument to specify the input maps) and --write_maps cannot be used together. \n) and exit at an early point.

[pslacerda]

@pslacerda Would it be ok if we apply some more edits, and supersede this PR with a new one? Your commits in this PR will be merged with edits.

@rwxayheee I'd be ok.

In fact, this problem is smaller than I thought: when --batch is applied the maps are computed only once. However it's still useful in my use case as I want to store binding sites (in maps form) for reuse without the need to recompute.

[rwxayheee]

Hi @pslacerda

I'd be ok.

Thanks! I will not push my commits to your branch (this PR), but will open another PR (that includes your commits) and ask for another reviewer.

I want to store binding sites (in maps form) for reuse without the need to recompute.

Yes, this is an efficient approach, but I encourage you to consider the precision of the maps and benchmark a few systems, to see how much discrepancy there will be when you use maps instead of a real receptor. This is why I brought up the two different ways of calculating the interactions the other day - with maps, or directly from the receptor. I think because of the precision of the maps, the numerical results will be slightly different.

You could do this small test:

1- run a docking, and write maps

2- rerun the docking, but with the pre-computed maps

In my experience, the numerical results will be different, and I think it's because the maps have limited precision (and hopefully there're no more underlying problems with the map function..) If your application relies on the map function, you might want to do the benchmark and show how much the results can differ.