litebird / litebird_sim

Simulation tools for LiteBIRD
GNU General Public License v3.0
18 stars 13 forks source link

make TOAST interface work with components different from obs.tod #242

Closed marcobortolami closed 1 year ago

marcobortolami commented 1 year ago

This PR has been opened to solve #241.

marcobortolami commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
  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 commented 1 year ago

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 commented 1 year ago

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

ziotom78 commented 1 year ago

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