partmor / ezaero Goto Github PK

Let me propose an interesting upgrade: imagine we want to carry out a simulation on a general wing geometry like the one shown below:

At the moment, ezaero is able to properly mesh and solve for trapezoidal lifting surfaces. This new feature would require a software refactoring, but any geometry could be generated!

I propose the following steps to achieve this new feature:

• Generate a vlm/lifting_surface.py module which holds the definition of a LiftingSurface class. This class holds all geometrical definitions for a small trapezoidal section. It contains a plot() method for showing the current geometry without having to run a simulation. Also, it includes a new r_offset when building the object, which is the position vector of the leading edge of the root. This will enable to move the part along the global model geometry.

• Instead of a single wing, a list of LiftingSurfaces modeling the global geometry is passed to the Simulation instance. Influence coefficient matrices are stacked and a global solution is finally achieved. Testing cases can be implemented from this online solver.

Let me now what you think about this new feature when possible, @partmor 👍

Enable intersphinx with numpy and matplotlib.

Thank you for this awesome package! I was coding my own VLM (due to academical reasons) when just discovered ezaero and would like to extend some of its capabilities.

At the moment, three dimensional visualizations are based on matplotlib. From my point of view, we should keep matplotlib for 2D visualization and use plotly as an interactive display. I've already implemented this feature, see the final result in the figure below this lines. The final figure is completely customizable and be rendered directly in the documentation of the project.

Would you like me to open associated pull request, @partmor?

Define in tox a documentation build testenv.

At the moment, tox.ini file holds several non critical environments: check,coverage,clean,docs and format. Those are configure to run on a Python 3.7 version, see:

We might consider switching those to a general python3 environment, since package tests can be run in both python3.7 and python3.8.

Add docstrings for these classes.

Consider switching CI/CD pipelines to GH Actions.

Currently the project has:

• travis-ci: for Linux and MacOS (does not integrate out-of-the-box with the checks of PRs anymore)
• appveyor: for Windows

In theory both CI providers could be switched to GH Actions (AFAIK, GH Actions supports all the mentioned platforms).

While working in #3, I just noticed that panels are not being generated properly since a local chord shift is being introduced:

This shift should be introduced only within vortex rings, not on wing panels. The bug has not been identified early since for drawing actual geometry of the wing, panel matrix was used. I implemented a geometry visualizer which does not require from a simulation to be used, only needs wing parameters:

Notice how panels are not placed in proper place, they are shifted in the local chord direction. I was finally able to fix this issue, see:

Now panels adapt perfectly to geometry and collocation points are 3/4 of the local chord

Consider including example python scripts in flake8 and isort tests.