What units to use for each module? How to specify them? How to convert between units?

[tomma90]

Some simulation modules may require input in some specific units different from the standard units used by the rest of the pipeline. This may create conflicts between modules.
As an example, to fully simulate the detector response, one may want the optical input (sky map) in units of power rather than the more common temperature or intensity (Jy/sr) units produced by pysm. See the following presentation for some details about detector simulations: TES Simulation.pdf.

Should we:

1. Allow all modules to process data in all possible units needed by the users? As discussed during the telecon, this may be not a very efficient way.
2. Provide a module/function that converts between units needed by the users? If we are going to follow this line we should get some feedback from the collaboration about the units we should consider. Then get conversion factors, input models, etc. and agree on who and how is in charge of producing them.
3. Just specify the units for each module and leave it to the user to convert according to his/her own needs?
4. Other options?

Comments are more than welcome.

[mreineck]

In Planck LevelS the physical unit of every possible kind of data product was specified in a document (the DDL), so all modules knew unambiguously in which units their inputs were provided and how exactly they had to write their output. This puts some additional burden on the module developer, but I would argue that this is manageable. This is slightly different from your option 3) as it associates the units with the data products instead of the module inputs and outputs.

Option 1) puts way too much extra work on module developers, I'd say.

Option 2) is kind of neat, but can be dangerous for some units, whose conversion depends on yet other quantities; a particularly nasty example is antenna temperature vs. thermodynamic temperature, where the conversion depends on on a lot of detector characteristics. I'm not sure this is a can of worms we want to open ...

[ziotom78]

We could go with solution 3, and permit solution 2. on a case-by-case basis; for instance, a tool to convert between power and temperature/intensity for the CR module that is bundled with the framework. In this way, people do not have to reinvent the wheel, but we (hopefully) keep the number of conversions limited to those cases where this is actually a benefit.

[tomma90]

My worry about option 3 is that if we don't agree on some common conversion factors the simulations may end up producing inhomogeneous results.
As for Martin comment about point 2, I guess at some point we will have to open the can of worms. Although I guess that is a collaboration-wide issue and shouldn't be discussed just by the simulation team.

[mreineck]

As for Martin comment about point 2, I guess at some point we will have to open the can of worms.

Someone will have to open it, I agree. My worry is that for example some conversion factors depend on whether a module is using nominal or realistic beam shapes and/or delta or realistic frequency responses ... and only the module itself can know what it is doing. Trying to guess this from outside the modules is really problematic.