Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing radiative transfer control variables #772

Open
kslong opened this issue Sep 30, 2020 · 2 comments
Open

Confusing radiative transfer control variables #772

kslong opened this issue Sep 30, 2020 · 2 comments

Comments

@kslong
Copy link
Collaborator

kslong commented Sep 30, 2020

Currently, we use several variables to control radiation transvariables. These include

rt_mode
ioniz_mode
macro_ioniz_mode
macro_simple
matom_radiation

Several of these are just have True or False values, essentially, but the names don't say what this means so one has to go back and look at the definition to find out, or add a comment to explain. It's also not clear that we need this large number of variables. For example, why do we need both an ioniz_mode and a macro_inoniz_mode. We should try to improve this, and possibly combine some variables.

@jhmatthews
Copy link
Collaborator

I agree these are confusing. I don't believe any of them can be simply combined (at least not if the old behaviour is desired), because they all control slightly different things.

Here's what they actually do and my assessment of name/utility of each:

  • rt_mode: How to treat radiative transfer - do you want to use indivisible packets and either macro-atoms or "fake macro atoms" / simple atoms, or use weight reductions and Lk02 style two-level treatment for line transfer. Note this can be altered regardless of whether macro-atom data is actually in the code.
    • Probably a reasonable name.
  • ioniz_mode: the actual ionization mode as set in the parameter file. Not really related to matoms at all.
    • Probably a reasonable name.
  • macro_ioniz_mode: whether to use estimators for macro-atom level populations or use the same approximations as for simple ions. I think this should always be on apart from for the initialisation.
    • Improve name?
  • macro_simple: decide whether to force a "simple two level treatment" of all lines and continua, even if macro-atoms have been read in. Probably useful as a diagnostic and can be accessed through line transfer modes 8 and 9.
    • Improve name?
    • possible duplication with macro_info records in the line list - could instead set all macro_infos to FALSE when this mode is required.
  • matom_radiation: this tells the code whether to use "pre-computed emissivities" for macro-atoms, or do the full rad eq calculation.
    • Improve name?
    • might be unnecessary if it's only turned on in spectral cycles (could use ioniz_or_extract instead?).

@kslong
Copy link
Collaborator Author

kslong commented Oct 1, 2020

I agree making the names more sensible would go a long way to clarifying the situation, although it is not completely obvious to me there could not be some consolidation. For example, macro_ioniz_mode could be simply a check as to what ionization cycle we are in, and macro simple might be a separate rt_mode. matom_radiation as you say might be tied to spectral cycles explcity, or again could be a rt_mode.

If we just change names, these might be possibilities

macro_ioniz_mode --> macro_use_estimators
macro_simple --> macro_use_2level_method
matom_radiaton --> macro_use_precompted_emissivites

All could be answered by True False

@kslong kslong changed the title Confusing radiative transfer control varabiles Confusing radiative transfer control variables Jan 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants