-
Notifications
You must be signed in to change notification settings - Fork 50
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
LSTMStateTransitionModel (Closes #330) #340
Conversation
Benchmarking Results
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
This pull request introduces 1 alert when merging 23511e7 into 5bd6a20 - view on LGTM.com new alerts:
|
Benchmarking Results [Update]
To:
|
examples/lstm_model.py
Outdated
m2 = LSTMStateTransitionModel.from_data( | ||
(data.inputs, data.outputs), | ||
sequence_length=4, | ||
epochs=250, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does epochs gets 250 here mean? I assuming that this is part of the LSTMStateTransitionModel?
nonlocal t_counter, x_counter | ||
z = m.output(x_counter) | ||
z = m2.InputContainer(z.matrix) | ||
x_counter = m.next_state(x_counter, future_loading(t), t - t_counter) | ||
t_counter = t | ||
return z |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit complicated for me to personally understand? If you can explain?
examples/lstm_model.py
Outdated
print('Building model...') | ||
m2 = LSTMStateTransitionModel.from_data( | ||
(data.inputs, data.outputs), | ||
sequence_length=4, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also what is sequence_length used for with LSTM?
return z | ||
|
||
# Use new dt, not used in training | ||
data = m.simulate_to(data.times[-1], future_loading, dt=TIMESTEP*3, save_freq=TIMESTEP*3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not used in training?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a comment. Does the comment above answer your question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep makes more sense now!
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
Benchmarking Results [Update]
To:
|
model.compile(optimizer="rmsprop", loss="mse", metrics=["mae"]) | ||
|
||
# Train model | ||
model.fit(u_all, z_all, epochs=params['epochs'], callbacks = callbacks, validation_split = params['validation_split']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume based of the last meeting that this fitness fucntion will be changed. It had something to do with seperate the parts of LSTM so as to not impact and cause the jumpiness we all saw in the output?
…the normalization: normalization seems to be carried out within next_state now; but I suggested to normalize all data before the prediction loop, so next_state always receives (and always outputs) normalized data. De-normalization can be carried out afterwards before returning the result to the user.
Benchmarking Results [Update]
To:
|
First version of the LSTM State Transition Model (Closes #330).
This is a first iteration of a State Transition Model (i.e., no events) using the LSTM RNN algorithm. Note: this is initial implementation, so there is follow-up work to be done (see bottom). The initial version will take in data from one or more runs to generate a prognostics model which can then be interchanged with a regular prognostics model (full compatibility with prog_algs will be tested later, see nasa/progpy#28).
Our LSTM approach maps from past and current input and past outputs to current output. i.e.,
[z_t-n, u_t-n+1, z_t-n+1, ... z_t-1, u_t] -> z_t
where z is output, u in input, t is current time, n is sequence length (i.e., window size). This is applied repeatedly to predict forward. Past outputs and inputs are stored in the system state.
This is not very robust - it can only work with simple models. I test this using an example where I build a model with data generated from the ThrownObject model with a set timestep and a different time step. At inspection it matches the behavior well.
It was unable to match the behavior of more complex data from BatteryElectroChem or BatteryCircuit. I'm hoping some of the work planned in follow-up issues will improve performance enough to capture that.
Changes made:
Additional questions for reviewers:
Follow-up issues