Difference between revisions of "AC UserManual"
Line 62: | Line 62: | ||
ssh {user}@ui.pic.es | ssh {user}@ui.pic.es | ||
− | 1.3 | + | 1.3 Create a directory in which you are going to develop your codes, e.g: |
− | + | mkdir -p ~/src/{software_project_name} | |
− | 1.4 Copy the code from the gitlab repository: | + | 1.4 Copy the code from the gitlab repository in the created directory: |
− | git clone https://gitlab01.pic.es/{ | + | cd ~/src/{software_project_name} |
+ | git clone https://gitlab01.pic.es/{software_project_name}/{pipeline}.git | ||
Revision as of 11:19, 19 March 2018
Storage
Massive storage
Each project has a massive storage space accessible at the following path:
/pnfs/pic.es/data/astro/{project} (see projects_url for more details)
which has only read permissions for the project's users.
Inside the directory there are two different paths corresponding to two different back-ends:
Tape
/pnfs/pic.es/data/astro/{project}/tape
As its name suggests, the data in the tape path is stored in magnetic tapes, and is critical, such as raw data or very difficult data to obtain or to get. The size of each file is usually large, from 1-2GB to 100-200GB, due to technical reasons (they are usually iso or tar.bz2 files). Data in tapes is not very often accessed. It is necessary a previous step when accessing data in tapes, which is the pre-stage. This step is the action of reading the magnetic tape and put the data into a buffer. Once the data is in the buffer one can access the data as it was in a disk. After some time, the data is removed from the buffer. In case the data in tape has to be available for long time get in touch with the contant person of the project.
Disk
/pnfs/pic.es/data/astro/{project}/disk
Disk data is usually the data being currently used by the project, and it is being very often accessed. The size of the files is not important here.
Scratch
Each user has a scratch space at the following path:
/nfs/astro/{user}
This space is thought as a sandbox. When the project decides some data from any scratch space is important enough for the whole collaboration, the contact person for each project will move the data into the /pnfs storage.
Take note that all data older than 6 months may be erased at any time without prior notice.
Any location not included in the former paths is not allowed and its contents erased on sight.
Download code and git rules
These are the git rules for developers at PIC.
The methodology written below is a try to help the code development of the team and they are thought for non-experts git users.
It has been compiled from the official git documentation, which we strongly recommend to look at (at least the first three chapters):
And from this git branch model:
A successful Git branching model
We assume you already have a PIC account.
Codes are hosted at https://gitlab.pic.es.
1. Download the code (first you need to have permissions to do it)
The user software area can only be edited from services.astro so you must have access to this machine in order to edit the code.
1.1. Access ui:
ssh {user}@ui.pic.es
1.2. Access services.astro:
ssh {user}@ui.pic.es
1.3 Create a directory in which you are going to develop your codes, e.g:
mkdir -p ~/src/{software_project_name}
1.4 Copy the code from the gitlab repository in the created directory:
cd ~/src/{software_project_name} git clone https://gitlab01.pic.es/{software_project_name}/{pipeline}.git
2. Create your own branch
Every project has two main protected branches: master and develop. Protected means you, as a standard developer, will not have permissions to write on them. Therefore in order to develop your features in the code you need to create your own branch that will always come from the develop branch.
2.1 Enter in the project directory:
cd {pipeline}
2.2 Create the branch:
git checkout -b feature_branch_name origin/develop
3. Modify the code
3.1 Day Tip:
Everyday you sit in your computer and want to modify the code, in order not to be outdated in the changes made in the develop branch, you should do:
3.1.1 Download any modification in the code
git fetch
3.1.2 Incorporate changes in the develop branch into your feature_branch_name branch
git rebase origin/develop
(Hopefully there will be no conflicts if all developers are working in independent branches. If this is not the case and you have doubts after reading the references given in point 5 below, please call us before meshing it up!)
3.2 See the changes you have done
git status
3.3 Add changes
git add changed_files
3.4 Commit changes
git commit -m "message describing the modifications"
4. Finish the new feature
Once you finish to develop, debug and test the new feature you send us an email.
We immediately will send you back another one saying that your feature has been integrated into the develop branch.
Note that your branch will be deleted.
5. Incorporate changes and start a new feature again
In order to start with a new feature you need to incorporate the changes we just did (integrate the feature into develop) and create another new branch:
git fetch
git checkout -b anoter_feature_branch_name origin/develop
Working with Python environments
Create a new environment
cd ~/env/ /software/astro/sl6/python/2.7/bin/virtualenv <name>
Activate environment
Locate the `setup.py` file of the project
cd ~/src/<project>/
Activate environment and deploy
. ~/env/<name>/bin/activate pip install -e .
Install a specific Python package
. ~/env/<name>/bin/activate pip install <package>
Install jupyter notebook suite
. ~/env/<name>/bin/activate pip install jupyter[notebook]