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

Add nonlinear constant turn models. Update transition model class hierarchy #506

Merged
merged 3 commits into from
Feb 17, 2022

Conversation

DaveKirkland
Copy link
Contributor

Added nonlinear constant turn models. Moved nonlinear class up into the model i.e. all models are inherently nonlinear. Linear models are a subclass. Added tests for the StateVectors class.

Replaced CombinedLinearGaussianTransitionModel and CombinedNonlinearGaussianTransitionModel with CombinedGaussianTransitionModel which is now in the base class. This will break a lot of existing code that used these combined models but it is an easy fix e.g. replace CombinedLinearGaussianTransitionModel with CombinedGaussianTransitionModel.

@DaveKirkland DaveKirkland requested a review from a team as a code owner October 1, 2021 18:10
@DaveKirkland DaveKirkland requested review from sdhiscocks and idorrington-dstl and removed request for a team October 1, 2021 18:10
Comment on lines 33 to 53
# class CombinedLinearGaussianTransitionModel(LinearModel, _CombinedGaussianTransitionModel):
# r"""Combine multiple models into a single model by stacking them.

The assumption is that all models are Linear and Gaussian.
Time Variant, and Time Invariant models can be combined together.
If any of the models are time variant the keyword argument "time_interval"
must be supplied to all methods
"""
# The assumption is that all models are Linear and Gaussian.
# Time Variant, and Time Invariant models can be combined together.
# If any of the models are time variant the keyword argument "time_interval"
# must be supplied to all methods
# """

def matrix(self, **kwargs):
"""Model matrix :math:`F`
# def matrix(self, **kwargs):
# """Model matrix :math:`F`

Returns
-------
: :class:`numpy.ndarray` of shape\
(:py:attr:`~ndim_state`, :py:attr:`~ndim_state`)
"""
# Returns
# -------
# : :class:`numpy.ndarray` of shape\
# (:py:attr:`~ndim_state`, :py:attr:`~ndim_state`)
# """

transition_matrices = [
model.matrix(**kwargs) for model in self.model_list]
return block_diag(*transition_matrices)
# transition_matrices = [
# model.matrix(**kwargs) for model in self.model_list]
# return block_diag(*transition_matrices)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the entire class is commented-out, it should probably be deleted. Though I think having the 'linear' combined model is still useful. Applying the combined transition via a single matrix multiplication will be quicker than the model-by-model logic of the combined parent class.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks like I forgot to remove that.
To handle time varying models, the total matrix has to be rebuilt at each call. Also because the total matrix is block diagonal, the full matrix multiply involves a lot of multiply by zero operations. It may make sense to do the smaller matrix multiplies and stitch together the result. It would probably be useful to benchmark the results to see if there is a significant performance hit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oharrald-Dstl @sdhiscocks I've done some benchmarking and indeed the CombinedLinearGaussianTransitionModel is faster than the general implementation. I will add it back in, but utilize the new class hierarchy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated the branch. I added back the CombinedLinearGaussianTransitionModel - this will also avoid breaking much of the existing code. I also fixed some of the issues may changes broke surrounding the simple initiator and it's associated test scripts. These issues were cause by code like isinstance(xxx, NonLinear).

@DaveKirkland DaveKirkland force-pushed the Nonlinear_Models branch 3 times, most recently from 155cd96 to 8974993 Compare October 7, 2021 14:36
Copy link
Member

@sdhiscocks sdhiscocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

Main issue is the function method needs to support vectorised input, which only requires minor change, and original jacobian method effectively tests this.

stonesoup/models/base.py Outdated Show resolved Hide resolved
stonesoup/models/transition/base.py Show resolved Hide resolved
stonesoup/models/transition/base.py Outdated Show resolved Hide resolved
stonesoup/models/transition/base.py Show resolved Hide resolved
stonesoup/models/transition/nonlinear.py Outdated Show resolved Hide resolved
stonesoup/models/transition/nonlinear.py Outdated Show resolved Hide resolved
@@ -1,28 +1,17 @@

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to introduce edits to this file?

@@ -15,7 +15,7 @@
"cell_type": "markdown",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to introduce edits to this file?

@oharrald-Dstl
Copy link
Contributor

As there are now two ConstantTurn models, the files:
docs/source/auto_examples/Smooth_Platform_Coordinate_Transitions
stonesoup/simulator/transition.py
will require a specific model be referenced.

@sdhiscocks
Copy link
Member

As there are now two ConstantTurn models, the files: docs/source/auto_examples/Smooth_Platform_Coordinate_Transitions stonesoup/simulator/transition.py will require a specific model be referenced.

Good point. I wonder whether it would better to change name of the models? What about ConstantTurnRate maybe for the linear one; or maybe call one CoordinatedTurn (or would that cause confusion)?

@DaveKirkland
Copy link
Contributor Author

As there are now two ConstantTurn models, the files: docs/source/auto_examples/Smooth_Platform_Coordinate_Transitions stonesoup/simulator/transition.py will require a specific model be referenced.

Good point. I wonder whether it would better to change name of the models? What about ConstantTurnRate maybe for the linear one; or maybe call one CoordinatedTurn (or would that cause confusion)?

@oharrald-Dstl @sdhiscocks
I was thinking of 'KnownTurnRate' and also 'KnownTurnRateSandwich' for the linear models and leaving the nonlinear models as 'ConstantTurn' and 'ConstantTurnSandwich' - thoughts?

@DaveKirkland
Copy link
Contributor Author

@sdhiscocks I refreshed the commit with the new class names and merged with the main branch. I'm not sure why it has changes for the Video_Processing.ipynb and associated rst and gif files - I didn't changed them.

I also tried rebasing with HEAD~2, but this picks up more than 20 previous commits and I wasn't quite sure how to handle that.

@sdhiscocks sdhiscocks added the breaking A breaking change that required other to modify their code label Feb 2, 2022
@codecov
Copy link

codecov bot commented Feb 2, 2022

Codecov Report

Merging #506 (16b988b) into main (a8760f9) will increase coverage by 0.03%.
The diff coverage is 98.29%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #506      +/-   ##
==========================================
+ Coverage   94.32%   94.36%   +0.03%     
==========================================
  Files         154      154              
  Lines        7352     7435      +83     
  Branches     1399     1410      +11     
==========================================
+ Hits         6935     7016      +81     
- Misses        314      315       +1     
- Partials      103      104       +1     
Flag Coverage Δ
integration 68.04% <37.60%> (-0.56%) ⬇️
unittests 91.74% <97.43%> (+0.06%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
stonesoup/models/transition/base.py 95.91% <93.33%> (-4.09%) ⬇️
stonesoup/initiator/simple.py 97.32% <100.00%> (ø)
stonesoup/models/base.py 100.00% <100.00%> (ø)
stonesoup/models/measurement/nonlinear.py 98.94% <100.00%> (ø)
stonesoup/models/transition/linear.py 100.00% <100.00%> (ø)
stonesoup/models/transition/nonlinear.py 100.00% <100.00%> (ø)
stonesoup/plotter.py 95.52% <100.00%> (ø)
stonesoup/simulator/transition.py 94.52% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8760f9...16b988b. Read the comment docs.

@sdhiscocks
Copy link
Member

@sdhiscocks I refreshed the commit with the new class names and merged with the main branch. I'm not sure why it has changes for the Video_Processing.ipynb and associated rst and gif files - I didn't changed them.

I also tried rebasing with HEAD~2, but this picks up more than 20 previous commits and I wasn't quite sure how to handle that.

I reverted the changes to the video processing demo, and then squash it back into your original commit, rebased onto main. Also added a extra commit, just to fix documentation failure.

@sdhiscocks sdhiscocks merged commit efb1ba2 into main Feb 17, 2022
@sdhiscocks sdhiscocks deleted the Nonlinear_Models branch February 17, 2022 09:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking A breaking change that required other to modify their code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants