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
Comments
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? |
I think a good way could be to store all analysis scripts in a sub-folder (
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.
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. |
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. |
Great idea about the /scratch folder. It would help cleaning the project and provide a "test" folder.
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. |
Great
Indeed, we can leave it there but I can write a few lines to describe the content (done in #39) |
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:
Data
will be theDATAreportedINblog
. The organization in this folder is great with the source of the data in each file. But we can move the graphic files in theFig
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 theData
folder. We could have aMakefile
inside it to properly regenerated them when the data files changed and a sub-foldersrc
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 thePOPCCharmm
folder) with the same tree view asData
. 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 theFig
folder. Thus, people could quickely identified them. See Manage HGmodelManuscript folder #15Of 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 :)
The text was updated successfully, but these errors were encountered: