Skip to content
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

Including effect of inputs vector in the output of a model #141

Closed
3 of 6 tasks
WardLT opened this issue Jun 12, 2024 · 2 comments
Closed
3 of 6 tasks

Including effect of inputs vector in the output of a model #141

WardLT opened this issue Jun 12, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@WardLT
Copy link

WardLT commented Jun 12, 2024

Requirement Text
I would like to include a model where the control vector has an influence on the measured outputs, but the interface to PrognosticsModel only includes the state as input.

Background Information
I'm implementing a single-resistor (R_int) equivalent circuit model.

Suggested Solution
Add u to the inputs of PrognosticModel.output, update the use of the model in the various StateEstimator classes.

DoD
edit this to be a list of tasks that need to be completed

  • Implement feature
  • Add to example
  • Add to tutorial
  • Add tests
  • update documentation
  • Add to change notes for next release
@WardLT WardLT added the enhancement New feature or request label Jun 12, 2024
@teubert
Copy link
Contributor

teubert commented Jul 5, 2024

Hello @WardLT

Thanks for your suggestion. Sorry for the delay - I was on paternity leave until this week.

You're describing a pretty common case that we've run into with many of our models. The recommended solution for this is to include your control input in the state vector. This is referred internally as a "pass-through input".

There's a few reasons for this:

  1. We made a design decision early on that the state of the system (used to derive outputs, event states, threshold met, etc.) be completely described by the state vector to simplify and clean model design
  2. Many of the tools we've built rely on this assumption.

I've looked through our public models and cant find an example of passthrough inputs, but it's present in a few of the nasa-internal models.

It would look something like this:

class MyModel:
	def next_state(self, x, u, dt):
		... # Logic of model
		next_x['some_input'] = u['some_input'] # passthrough input

	def output(self, x):
		# use x['some_input']

Is this an adequate solution to your problem? Let me know if this doesn't solve it and we can talk more about your proposed solution.

@WardLT
Copy link
Author

WardLT commented Jul 5, 2024

First, congrats!

Second, passthrough inputs makes sense and I don't forsee it becoming a problem. I'll go ahead and close my PR then find out if I can make this work with our models.

@WardLT WardLT closed this as completed Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants