Some things which do not work

[francescomambretti]

Hi, here is a list of minor and major issues with the code. Minor issues:

• some typos here and there (equlibration without the “I” between u and l, for example; or some comments which are not exhaustive at all)
• it is unclear where to put NVIDIA MPS instructions, e.g. in a script if you use a job scheduler? elsewhere? What if I don’t run the job with a scheduler?
• it is unclear to which oxDNA executable your code is connected. For example, on my workstation I have a cpu and a gpu installation of it, how does your code know which one to use?
• would it be wise to create a dedicated conda environment? I would say so, but if I do it, then the code does not find oxpy anymore… any clue? concerning the provided example:
• which are the default options, if not specified in pre_equlibration_parameters? (Or in the equivalent dictionaries for equilibration and production). For example, what about the salt concentration? Or the max_backbone_force? Does your code take the oxDNA default values?

Major issues:

• the Python script is largely incomplete and does not work
• inside the .ipynb, simulation_manager.run(join=True) should be blocking (i.e. the following simulations cannot be run until these are finished), but it doesn’t seem to be the case on my Ubuntu workstation
• the WHAM analysis with the provided parameters crashes with list index out of range
• trying to use your code to model the simple hybridization of two ssDNA made of 8 base pairs each (an example which was present in the previous release of your software) results in very weird outputs, where the melting temperature of such object changes by more than 10 degrees by changing box size. According to me, this should not happen (or, at least, not to such an extent). Have you tried anything similar? Can you think of anything in the code that could explain this odd behavior?

[mlsample]

Hi Francesco, thank you for being interested in the project and helping to find the current bugs in the code! I will write up a more comprehensive response to your much appreciated finding of bugs to further respond to them with solutions. Additionally, I will post a docker container environment to further test the code in to have some consistency there.

[mlsample]

I added a docker image so my code is reproducible: https://hub.docker.com/repository/docker/mlsample/hairygamiumbrellasampling/tags

   docker pull mlsample/hairygamiumbrellasampling:latest
   docker run --rm --gpus all -it -p 8888:8888/tcp hairygamiumbrellasampling:latest

I'll address the major issues first:

1. The rest of the notebook code was added to the python script. I ran the code within a container, but hopefully it works on your workstation
2. I am unsure why the join=True is not working for you. This is not really a fix to the underlying problem you are having, but you can use simulation_manager.worker_manager() to run it so that it will surely block.
3. Not too sure about this one, can you provide more details?
4. Assuming you are using the code I wrote that was in the previous version of the code, I do know why the melting temp could potentially change by such a large amount based on the box size, but it also depends on the xmax parameter you use and the scale of the box size change. Of course, the melting temp is a function of the DNA concentration, but you would really only see meaningful changes (more than 1 or 2 degrees) if the box size changed by many orders of magnitude. If you are changing the box size without changing xmax, without post processing analysis there should be no difference.

Small issues: 1.I should lint the code, but for now I'll keep it as is.

2. I should comment the code more, but for now, I will release a website with documentation of the important features.
3. Nvidia-mps in the context of a job sheduler (slurm) should be in the batch script. Not in a job sheduler, you can run the nvidia-mps daemon locally in a terminal with cudatoolkit. The name of the pipe and log dir don't need to include any key works, but should be unique to each daeomon instance
4. The oxDNA executable that is being used by my code depends entirely on oxpy, and as such, depends on which python virtual env are you in when you run cmake when first building the oxDNA code. The executable which oxpy is linked to is the executable which will be build in the make step.
5. A dedicated conda env is a good idea, however related to the issue above, you would need to build oxDNA while that env is active, making such a task somewhat less relevant, as ipy_oxdna depends on oxpy. I think a docker container fills this need better. However, if you know another solution I would be interested.
6. The default options can be found in defaults.py