search

tudat-team / tudat

A C++ platform to perform astrodynamics and space research.
BSD 3-Clause "New" or "Revised" License
17 stars 27 forks source link

Feature request: two-step exponential model for Mars #104

Open gaffarelj opened 2 years ago

gaffarelj commented 2 years ago

The exponential atmosphere model currently implemented for Mars is accurate only roughly up to 25km. As suggested in _Gallais, P. Models of Atmosphere, pages 21–29. Springer Berlin Heidelberg, 2007. doi:10.1007/978-3-540-73647-9_3_, two distinct exponential atmosphere model can be fitted: one for 0-25km, and one for 25+km, see Table 3.2 of the above reference: image To motivate this implementation, here is a plot I just made comparing the simple exponential atmosphere model (currently implemented), the one I call "two-step" exponential model, as well as Mars GRAM 2010 (truncated after 250km), and the MCD 5.3: image This shows the two-step exponential model stays closer to both Mars GRAM and the MCD. I do not suggest replacing the existing exponential model, but giving the option between the one-step or two-steps models.

DominicDirkx commented 1 year ago

I think this would be a worthwhile model to implement, and can think of a couple of options:

My preference would be for the latter, implementing both the interface options. What are your thoughts on this?

gaffarelj commented 1 year ago

A little late, but I finally caught up to my emails...

Implement this, with only the scale height for the second model (>25 km) provided, and the reference density calculated from enforcing continuity at the switch point

I would not be entirely in favor of this. If I understand correctly, this would mean that we then have an incorrect density as a function of altitude between 0-25km. This means that, between the current implementation, and this suggestion, a user would have to choose between having an accurate density before or after 25km, but never both.

Alternatively, we could implement the above (both options) as a succession of not just 2, but N, exponential atmosphere models

This would definitely have my preference. Especially since this model could then be made configurable, by passing for instance a list of altitudes, reference density, and scale heights, having by default the current or (linked) two-step models. This would actually allow having just one function defined for exponential atmosphere, with some default options (including the current one) being available (and exposed) to users, to avoid breaking backward-compatibility

DominicDirkx commented 1 year ago

No worries, there is no rush with this issue :)

Implement this, with only the scale height for the second model (>25 km) provided, and the reference density calculated from enforcing continuity at the switch point

I would not be entirely in favor of this. If I understand correctly, this would mean that we then have an incorrect density as a function of altitude between 0-25km. This means that, between the current implementation, and this suggestion, a user would have to choose between having an accurate density before or after 25km, but never both.

Well, kind of. It would allow different scale heights at different altitudes, but would enforce that the curve of density as a function of altitude is continuous, which imposes a constraint on the combination of reference density and scale height for each atmosphere range

Alternatively, we could implement the above (both options) as a succession of not just 2, but N, exponential atmosphere models

This would definitely have my preference. Especially since this model could then be made configurable, by passing for instance a list of altitudes, reference density, and scale heights, having by default the current or (linked) two-step models. This would actually allow having just one function defined for exponential atmosphere, with some default options (including the current one) being available (and exposed) to users, to avoid breaking backward-compatibility

Indeed, this would allow full control to the user to impose scale heights/reference densities. But, but allowing this control, the user can also provide values that lead to discontinuities in the density with altitude.

I think that having both could be advantageous as interfaces (depending on whether you want to be sage, or in control)

gaffarelj commented 1 year ago

I think that having both could be advantageous as interfaces (depending on whether you want to be sage, or in control)

I totally agree, this should be the way to go then I think. I also gives user a choice to go more in depth or not in their implementation (and so if they don't want to, we avoid making this too complex as a default)