Adding unfied planet mapmaker using for MF-SATs

[yoshinori-0778]

Adding general functions in coords.planets.py and functions related to planet mapmaking in mapmaking.planet_mapmaker.py.

Now is a very very draft, but I confirmed that a planet map was made. Will arrange these more appropriately.

[kmharrington]

these sorts of hard-codings I would move to a version-controlled configuration file.

[mhasself]

Thanks for all this work! As requested, here is some general guidance (but not an exhaustive review yet):

• Please include an example config file as part of documentation.
• Format code and docs to less than 120 columns.
• There are also some "whitespace" violations -- might be worth just running a source formatter on the new files you're contributing (but don't mass-reformat the existing files like planets.py!)
• Consider making the deflection/wobble code a little more general, and moving into coords module somewhere.
• You have functions for getting and archiving and processing PWV. Are those needed, if instead we can provide PWV through obsdb? I think it's good to minimize the number of different ways we pull data from APEX / Toco radiometer.
• Use "single" instead of "each" for functions that process one of something (e.g. get_each_instrument_P). "Each" implies that it is looping, internally, over a bunch of things.
• Remove default paths from planet_mapmaker.py funcs

Much of the new code in planets.py is basically dealing with the fact that SlowSource is not really good enough, at this point. It would be nice to take your functions calc_planet_* and instead create a replacement for SlowSource, e.g. AzElSource, that provides an az, el interpolator for any kind of source with sufficient precision for beams work. (Basically I want to get rid of SlowSource in favor of something that works better, without a huge performance penalty for simple cases.)

[mhasself]

Perhaps use obs['wafer_slots_list'] for this.

[mhasself]

Construct this data one time (instead of duplicating 3 times).

[mhasself]

Use a full submodule docstring """ ... """ here, and explain in more detail what the script does. It's also a good place to put in an example of a configuration file. The docstring here is easy to have rendered in readthedocs, so it can be the "one place" this script is explained.

[mhasself]

Ah, xieta decomposition won't work (as you say in docstring), but I think this would?:

 phi, theta, gamma = so3g.proj.quat.decompose_iso(q)
 return so3g.proj.rotation_iso(phi, theta, 0.)

[mhasself]

Thanks for all this work! As requested, here is some general guidance (but not an exhaustive review yet):
...

One more thing: utility functions (such as the ones you've added in coords.planets) should have unit tests. (It's not necessary to duplicate all the calculations; rather the tests just make sure there aren't typos and that different ways of asking for the same thing will yield the same answer.)

[yoshinori-0778]

THanks for the comments @mhasself

Please include an example config file as part of documentation.
Could you more clarify where I should inculde? Should I add example config files in this mapmaking directory?

You have functions for getting and archiving and processing PWV. Are those needed, if instead we can provide PWV through obsdb? I think it's good to minimize the number of different ways we pull data from APEX / Toco radiometer
If there is PWV database, we do not need this. Is that available somewhere? I am happy to incorporate it.

[yoshinori-0778]

Future task for me: run all combination of detector/boresignt/planet center and wafer/detector based deflection correction.

[kmharrington]

You have functions for getting and archiving and processing PWV. Are those needed, if instead we can provide PWV through obsdb? I think it's good to minimize the number of different ways we pull data from APEX / Toco radiometer
If there is PWV database, we do not need this. Is that available somewhere? I am happy to incorporate it.

@mhasself A note on this. I discovered recently that the extended obsdbs running in your user account do not include calibration observations. It would be good to have those expanded and to make them official. Otherwise we'll keep having parallel implementations pop up.