Override T to manually set the ambient T°

[fthorey]

Hello,

I was wondering if it would be interesting to add an argument to the ctor of FlightCondition to allow to manually set the T° and not rely on the reference T°. I did a quick and dirty implementation override the T property but maybe that could benefit a larger audience ?

[MattCJones]

Could you expand on this a little more? I'm not sure I understand the issue you are having. Do you have an example I can reproduce?
Thank you!

[fthorey]

It's not actually an issue per se. It's just that I'd like to set the ambient temperature directly to compute the other properties, instead of relying on the atmosphere model that computes it from the altitude, so I can cover other temperature conditions. There is no setter from the @Property T, so I can't really set It directly, nor from the constructor. But maybe I put this message in the wrong place, I would be happy to move it to somewhere else if such a place where we can discuss features rather than issues? Thank you for this great tool! Regard Florian

…

On Sun, 2 Apr 2023, 22:59 MattCJones, ***@***.***> wrote: Could you expand on this a little more? I'm not sure I understand the issue you are having. Do you have an example I can reproduce? Thank you! — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE45YOZJQ5PI4JMNNC2FJDW7HSDXANCNFSM6AAAAAAWQQGBQU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MattCJones]

I think I follow. Currently the ambient temperature is a function of the input altitude using the Standard Atmosphere model. So, the functionality you want is basically setting the temperature and then getting the corresponding altitude and properties?

If I understand that correctly, I think it is worth implementing, so I'll take a look! But, please let me know if I am mistaken.

I'm okay with hashing this out here (: .

[fthorey]

Not exactly, I need to get the properties for a delta temperature at a given altitude. So I would need to be able to speficy the temperature and the altitude as well. Also there is no reason to implement this change for temperature and not for pressure. So maybe the best would be in the constructor to let the user speficy T, P and h. If T is not provided by the user then to fallback to the standard atmosphere model for T. If P is not provided then fallback to the standard atmosphere model for P. But I'm not sure what to do with h if only P and T are provided as they could yield different altitude levels when using the standard atmosphere model. I assume all properties are derived once P and T are prescribed and they don't depends on the altitude, so mostly altitude is not completely required, only the layer class would be affected but maybe it's possible just to say that no altitude is provided.

…

On Mon, 3 Apr 2023, 03:04 MattCJones, ***@***.***> wrote: I think I follow. Currently the ambient temperature is a function of the input altitude using the Standard Atmosphere model. So, the functionality you want is basically setting the temperature and then getting the corresponding altitude and properties? If I understand that correctly, I think it is worth implementing, so I'll take a look! But, please let me know if I am mistaken. I'm okay with hashing this out here (: . — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE45YL6QFSLITFRR6UH5PLW7IO3DANCNFSM6AAAAAAWQQGBQU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MattCJones]

Sorry I got a little distracted, but I finally took at stab at this. You can now overload p and T. I didn't set any logic yet to recompute altitude. Can you let me know if this works for your use case? Cheers!