Change accuracy of pvsyst_cell test function

[IoannisSifnaios]

I noticed that for the test_pvsyst_cell_ndarray, the tolerance for the test is 3, which I think is too high. Thus, I changed it to the default value.

[IoannisSifnaios]

@kandersolar, all the tests for sapm (module and cell) have a tolerance of 3. Is this correct? Or am I misunderstanding something?

[kandersolar]

I think you are correct that these tests are in error. Looking back through history, I think this was an oversight from when we switched from the nose test framework to pytest in #204. From what I can tell, nose interprets the third parameter as the number of decimal places to check, so 3 would mean "to three decimal places", whereas pytest interprets it as the precision, so 1e-3 means "to three decimal places". It looks like #204 just copied the 3 over for those tests: https://github.com/pvlib/pvlib-python/pull/204/files#diff-c00d7870b1b61cebdc08ab0e105fff10539647591a48cccd553606cd56376055R338-R339

I suspect we may have similar issues in other test modules. Here are two ideas to identify any, if they exist:

• Look through the changes in use pytest instead of nose for automated tests #204 to see if any other tests may have the same problem.
• Perhaps @echedey-ls can come up with a git grep regex to look for cases of assert_almost_equal(..., ..., x) where x is an integer?

[echedey-ls]

@kandersolar assert_almost_equal's third parameter is the decimal which gets compared.
I suppose you were talking about assert_allclose. Fixes to the diff findings and a few more were made at #2082

FFR, regex is (assert_allclose)\((.*), ?(.*), ?([a-zA-Z0-9=]*)?(\d)\)

[kandersolar]

Thanks and good catch @IoannisSifnaios!