make TOAST interface work with components different from obs.tod

[marcobortolami]

This PR has been opened to solve #241.

[marcobortolami]

I just added the components keyword to the high level functions, following what has been done for madam. We should think about the best strategy to create and use all the instances needed by TOAST

[ziotom78]

Thanks for the PR. I believe we should ask the TOAST map-maker to take as many components as we want and then add them up in the TOD before running the map-maker, right? (This is what Madam does.)

However, this will require the wrapper to allocate a new TOD to keep the sum of all the components. Is this something we want, or should we just require to pass one component to the map-maker? (For Madam there was no problem, as madam is a separate executable that is called once litebird_sim has stopped running. However, this is not the case for the TOAST map-maker, which is supposed to be run while all the Observation objects are still in memory…)

[marcobortolami]

1. The usage would be easier if we just list the components that we want to use on the destripe function and the mapmaker handles their sum, at a cost of more memory usage
2. In the second case the user should take care of the sum, that is not a difficult task. The user could create a new TOD for the sum externally and pass just that component, or sum the interesting components in the same TOD field, saving memory, e.g.

obs.tod_cmb += obs.tod_fg
obs.tod_cmb += obs.tod_wn

3. Another solution in the middle of the two above would be checking if the list of components has more than 1 element. If so, a new TOD field is created for the sum. If not, that TOD is used for the mapmaking.

I would go with 2 or 3.

[ziotom78]

Thanks for the comment, @marcobortolami . My preference is for option 2. Apart from pointings, TODs are the largest objects the framework keeps in memory, so asking the user to explicitly allocate a variable for the sum of the TODs might help in tracking down unexpected memory requirements or to quickly find the culprit of job failures.

@paganol , what do you think?

[paganol]

I there, I agree with @ziotom78. I would go for the option 2

[ziotom78]

Perfect, I implemented option #2 and updated the tests and the docstrings.