guidelines on how to import existing codes

[NicolettaK]

As discussed at the S2S meeting in April 2020, I think it would be important to prepare a set of guidelines on all the steps needed to import existing codes in this repo.

There exist a bunch of codes already developed by collaborators that we probably want to import here. Releasing a tutorial on this would also help in making clearer to the collaboration the scope of this team, which, as we said several times, is not to develop the full pipeline but just to have a common and coherent infrastructure.

One example is the simple pipeline that I developed to produce map based simulations, which is available here https://github.com/NicolettaK/LB_mbs. This is a private repo at the moment as there are infos about the instrument, but I can give you access if you want to have a look.

Any idea on how we should proceed on this?

[ziotom78]

Thank you for having opened this issue. I believe we should create a dedicated section in the documentation, providing a checklist that details which kind of codes we want to import, and how the code should look like.

A few things I'd like to see in the page are:

1. Examples of codes that we would like to use in this repo (e.g., «component separation code», «cosmic ray glitch simulator», etc.);
2. Constraints in the way the code is implemented (e.g., «no standalone program, only libraries», «no Python2, IDL, Matlab codes» etc.);
3. How to make litebird_sim support the code (e.g., «any library should be installable through pip»);

It would be nice to provide a simple example of this process. We might use a very simple standalone code (a few tens of lines) and show which steps are necessary to make it usable under litebird_sim. For me, it would be really useful to have a look at your private repository, @NicolettaK.

To all: please comment!

[NicolettaK]

@ziotom78 you should have access already

[NicolettaK]

what about testing?

[ziotom78]

@ziotom78 you should have access already

Yes, what I meant to say was: in my opinion, it would be good for everybody to have a look at your repository and use it as a reference to build the documentation.

what about testing?

This is a nasty issue. My experience shows that codes in our community rarely have comprehensive tests, and interfaces are seldom well-defined. However, if we want to incorporate some code in our repository, we should create integration tests anyway.

[ziotom78]

I've opened a PR containing a sketchy new section for the documentation. Unfortunately, the text refers to functionalities that have yet to be implemented (e.g., the method Simulation.query_input_parameter is still missing), so the clarity of the text might be sub-optimal.

@NicolettaK , , if you consider your code in NicolettaK/LB_mbs, does the text answers the questions you would have? Which parts of the text you think should be extended/removed/amended to help you in integrating the code?

To all: please integrate the PR with your comments! I do not know how much time I'll be able to dedicate to this, as this week I am busy with exams. In the meantime, feel free to commit changes directly to the PR.