Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repository Organization #17

Open
HubLot opened this issue Mar 25, 2015 · 6 comments
Open

Repository Organization #17

HubLot opened this issue Mar 25, 2015 · 6 comments

Comments

@HubLot
Copy link
Member

HubLot commented Mar 25, 2015

Further to the issue #15, I would like to offer a tree view of the repo to improve it. The idea is to follow more or less the github research workflow here and we would have something like this:

nmrlipids.blogsport.fi
   |
   - Data (DATAreportediINblog)
   |
   - Fig
   |
   - Input files
   |
   - HGmodelMANUSCRIPT
   |
   - LIPIDionMANUSCRIPT
  • Data will be the DATAreportedINblog. The organization in this folder is great with the source of the data in each file. But we can move the graphic files in the Fig folder. This way, we won't mix up raw data and the graphics generated from them. Adding a few lines in the README to explain the data file will be great and how we obtain them from MD trajectories.
  • Fig will contain all & only the generated graphics from the Data folder. We could have a Makefile inside it to properly regenerated them when the data files changed and a sub-folder src where the scripts to generated the fig will be stored. The idea is to quickely & easily regenerated the figures from scratch (reproducibility).
  • Input files will contain all input files to re-launch the MD simulations (like the POPCCharmm folder) with the same tree view as Data. There is not much of these files currently but they can be easily added from zenodo. We will aslo add the zenodo links in a README or something like that.
  • HGmodelMANUSCRIPT& LIPIDionMANUSCRIPT will contain only the needed files for the manuscript (tex, bib, etc). The README wil contain, among other stuff, the list of the figures used which are stored in the Fig folder. Thus, people could quickely identified them. See Manage HGmodelManuscript folder #15

Of course, the scientific disussion will remain on the blog but the technical part can be discuss here.

Of course, I'm willing to do this work :)

@ohsOllila
Copy link
Member

Would you have some idea which would be good way to organize the analysis (or other) scripts? Now there is the scripts folder in nmrlipid.blogspot.fi repo and there are some scripts which are also used in the new repository NmrLipidsCholXray. There are also some more specific scripts now in these "Input files" folders. Is it better to have all the scripts in the scripts folder, or only the more general ones? How about the scripts which are used also in other repositories?

@HubLot
Copy link
Member Author

HubLot commented Mar 31, 2015

I think a good way could be to store all analysis scripts in a sub-folder (scripts) of the DATAreportediINblog folder. 2 benefits:

  • consistency with the Fig folder: the subfolder scripts to reproduce figures and here to reproduce data (order, dihedrals, ...) from raw trajectories.
  • Save in one place to avoid duplication.

Your mapping scheme to generalize analyze scripts is a great idea. Once done, it's really straightforward to apply an analysis to all trajectories. I think it will simplify this whole thing.

Adding documentation with some examples of how running these scripts (assuming the trajectories are stored somewhere) will be good to.

How about the scripts which are used also in other repositories?

That's the tricky part, there is no really easy solution. To keep them sync between repos, one solution could be to create a repo with only those and use git subtree but I think it will be overkill/overhead for now.
Otherwise, you could use symlinks of scripts on your side between repos. Or just copy the modifed ones to the other repos. We can start by doing manually and see how it works.

@ohsOllila
Copy link
Member

One though which might be worth of considering is to have the structure you suggested with one additional folder in the project root:

/scratch/

This would contain files and folders which are used and changed a lot during the workflow of the project. For example, currently the folders POPC_, DPPC_, DLPC* and dihedrals would belong there. Then once the content is getting more ready, it would be moved to the folders you have made.

One question is also that should we make an own repository for the Lipid-ion interaction work? My feeling now is that we should. One reason is that when we get a doi for this repository for the publication, there would be these workflow files from lipid-ion work included if they are in same repository. That may not be reasonable.

@HubLot
Copy link
Member Author

HubLot commented Apr 16, 2015

Great idea about the /scratch folder. It would help cleaning the project and provide a "test" folder.

One question is also that should we make an own repository for the Lipid-ion interaction work? My feeling now is that we should. One reason is that when we get a doi for this repository for the publication, there would be these workflow files from lipid-ion work included if they are in same
repository. That may not be reasonable.

I agree. Indeed, maybe the philosophy 1 repo <-> 1 publication would be more clear for people and more efficient. It definitely worth a try at least. We would have redundancy between repos but it will be the input files for the most part and they not going to change over time.

This was referenced May 11, 2015
@ohsOllila
Copy link
Member

After this pull request #37, I moved or removed the random repositories from the root: 26c14c7 1907ce6

The Dihedrals directory in scracth could be, in principle, moved to Fig/scripts and Data folders. This is not necessary, though.

@HubLot
Copy link
Member Author

HubLot commented May 12, 2015

After this pull request #37, I moved or removed the random repositories from the root: 26c14c7 1907ce6

Great

The Dihedrals directory in scracth could be, in principle, moved to Fig/scripts and Data folders. This is not necessary, though.

Indeed, we can leave it there but I can write a few lines to describe the content (done in #39)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants