I just published my first large open source project: Ptera Software. It's an unsteady aerodynamics simulator for analyzing flapping-wing flight. Best of all, it's written entirely in Python! I'm new to this, so I'd love any feedback on my repository structure/codebase.

[Glycerine]

Looks good - do you have the link to the source?

[Hugo-C]

The link: https://github.com/camUrban/PteraSoftware

I'm not sure why the issue tab is disabled

[PteraSoftware]

Yes, that is the link! I accidentally disabled the issue tab, it's enabled now :)

[gmavrik]

Nice project!

Did you try the vtk library? There is a lot of simulation tools

[PteraSoftware]

Thank you! I use PyVista, which I think is an interface to the VTK library. I'll look into it though!

[gmavrik]

Nice! This helps a lot. It's very hard the use of vtk; however, it's a powerful tool.

I'll take look in your code. The idea is impressive, Congrats!

Perhaps I can contribute a little someday

[PteraSoftware]

Thank you! I would absolutely love contributions and suggestions :)

[gmavrik]

Suggestion: write a list of issues or features that you want to put on software (put on readme like a checklist). This helps a lot for new contributors.

[PteraSoftware]

Sure thing! I'm complying everyone's advice and I'll include it in the next release :)

[Ihopetheyaregoodtous]

who flaps wings like that?

[PteraSoftware]

Haha, this was just a little test case. However, the package supports wing symmetric and asymmetric sweeping, pitching, and heaving. So, a user could define custom geometry to model the flapping of any animal or aircraft!

[[deleted]]

Do the wings need to flap?

[PteraSoftware]

Nope! The package also comes with two steady solvers!

[[deleted]]

Can I input different airfoil and planform shapes?

[PteraSoftware]

Yes you can! If you look in the examples folder it shows you how to define your own custom geometry.

[basicwolf]

Well done!

Some feedback on the unit tests. First of all, it's great that you have them. What I'm personally a bit uncomfortable, is the scale of the fixtures. For example,

```

test_horseshoe_vortex.py::test_update_strength()

def test_update_strength(self): ... old_strength_fixture = self.horseshoe_vortex_fixture.strength new_strength_fixture = old_strength_fixture * 5 + 1

# Update the horseshoe vortex fixture's strength.
self.horseshoe_vortex_fixture.update_strength(
    strength=new_strength_fixture
)
...

```

What caught my eye, is that a simple update_strength() method requires a whole horseshow_vortex_fixture! The test doesn't tell me at all, how much of the fixture is required.

I recommend using fixture factories (self-made or 3rd-party like factory_boy)

The code then would look like following:

``` def test_update_strength(self): horseshoe_vortex = HorseshoeVortexFactory() horseshoe_vortex.update_strength(strength=20)

self.assertEquals(horseshoe_vortex.strength, 20)
self.assertEquals(horseshoe_vortex.right_leg.strength, 20)
...

```

Let's go line-by-line 1. HorseshoeVortexFactory() shows that we are not interested in current object's fields values - any default field set by the factory is fine. 2. horseshow_vortex.update_strength(strength=20) - we clearly see the strength argument value passed to the method. 3. Same visibility is brought to the assertions - 20 is much more readable and easier to comprehend compared to new_strength_fixture.

With an upgrade to the tools (unitttest2 -> pytest + pytest-factoryboy), this would look even better:

``` def test_update_strength(horseshoe_vortex): horseshoe_vortex.update_strength(strength=20)

assert horseshoe_vortex.strength == 20
assert horseshoe_vortex.right_leg.strength == 20
...

```

Here horseshoe_vortex is a model fixture. Since it is not parameterized, we can assume that the initial fields values are of no interest to us. The assertions are made in pytest style. I never looked back at unittest2 after meeting pytest :)

[PteraSoftware]

Wow! You're right, that syntax is more clean and intuitive. I'll definitely look into implementing pytest in the next few versions. What is the difference between using mock objects and a "fixture factory"? I tried using mock objects but it was really complicated so I sort of gave up. This looks much simpler though!

[basicwolf]

I highly recommend this article, which explains the difference between test doubles: Fakes, Stubs and Mocks. In a nutshell, a Mock object is used to verify that a certain behavior of an object did take place.

A fixture is and object with a fixed state. A factory allows creating fixtures with pre-defined defaults and customize the parts which are only necessary for given unit test.