Skip to content

Add possibility to convert Non Linearity factor from 1/K to 1/SR#524

Open
mj-gomes wants to merge 6 commits into
masterfrom
non_lin_specrad
Open

Add possibility to convert Non Linearity factor from 1/K to 1/SR#524
mj-gomes wants to merge 6 commits into
masterfrom
non_lin_specrad

Conversation

@mj-gomes
Copy link
Copy Markdown
Contributor

This is one other feature that I had been using in the HWP simulations and that was not yet in lbs.

It allows to pass a flag to sim.apply_quadratic_nonlin to convert the non linearity factor (g) from 1/K to 1/SR (spectral radiance units), so that we keep coherent units when computing the TOD in spectral radiance units and then inserting the non linearity effect on it.

Should we also make this information (the conversion flag and also the sampled value for the non linearity factor) available in the automatic output simulation report?

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 22, 2026

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  litebird_sim
  __init__.py
  detectors.py
  hwp.py
  non_linearity.py 104, 112-117
  observations.py
  scan_map.py
  simulations.py 2137
  litebird_sim/hwp_harmonics
  hwp_harmonics.py 42
Project Total  

This report was generated by python-coverage-comment-action

@mj-gomes mj-gomes added the enhancement New feature or request label May 22, 2026
@ziotom78
Copy link
Copy Markdown
Member

Hi @mj-gomes, these changes look fine to me.

I believe that this information should definitely be included in the report! In this way, whoever reads it can check if the units were used consistently.

I would add an item about convert_K_to_SR in the docstring for Simulation.apply_quadratic_nonlin (just copy the one from apply_quadratic_nonlin_for_one_detector).

Thanks!

@mj-gomes
Copy link
Copy Markdown
Contributor Author

mj-gomes commented May 22, 2026

Hi @mj-gomes, these changes look fine to me.

I believe that this information should definitely be included in the report! In this way, whoever reads it can check if the units were used consistently.

I would add an item about convert_K_to_SR in the docstring for Simulation.apply_quadratic_nonlin (just copy the one from apply_quadratic_nonlin_for_one_detector).

Thanks!

It's done. It's the first time I deal with the append_to_report method, but from what I understand it is sufficient adding conv_K_to_SR as an argument, since the method deals automatically with the kwargs. Is this correct?

If so, I would say this can be merged (in any case it does not introduce breaking changes to anything already implemented).

@ziotom78
Copy link
Copy Markdown
Member

It's done. It's the first time I deal with the append_to_report method, but from what I understand it is sufficient adding conv_K_to_SR as an argument, since the method deals automatically with the kwargs. Is this correct?

Partially, but this is not enough to make the value of the parameter appear in the report. Internally, LBS uses the Jinja2 template engine to produce the Markdown reports, so you must make sure that the new variable appears somewhere in the final report.

Take a look at litebird_sim/templates/report_mpi.md: it uses the variables mpi4py_version, mpi_implementation, mpi_version, and warning_mpi_version to decide what to put in the report. In your case, I believe that the best option would be to use an if. Something like

{% if conv_K_to_SR -%}
Put the text that should be produced when the variable is True
{% else %}
Put the text that should be produced when the variable is False
{% endif %}

BTW, I couldn’t find any template report for the HWP non-linearity module in the templates folder, so you should probably create one first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants