Expand testing for UnsteadyRingVortexLatticeMethodSolver

[camUrban]

Problem Statement

UnsteadyRingVortexLatticeMethodSolver has no dedicated unit tests. Gaps in unit test coverage increase regression risk. The level of integration test coverage is also unclear.

Location(s): pterasoftware/unsteady_ring_vortex_lattice_method.py

Proposed Solution

Add targeted unit tests for internal helper functions or under tested code paths. Also assess the existing integration test coverage and add supplement if necessary.

Additional Context

This issue is referenced by TEST comments in the solver.

[IlyasFardaouix]

I think the issue is that the UnsteadyRingVortexLatticeMethodSolver class has internal helper functions that aren't covered by the existing tests. Have you considered testing the compute_vortex_lattice method, which seems to be a key part of the solver? FYI, looking at the code, it's called from the solve method, so it's worth checking that one out too.

[camUrban]

Hi @IlyasFardaouix, thanks for your comment! Would you mind explaining which compute_vortex_lattice you mean? I don't think there are any functions named that in the repository. Also, the only call to a solve method is numpy's linalg.solve function.

[IlyasFardaouix]

I think I see the confusion. It seems like we're discussing the wrong compute_vortex_lattice method. Upon reviewing the code again, I noticed that there's actually a method named compute_vortex_lattice inside the UnsteadyRingVortexLatticeMethodSolver class itself. I'd suggest we focus on testing that method first, as it's indeed a key part of the solver. What do you think about adding a test case to verify its correctness?

[camUrban]

Hi @IlyasFardaouix, I want to address your recent comments here and on #147 and #148 together.

I appreciate your interest in Ptera Software, but I've noticed a pattern across these threads that I want to be upfront about. Several of your suggestions reference things that don't exist in the codebase. For example, the compute_vortex_lattice method you've now referenced twice doesn't appear anywhere in the repository. Other comments suggest changes that are already implemented (like @njit on the Biot-Savart kernels in #140), or ask me to confirm what's in files that are publicly accessible in the repo.

I don't want to discourage anyone from engaging with the project, but responding to comments that don't reflect familiarity with the code takes time away from actual development. If you'd like to contribute, I'd ask that you read the relevant source files before commenting and reference specific lines or functions that actually exist. I'm happy to engage with suggestions grounded in the code.

Thanks for understanding!