Replace calculate_los_tau_v with generic column density method

[stephenmwilkins]

At the moment we have the method calculate_los_tau_v on galaxy; this calculates the column density of metals, converts to a dust mass, and then calculates an optical depth (tau_v).

In addition to being fairly opaque, I think we would be better served by having a more generic calculate_column_density method. This should be flexible enough to calculate both the column density of gas but also the column density of any property of the gas (e.g. metals, a specific element, or dust if it exists).

We could then have a method which wraps this to calculate the dust column depth and then a method that wraps that to calculate the optical depth. However, these could also be just part of a pipeline?

[WillJRoper]

It would be nice to have a generic column density method but surely that would would better be done via the map functionality already implemented?

calculate_los_tau_v is specifically relative to each star (to get tau_v for each star), I'm not sure it makes sense to calculate any other column density for each star. A lesser point, but if I remember correctly there were specifics that had to be done in the C making it a bit more difficult to generalise.

What is the use case for any other column density specifically relative to the position of each star?

[WillJRoper]

In fact, I think replacing this with a generic calculate_column_density method is confusing. I would expect a generic column density not to be relative to a star and instead be through the whole galaxy producing a map. Lets not change calculate_los_tau_v.

[stephenmwilkins]

Ah... so there is distinction, the entire column density of the galaxy, which I agree can be done on the map, or the column density to each star particle, which is this calculation. I think they just need a different name but we definitely want a generic column density - to each star - method. It would be useful to know how much gas, metals, and dust (when dust is a property of the gas, as in Simba and COLIBRE) each star particle is seen through.

calculate_stellar_column_density implies the column density of stars so we can't use that. How about calculate_column_density_to_stars? or calculate_column_density_to_star_particles.

[WillJRoper]

Or we could attach it to a stellar component instead and have it take a gas object. That makes sense I think.

[stephenmwilkins]

As for use case:

• using metallicity is important for the current LOS dust calculation
• using a specific element (e.g. carbon or silicon) may be useful for a more sophisticated LOS dust calculation.
• for models with dust as a property of the gas particle obviously we should use that instead for the LOS dust calculation.
• using just the mass of hydrogen (functionally ~75% of the gas mass) could be used to calculate an upper estimate of the ionising photon escape fraction.

[stephenmwilkins]

I prefer it on Galaxy since it needs both stars and gas. However, it could be stars with a wrapper on galaxy.

[stephenmwilkins]

ideal for me if calculate_column_density_to_stars has an optional argument for the gas property (metallicity, dust etc.) to use, otherwise just default to masses.

[WillJRoper]

"using metallicity is important for the current LOS dust calculation" -> the current LOS calculation takes dust mass not metallicity.

But fair on the others.

I prefer get_column_density_per_star which can be attached to a galaxy but I do think this should wrap the main workhorse on Stars (which is currently not the case). It is a stellar method really so makes more sense to have there with an interface on a Galaxy. It can take a string for the attribute to compute which defaults to dust_masses I don't see "masses" being the best default.

[stephenmwilkins]

Hmm... so at some point it converts the metallicity to dust_mass, assuming a dust-to-metal ratio?

I think probably the best pipeline approach is:

1) add a new property to the gas particles which is the dust mass. Perhaps a method to do this? 2) calculate the dust column density. 3) convert a dust column density to an optical depth.

An alternative would be to replace one with a call to calculate the metal surface density. However, this is only really useful if you exploring different dust-to-metal ratios.

I think I'd still advocate for just using masses by default with an optional argument for the property to use otherwise. We could add a convenience wrapper around the generic method along the lines of:

def get_dust_column_density_per_star():
    get_column_density_per_star(property='dust_masses')

[WillJRoper]

This is already done already. It either takes dust_masses as input to a galaxy or @aswinpvijayan calculation is used to calculate a DTM.

It's not a simple as breaking it down like that, some speed would be sacrificed if you split some of the operations out of the C to get to an optical depth. We can't change any of that side of things.

[stephenmwilkins]

But the optical depth is just a scaling of the dust column density so why can't it be outside?

[WillJRoper]

Could be different per particle eventually right?

[stephenmwilkins]

Nope. We might have to do it independently for different types of dust but that's different.