-
Notifications
You must be signed in to change notification settings - Fork 26
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
Add keyword argument in AbstractManualThrustFlightPhase class #382
Comments
Not in the version you use, I'm afraid. In current version (1.0.5), it would be possible to do something more efficient: What is currently not advertised in the documentation, is that it is possible to build very easily custom segment types, by subclassing the class FlightSegment. As said in the example of the class documentation, you can create a class Another thing to be known, is that the segment parameters that are available in the mission file are declared in the segment classes as dataclass fields. Therefore, anywhere in the code you run, you may define a new class like this one: from fastoad.models.performances.mission.segments.speed_change import SpeedChangeSegment
@dataclass
class SpeedChangeElectric(SpeedChangeSegment, mission_file_keyword="speed_change_electric"):
electric_power_rate: float = 0.0 # do not forget the type hint, required by the data class syntax,
# and the default value that is needed "because of the inheritance" (short story) With only these few lines, you get a usable segment type for the mission files, called The drawback of this method (besides the fact that you are not using the needed version of FAST-OAD) is that you have to do |
Hello Christophe, Thanks for the answer. I haven't planned to upgrade to the latest version anytime soon, but thanks for the insights. Regarding the segment classes, I am aware the simplest thing to do would be to add the decorator @AddKeyAttributes({"electric_power_rate": 0.}) the line before the class definition of 'ManualThrustSegment', however that would mean having to modify the original FAST-OAD files, whereas I try to keep the whole FAST-OAD directory unchanged. Therefore in order to avoid too many redundancies of classes I preferred to create a new 'SpeedChangeSegment' and 'AltitudeChangeSegment' as follows: from fastoad.models.performances.mission.segments.altitude_change import AltitudeChangeSegment
@AddKeyAttributes({"power_rate_electric": 0.0})
class AltitudeChangeSegmentHybrid(AltitudeChangeSegment):
"""
Computes a flight path segment where altitude is modified with constant speed
with a given thrust_rate and electric_power_rate
"""
def _compute_propulsion(self, flight_point: FlightPoint):
flight_point.thrust_rate = self.thrust_rate
flight_point.power_rate_electric = self.power_rate_electric
flight_point.thrust_is_regulated = False
self.propulsion.compute_flight_points(flight_point) |
I have also tried to do something like this: AddKeyAttribute("power_rate_electric",0.)(SEGMENT_KEYWORD_ARGUMENTS) Howevr adding this line at the beginning of my standard_flight class give me the following error: Why is that? I was expecting it to work exactly like for the flight_points class |
I guess it is because "SEGMENT_KEYWORD_ARGUMENTS" is simple dictionary, whereas FlightPoint is a DynamicAttributeDict. Is that right? |
Thank you for these elements. I had completely forgotten about the And actually, it allows you to avoid duplicating segment classes. You just have to run the line AddKeyAttributes({"electric_power_rate": 0.0})(ManualThrustSegment) and you get this attribute available in this class and its inheritors. Nevertheless, since your original question is about |
Just realizing my last comment is probably irrelevant, because you have to manage your electric_power_rate parameter in the ManualThrustSegment class, hence you have to produce your own version of this class... And though the architecture has changed, I think that problem still applies to version 1.x. We will have to check that out... |
Hello,
I have an "electric_power_rate' variable that I want to pass to the engine class as it's done for the 'thrust_rate' variable. In order to do that, I had to create a new 'AbstractManualThrustFlightPhase' class to add the new variable. Is there a better way to do it which doesn't lead to this kind of redundancy?
N.b.: I am using the version 0.5.4b0
Thanks,
Vincenzo
The text was updated successfully, but these errors were encountered: