vibrationtoolbox / vibration_toolbox

Educational Vibration programs. Intended for undergraduate and early graduate students.

The Engineering Vibration Toolbox for Python

Joseph C. Slater and Raphael Timbó

Welcome to the Vibration Toolbox. This Python version is a completely new design build for modern education. This is an educational set of codes intended primarily for demonstration of vibration analysis and phenomenon. You may find them useful for application, but that isn't the intent of this toolbox. If you have professional-level needs please contact the authors.

Full documentation is available, but please excuse that it is still under development. Such documentation has never existed for the other ports of the toolbox so this is taking some time. We don't need feedback at this time, but we will take assistance in improving documentation and code. Please clone the repository and support use by submitting pull requests fixing typos and clarifying documentation.

Try now!

You won't get everything, but you can try parts of the toolbox immediately by riunning the tutorial on mybinder.org, right in your browser window!

Installation

If you aren't familiar at all with Python, please see Installing Python.

Installation is made easy with pip (or pip3), with releases as we have time while we try to create a full first release. Much of it works already, but we certainly need issue reports (on github).

To install type:

pip install --user vibration_toolbox

at your command prompt (not the python prompt) where --user isn't necessary if you are using a locally installed version of Python such as Anaconda.

To run, I recommend you open a Jupyter notebook by using jupyter notebook at your command prompt/terminal prompt/Anaconda prompt and then type:

import vibration_toolbox as vtb

For examples, see the JupyterNotebooks folder. Some of these have interactive capabilities that are only apparent when you run them yourself instead of just looking at them on GitHub. Unfortunately our organization of these still leaves a little to be desired. Help accepted!

Installation of current code/contributing

The usage documentation is far behind the current code, while the reference is way ahead of the released code due to the autodoc capability of Sphinx. Especially as of 2017, the code is still in rapid development. So is the documentation. Releases to pypi.

If you wish to install the current version of the software, and especially contribute, please follow the instructions in Contributing.rst

That should be it. Please note issues on the issues tab on GitHub.

vibration_toolbox's Issues

modes_system in mdof- if C is proportional, wd ≠ w if C ≠0

If C is proportional, modes_system returns incorrect damping ratios.

Needs insertion of a unit test as well.

I believe the code is fixed.

proportion to C or M must result in underdamped system for test cases
Damping ratios are diag(S.T@C@S/2/Omega) (pseudo-code)

Files organization

Joseph,
I think the file vtoolbox.py is getting large (675 lines now) and I am having trouble to find things inside the code.
I was thinking about creating different files and then I would import those in the vtoolbox.py.
Ex.: create a free_response.py with the functions for free response. Inside vtoolbox.py we would have from free_response import sdof_free response, sdof...
I think this would help to organize things.
I don't know in which way the files could be named. I was thinking about something related to the chapters from Inman.
What do you think about that?

Any of you had problems running doctests.py on spyder?

File "C:\Users\Admin\Anaconda3\lib\doctest.py", line 357, in init
pdb.Pdb.init(self, stdout=out, nosigint=True)

TypeError: init() got an unexpected keyword argument 'nosigint'

while I run .py files on spyder. I looked into it online and one of the solutions is to edit pdb.py. Here is the link-
http://stackoverflow.com/questions/37669435/python-3-5-typeerror-init-got-an-unexpected-keyword-argument-nosigint

Notebooks organization

I was thinking that we could organize the notebooks in the following way (I am thinking here based on what I have seen in other projects)

We would have the notebooks in two different places:

• Tutorials : here we would have one specific notebook for each module (sdof, mdof, ema etc.) The purpose of these notebooks would be to go through the modules functionalities.

• Gallery (or something like that) : Here we would have any kind of notebook that uses the toolbox to explore some vibration aspect, interest thing etc. The beat phenomenon notebook for example would go here.

What do you think?

"@" is a python operator?

like c=a@b; I can not find this operator in python2 and python3

Doc string corrections.

We need to polish up the docstrings.

Many miss a few key points, and many don't follow the numpy docstring convention

Specifically, the first line should be a terse stand-alone description. The second line blank, with a more complete description.

Variable types are inconsistent in name. The numpy standard should be followed. (I don't recall at the moment.)

Word `iPython` on documentation should be changed to `Jupyter`

Word iPython on documentation should be changed to Jupyter

Developer notes / Contributing

Currently we have some files inside the project that give some guidance on how to develop code for this project, but I think it would be good if we could discuss which files we should have and what they should contain.
Currently we have notes on:
readme.rst
vibration_toolbox/readme.rst
developer_notes.rst
create_distro.rst

I believe we could merge some of these files in a CONTRIBUTING.rst or something like that, just to make it easier to get the information.
Would like to hear your opinions @josephcslater @AnushaAnisetti

Regarding the content of the files, I think we should cover:

EDITING THIS PART AS WE DISCUSS

• Where to find support in case of doubts on how to use the toolbox.

• Explain where and how to report bugs.

CONTRIBUTING.rst See #42

• Explain standards adopted for the project such as numpydoc conventions

• Explain how to run tests

• Steps to take before submitting to Github.

• ...

Feel free do add items here.

proposal to merge with vibrationtesting

Dear @josephcslater,

Due to low activity in this repository, I would like to propose to merge this repository
with vibrationtesting.

I still use both to teach vibration courses; instead of installing separate packages,
it will be simpler to use one package only (vibrationtoolbox).

Thank you for your great effort.
I hope this project will continue (implementing all concepts in Inman's vibration & control).

Standardization of modules

I'd like to standardize on using sp in place of np as it's simpler and more consistent for users if they can use fewer calls in general. np ends up looking like a subset of sp in the way sp has evolved.

These changes include all modules and notebooks here.

vt for short name should be vtb to avoid confusion with Vibration Testing

`eval` should not be used

Use https://stackoverflow.com/questions/2371436/evaluating-a-mathematical-expression-in-a-string instead.

Vib should be Vibe in methods, classes, names, documents

Consistent typo error that will break code. Needs edits throughout.

I think setting up travis-ci is not quick and easy now

Hello Dr. Slater,

Steps to install in contributors mode may need to be changed or clarified. As following those steps lead to a note that says "GitHub services are being depreciated". For more details, please go thru the screenshot attached below:

Thanks,
Sainag.

FRF code should be vastly simplified so any mode/frequency pairs can be used in call

Should work with MDOF or Continuous. Should be demonstrated as a common function in MDOF and continuous sections

Interactive functions may need to be retested

I've found other cases where interactive has failed. Solution is to add plt.show() at the end of all plotting.

ema examples not working when followed by user.

Jupyter Notebooks

We need to figure out how the notebooks we use in the documentation can easily be accessed in whole and downloaded by users from within the online documentation. I've seen this capability elsewhere in other packages using sphinx and jupyter, but cannot recall where.

Implementing unit tests

List of test files to be added (one for each module):

• test_sdof.py
• test_mdof.py
• test_sdof.py
• test_continuous_systems.py
• test_ema.py
• test_vibesystem.py

---

@josephcslater I saw your commits and comments regarding implementing unit tests instead of having only doctests. I totally agree that we should do that.
I think it would be a good idea to split the tests between files that will test each module (test_sdof.py, test_mdof.py...) to avoid having lots of tests in only one file.

I was taking a look at the travis build history. I saw the following error when you tried to add the test file:

______ ERROR collecting vibration_toolbox/tests/test_vibration_toolbox.py ______
ImportError while importing test module '/home/travis/build/vibrationtoolbox/vibration_toolbox/vibration_toolbox/tests/test_vibration_toolbox.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
vibration_toolbox/tests/test_vibration_toolbox.py:3: in <module>
    import vibrationtesting as vt
E   ModuleNotFoundError: No module named 'vibrationtesting'
!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!!
=========================== 2 error in 1.81 seconds ============================

Was this vibrationtesting module added to the commit? I could not find it.
The tests were failing on your local machine?

Embedding widgets in sphinx docs- should this work?

jupyter_sphinx.embed_widgets

I'm wondering if we can run the plots inside the documents on the web with this.

Error: module 'vibration_toolbox' has no attribute 'time_plot'

I just want to try vibration_toolbox for the first time and it gives me an error when following the very first tutorial in the documentation (SDOF).

The first tutorial should work out the box, I think.

In [1]: import vibration_toolbox as vtb                                         

In [2]: vtb.time_plot()                                                         
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-8990cfc61e28> in <module>
----> 1 vtb.time_plot()

AttributeError: module 'vibration_toolbox' has no attribute 'time_plot'

In [3]: vtb.__version__                                                         
Out[3]: '0.6.7'

Needs help

Functions need help and need self-tests within help in pvtoolbox.py

Vibration tool box

Hi ,
I am recording data via endaq sensor.
I want to use vibration tool box for the analysis purpose.
I know the same tool is available in MATLAB.
But I want to use vibration tool box in python.
WIll this tool fulfill my requirements if I will use?
Please suggest whether to use or not.

Won't pass Travis-ci tests

Seem to be related to plotting within functions.

Per Raphael:

I was taking a look at this blog post

Getting things to work on Travis

I ran into two issues on Travis:

Generating matplotlib figures on Travis with a backed that requires DISPLAY will fail if it is not set.
Even if display is set, Travis may use a different backend than you do locally, which may lead to test failure (e.g., because the images produced have different numbers of pixels).
Both of these are solved by ensuring that matplotlib uses the agg backend for the tests (both locally and on Travis). To set the backend to agg, just add the command

matplotlib.use('agg')

This line must be executed before you import pylab or matplotlib.pyplot. This is very tricky if you are using nose, because nose actually imports every file in your package during the test collection phase.

Maybe this could be an option, but it looks like it is not simple to make these things work on Travis.

Sometimes the user might want just the output of the function, so another option would be to create a default arg for these functions like (..., plot=False).

Needs beams and rods test cases for all boundary conditions.

Needs tests for all of boundary conditions for beams and rods.

modes_system in mdof- example is impossible

Unit test case is a wrong answer. There is no such thing as a negative damped or undamped natural frequency.

This is a critical fault.