Closed zonca closed 2 years ago
@giuspugl for now I have just imported the class from so_pysm_models
, so it has the problem that it has a different interface compared to the other models, see docs https://so-pysm-models.readthedocs.io/en/latest/models.html#colines
I think in PySM 3 I could do a standard interface:
@u.quantity_input
def get_emission(self, freqs: u.GHz, weights=None) -> u.uK_RJ:
freqs = utils.check_freq_input(freqs)
weights = utils.normalize_weights(freqs, weights)
# check if each line is in the frequency range
# if not return zeros
# If yes multiply it for the weight interpolated linearly at the line frequency and return the map
# make sure to support multiple lines in same detector
Line frequencies are:
"10": 115.271 * u.GHz,
"21": 230.538 * u.GHz,
"32": 345.796 * u.GHz,
@giuspugl seems reasonable?
Hi @zonca , yes to me seems reasonable and we can keep this interface even in the case we 're going to update the CO templates.
Should we have presets for CO like for other models?
We could name them co1
, co2
, co3
and add them to https://github.com/galsci/pysm/blob/main/pysm3/data/presets.cfg, they are just fixing a set of input parameters for the class.
@giuspugl @seclark @brandonshensley how could we organize the presets (like d1
,d2
for dust) ?
we definitely want 1 model with all 3 lines, that could be co1
.
Then do we also want models with just 1 line? not familiar how people generally use CO templates.
My feeling is we should have one model that contains all the lines we provide and just list the transitions and frequencies in the documentation. I could see a need to provide higher J transitions in the future.
The Planck Commander analysis also had a "94/100 GHz" line map which is HCN among other things (see bottom of page 11 of the linked paper). Do we provide that too? Not so critical since it is mostly concentrated in the Galactic Center, just thinking completeness.
I agree with this. I can't really see a use case for only one CO line (although of course what's relevant depends on frequency). It's important to fix the names of each implementation for backward referencing, though. We could call what we have implemented now lines1
and build from there?
I agree with this. I can't really see a use case for only one CO line (although of course what's relevant depends on frequency). It's important to fix the names of each implementation for backward referencing, though. We could call what we have implemented now
lines1
and build from there?
I'll let @giuspugl reply to @brandonshensley about modelling.
yes, we can fix what we have now, I would call it co1
, we want to keep it short.
Hi all,
We can include the high - galactic clouds stochastically (or not) with the CO model we derived in (https://arxiv.org/abs/1701.07856), as co2
(w/o stochasticity). I hardly think that we 'll need stochastic realization of CO emission for time being but surely is a direction we might want to incorporate in the future. To this regard @brandonshensley
, @seclark , @NicolettaK and I have been working on a different approach encoding neural networks...
I agree that for completeness inclusion of HCN line is definitely something we want to include for! However that's not a CO line so wouldn't include into this pull request. I 'll think of a new way to include also this extra-lines that are of interests both for ground and space experiments.
See https://github.com/galsci/pysm/issues/103#issuecomment-1014213983
so:
co1
polarization fraction 0, include_high_galactic_latitude_clouds=False
co2
polarization fraction 0.001, include_high_galactic_latitude_clouds=False
co3
polarization fraction 0.001, include_high_galactic_latitude_clouds=True
(not stochastic)rebased on main
@giuspugl @brandonshensley @seclark
I've completed the CO models, the actual definition is in presets.cfg
please also take a look at the docs: https://pysm3--86.org.readthedocs.build/en/86/models.html#co-line-emission
@giuspugl @brandonshensley is this ok to merge?
Fine for me ! thanks a lot !