Error importing LinearCorePotential

[sitangshugk95]

https://github.com/ContactEngineering/Adhesion/blob/master/examples/adhesive_plastic_simulation_cone.ipynb

I think it should be from Adhesion.Interactions.cutoffs import LinearCorePotential instead of from Adhesion.Interactions import LinearCorePotential

I was getting this error: but changing it fixed the error:

However, I cannot make changes to the function definitions, and I guess that it is the same issue that is causing this error:

@sannant Please let me know if this is something that needs to be fixed on your end, or is it something that I am doing wrong?

[sitangshugk95]

@sannant It looks like this is related to #63 . Is this something that I can fix/submit a request, or does this need to be done from your end?

[sannant]

You are very welcome to submit a pull request. We will review it anyway. Thank you for finding this error, and sorry that this issue slipped out of my attention.

[sitangshugk95]

@sannant could you please give me the access rights to submit pull requests? I'm trying to push the modified code and it is giving me the following error:

[sannant]

you can create a fork on github and push there. (you will need to set your fork as push remote)

[sitangshugk95]

Thanks, I have submitted the pull request.

[sitangshugk95]

@jotelha @sannant The change (line 44 - linearize_core) shows up in contact.engineering github after being merged:

However, when I am running a code that calls that function using singularity run docker://imteksim/jupyterlab-surfacetopography:latest , the change is not being reflected; the error shows the old code (line 44 - LinearCorePotential):

Is there something that needs to be done for the changes to be reflected when executing using Docker images?

[jotelha]

Hi @sitangshugk95 the containers won't update by themselves, we will build a new one with some future release soon.

[sitangshugk95]

Thanks @jotelha.

Could you give me a rough estimate of when you expect to do it? It would help me plan my work accordingly, as I can't proceed unless it is done.

Also, since it looks like Docker images is the approach I would have to stick to to use contact.engineering for the near future, what would be a realistic frequency (biweekly/monthly/other) to update the containers based on your workload? I don't think it would be needed very frequently anyway once the basic debugging is done, but I would still like to have that info and inform my advisor.

[jotelha]

Can't give any estimate here, since ContactEngineering is an academic project, and many of the repositories like Adhesion grow organically as people collaborate loosely while working on their PhD and master projects, without the resources to provide support. My own project is rather unrelated and I am only helping a little on the side with the container-related stuff.

If you need your own modifications in the container timely, you can bind your local copy of whatever repository you changed into the container instance and override whatever is already present within the container.

Have a look at https://github.com/ContactEngineering/ce-container-stack/tree/master/docker/jupyterlab-SurfaceTopography#changes-to-the-container

Let's say you want a modified Adhesion package and you have it locally at /path/to/git/repo/Adhesion. In short, what you could do to have the modified repository in the container, is:

• Launch container instance with bind mount, i.e.

  docker run -v /path/to/git/repo/Adhesion:/home/jovyan/Adhesion -p 8888:8888 imteksim/jupyterlab-surfacetopography:latest

• Enter a terminal within the container as usual via the JupyterLab web interface
• As described at https://github.com/ContactEngineering/ce-container-stack/tree/master/docker/jupyterlab-SurfaceTopography#changes-to-the-container, use
  • conda deactivate and
  • export PATH=$(echo "$PATH" | sed -e 's|/opt/conda[^:]*:||g') to remove any conda-related residue from the path to break out of the container's default conda environment.
• change to /home/jovyan/Adhesion or wherever you mounted your repo within in the container
• install with pip install . or pip install -e . , latter for editable in-place. That should override whatever Adhesion version is already available within the SurfaceTopography kernel in the container.
• If you need a public online branch, you may install directly from the web, i.e. with pip install git+https://github.com/ContactEngineering/Adhesion.git@master, the suffix pointing to the actual branch

Hope that helps.

[sitangshugk95]

Thank you for the very detailed answer, so sorry again for my unfamiliarity with Linux.

• Launch container instance with bind mount, i.e.

  
  docker run -v /path/to/git/repo/Adhesion:/home/jovyan/Adhesion -p 8888:8888 imteksim/jupyterlab-surfacetopography:latest

@jotelha Quick question - could you please tell me how to modify the above command to use it with singularity without root privileges? eg; I generally use singularity run docker://imteksim/jupyterlab-surfacetopography:latest to launch the images, and I have it locally in /home/grads/s/sitangshugk95/Adhesion .

I tried the following, but it was probably wrong:

[jotelha]

This question boils down to looking into the singularity documentation, https://docs.sylabs.io/guides/3.0/user-guide/bind_paths_and_mounts.html will tell you to run

singularity run --bind /home/grads/s/sitangshugk95/Adhesion:/home/jovyan/Adhesion docker://imteksim/jupyterlab-surfacetopography:latest

but isn't your home directory mounted anyway with singularity?

[sitangshugk95]

@jotelha All I to do run the docker images is type singularity run docker://imteksim/jupyterlab-surfacetopography:latest in console - I am not entirely sure if my home directory is mounted with singularity: does it matter and how do I check it?

Anyway, I used singularity run --bind /home/grads/s/sitangshugk95/Adhesion:/home/jovyan/Adhesion docker://imteksim/jupyterlab-surfacetopography:latest and followed the steps you mentioned here and it works perfect - the changes have been reflected. Thanks a lot! Are these changes stored permanently? Or is it only local to that instance of the container, and will go away once I close that and open a new instance?