File:SetupOrientationRetina.png

2022-11-07T09:32:39Z

2022-11-04T13:59:47Z

Joesterle:

File:IgorRecCenterNew.png

2022-11-04T13:59:36Z

Joesterle:

Igor coordinates

Orientation

2022-11-04T13:29:47Z

Joesterle:

Orientation

2022-11-04T13:28:51Z

Joesterle:

Orientation

2022-11-04T13:28:10Z

Joesterle:

Orientation

2022-11-04T13:27:44Z

Joesterle:

# Stimulus

Setup 1 and setup 3 have different stimulus orientation.
The following two stimuli can get used to test the stimulus orientation on a setup.
[[File:Test orientation.zip|thumb]]

In 2022, the orientation of the stimulus as seen by the retina were as follows:

Setup 1:

- MB0_deg: goes from front (ventral / curtain) to back (dorsal)

- MB90_deg: goes from right to left

Setup 3:

- MB0_deg: goes from back (dorsal) to front (ventral / curtain)

- MB90_deg: goes from right to left

If you design a stimulus in QDSpy you can check its orienation by playing these stimuli and your stimulus.

# Igor

If you open a file in Igor (ScanM) and display it with e.g. Automated Cell Label, it will look something like this. The center coordinates (which is also the stimulus center) will be like this:

File:Igor rec center.png

2022-11-04T13:26:59Z

Joesterle:

Recording center of Igor file

Main Page

2022-11-04T12:46:13Z

Joesterle: /* Experimental */

Welcome to the AG Euler wiki.
Feel free to contribute additional content.

==General==

* [[Email Addresses]]
** needs update
* [[Internal Phone Numbers]]
** needs update

==Experimental==

*[[Ringer Solution]]
* [[Dissection]]
* [[Data Storage and Data Structure]]
* [[Orientation]]

==Computational==

* [[Docker Containers]]
* [[Igor]]
* [[Cluster]]
** needs update
* [[Datajoint]]
** needs update
* [[Jupyter]]
** needs update
* [[MATLAB]]
** needs update
* [[Python]]
** needs update
* [[PyCharm]]

Orientation

2022-11-04T12:45:47Z

Joesterle:

Setup 1 and setup 3 have different stimulus orientation.
The following two stimuli can get used to test the stimulus orientation on a setup.
[[File:Test orientation.zip|thumb]]

In 2022, the orientation of the stimulus as seen by the retina were as follows:

Setup 1:

- MB0_deg: goes from front (ventral / curtain) to back (dorsal)

- MB90_deg: goes from right to left

Setup 3:

- MB0_deg: goes from back (dorsal) to front (ventral / curtain)

- MB90_deg: goes from right to left

If you design a stimulus in QDSpy you can check its orienation by playing these stimuli and your stimulus.

2022-03-28T09:29:37Z

Joesterle:

If you want to visit the old page: [[Docker (deprecated)]]

== Instructions to build and run docker containers on cluster nodes ==
=== Accessing the cluster nodes ===
To access the cluster nodes you need to establish a ssh connection. This can be done from the terminal (natively under Ubuntu or using Cygwin under Windows). You first need to ssh to the cluster headnode (<code>ssh 172.25.250.112 -p 60222</code>). Authentication works with your LDAP/CIN useraccount and password. If your local username differs from your LDAP account name you have to use <code>ssh username@172.25.250.112 -p 60222</code>. From there you can access the cluster nodes via <code>ssh nodename</code>.
If you want to run a docker container with a jupyter notebook server on the cluster node and want to access it from your browser the usual way (opening [http://localhost:8888 localhost:8888]), a ssh tunnel to this cluster node is needed. Therefore you ssh to the cluster using the command
<pre>ssh username@172.25.250.112 -p 60222 -L 8888:172.29.0.xx:pppp</pre>
where the second IP address has to be the one corresponding to the clusternode and <code>pppp</code> is the port number used by your docker container (see below).

Cluster node IPs:
* eul1 172.29.0.148
* eul2 172.29.0.149
* eul3 172.29.0.150

If you have troubles with the ssh key authentication just run
<pre> ssh-keygen -R "hostname"</pre>
(with hostname = eulX) and accept the new key when you ssh to the respective node.

Tip: You can also find the node IP by calling <code>ip a | grep 172.29</code> when you are on that node.

=== Building and running docker containers ===
Disclaimer: Our docker containers contain special functionality to integrate LDAP user accounts and our home directories. The following instruction doesn't work out of the box with any random docker container.
==== Building a docker container ====
To check which docker images are available on a cluster node call <code>docker images</code> on that node.

If you want to build an image that does not yet exist do the following:

* Clone this https://github.com/eulerlab/docker (or this https://github.com/berenslab/docker) GitHub repo to a folder <code>your-docker-folder</code> where you want to have your docker files stored.
** This is a private repo, so you need to be a member of eulerlab (or berenslab).
*** The eulerlab repo is based on the berenslab repo.
** You may want to fork the repo before you clone it. This might not be necessary for many users, though.
* Go to <code>your-docker-folder</code>.
* Run e.g. <code>docker build -t berenslab/deeplearning:latest ./berenslab/deeplearning</code> which builds the container called <code>berenslab/deeplearning</code> with the tag <code>latest</code> from the directory <code>./berenslab/deeplearning.</code>
** If you don't state a tag, it will default to <code>latest</code> which is fine, but if there are multiple similar images, please use tags.
* Run <code>docker images</code> to see your docker image listed

Some docker images depend on other local images, meaning that you have to build the images they depend on first. For example <code>berenslab/datajoint</code> requires an existing image <code>berenslab/deeplearning</code>.

Otherwise they typically depend on remote images, e.g. <code>berenslab/deeplearning</code>, you typically do not want to build a container from scratch. If you want to create a new docker file and its respective image, first have a look at how the files are structured in https://github.com/eulerlab/docker.

* Then create a folder that is or includes your username within <code>your-docker-folder</code>, e.g. <code>your-docker-folder/inewton</code>
* Within create a folder with a name that describes your image, e.g. <code>your-docker-folder/inewton/deeplearning</code>
* To create the image from this dockerfile call <code>docker build -t inewton/deeplearning ./inewton/deeplearning</code> to have an image name everyone else on this node can interpret.
* Sometimes you may want to save this image to a tar file on your harddrive for reproducibility using <code>docker save image_name</code>

* If you just want to build the standard images (no debugging etc.), it makes sense to use <code>--no-cache</code> to save space on the node and don't store intermediate images from the build steps

==== Starting docker containers ====

TLDR:
To start a new container call the following command replacing the arguments with meaningful values:
<pre>
python agte-docker run -ti --jupyterport 6789 --jupyterpass some_password --name container_name_suffix -v /gpfs01/euler/data/Data:/gpfs01/euler/data/Data:ro -v /gpfs01/euler/data/Resources/Stimulus:/gpfs01/euler/data/Resources/Stimulus:ro berenslab/datajoint
</pre>

More info:
To start a docker container with a running jupyter notebook server and correct user permissions, we use one of the scripts <code>agte-docker</code> / <code>agte-docker_gpu</code> / <code>agpb-docker</code>.
Note that only the second and third support GPU usage. For this reason they also only work on nodes with GPUs.
Calling the script will look something like this:
<pre>
python agte-docker run -ti --jupyterport 6789 --jupyterpass some_password --name container_name_suffix berenslab/datajoint
</pre>

* The last argument (e.g. <code>berenslab/datajoint</code>) specifies the image the container will be based on.
** You can list all available images calling <code>docker images</code> on a node. If no images are available you have to build them first (see below).
* The argument after <code>--name</code> (e.g. <code>container_name_suffix</code>) should be a suffix that helps to identify specific containers for yourself.
** The script will automatically add your username to the container name.
* The argument after <code>--jupyterport</code> (e.g. <code>6789</code>) is the port number used for the ssh tunnel that allows you to access the jupyter notebook server.
** It has to be free, i.e. not used by other container. You can check this by running <code>docker ps</code> to list allrunning containers on that node. Usually it should also be well above 1000.
* The argument after <code>--jupyterpass</code> (e.g. <code>some_password</code>) can be used to specify a passwort to access the jupyter notebook later in the server.

If you want to use a GPU you want to ensure that you are the only one on a specific GPU and that your calculations use only one of the two GPUs of the node. Therefore run the script with
<pre>GPU=X python agte-docker run -ti --jupyterport 6789 --jupyterpass some_password --name container_name_suffix berenslab/datajoint</pre>
with either <code>GPU=0</code> or <code>GPU=1</code>.

The container name is then automatically set as <code>gpuX-username</code> and everyone can see which GPUs are already taken.

To start a container in interactive mode with bash and no jupyter notebook server call
<pre>
python agte-docker run -ti --jupyterport pppp --name container_name berenslab/datajoint bash
</pre>

===== Accessing additional directories =====
To work with datajoint and any experimental data you need to make two additional directories available from inside the docker container, therefore include <pre>-v /gpfs01/euler/data/Data:/gpfs01/euler/data/Data:ro -v /gpfs01/euler/data/Resources/Stimulus:/gpfs01/euler/data/Resources/Stimulus:ro</pre> in the run command.

===== Limit the container to a certain number of CPUs =====
Often it is useful to constrain your container such that it doesn't use all CPUs. For example, if someone else wants to access the GPUs they need at least 1 CPU.
Therefore, when stating a container add the following to use e.g. only first 30 CPUs.
<pre>--cpuset-cpus 0-29</pre>

The whole command might look like this:
<pre>python agte-docker run -d --cpuset-cpus X-Y --jupyterport pppp --jupyterpass some_password --name container_name berenslab/datajoint</pre>

=====Trouble-Shooting =====

* Always make sure the jupyterport is not already used.
* Always make sure the container_name is not already used.
* Do not state parameters after the image name (only before).
* Container stops directly after creating it:
If you create a new container with <code>agte-docker run</code> it may happen that the docker stops directly because of an error.
You will not find it with <code>docker ps</code>, but only with <code>docker ps -a</code>.
This can happen for several reasons.
Use <code>docker container logs container_name</code> to check the logs.

==== Interactive container mode ====
These commands starts the docker container in the detached mode which means it runs in the background. If in addition you want to enter the docker container with a bash you can call
<pre>docker exec -u username -ti container_name bash</pre>

=== Creating an image from a container ===
Sometimes you install things not using a docker file but within a container. While this should be avoided when it can be, sometimes this is very useful. If you have done so, you may want to create an image from your container, to be able to reuse it. Make sure to document what changes you have done to your container if it was anything non trivial.

To create an image of the container first do the following to create an image:
*<code>docker commit your_container_name</code>
*<code>docker tag id_of_the_just_created_container your_image_name</code>

=== Saving an image to your harddrive ===
To save an image call: <code>docker save some_image_name > some_filename.tar</code>

This will create a tar file of you docker image.

=== Copying an image to another note ===
If you want to copy an image to another node you can do the following:
* <code>ssh</code>to a node with an image you want
* <code>cd</code>to some folder you created for docker images
* <code>docker save some_image_name > some_filename.tar</code>
* <code>ssh</code> to another node
* <code>cd</code> to the same folder again with the docker images
* <code>docker load --input some_filename.tar</code>

==Basic usage of containers==

===Install packages in running containers===
Typically you want to add all (python etc) packages you will need to your Dockerfile before creating your Docker image.
In practice however, you might want to install packages in running containers, to extent their functionality.
To do this execute you docker container: <pre>docker exec -u username -ti container_name bash</pre>

Inside your docker container, you almost '''always''' want to install packages using <code>sudo</code>, because then they will be installed in the container only, and not in your home directory which will then be visible in other containers too, e.g.:
<pre>sudo pip install numpy</pre>

===Trouble shooting===
To check which python and pip version you are using type <code>python -V</code> and <code>pip -V</code>. The pip python version should match your python version, and if not, set an alias or always use <code>pip3</code> (not recommended).

Inside your notebooks you can run <code>!python -V</code> and check if the versions are matching.

<code>pip list -v</code> lists all packages and their installation locations. Verify that packages you only want inside you docker containers are not installed in you home directory.

<code>pip check</code> checks for broken dependencies.