Updated nosetests and documentation

[dmwelch]

Documented nosetests running, updated test finding s.t. tests can be run from root of git clone directory.
Updated documentation to reflect 6S site only hosting incompatible versions for Py6S.

Currently, only test that fails is the custom path due to hardcoded executable path in the test on OS X 10.10 with gfortran 5.2.0.

[robintw]

Thanks for this. I'll look at it in more detail soon and then hopefully merge it.

I was aware that Py6S doesn't yet work with 6SV2.1 (it was only released recently, without any documentation as to what they have changed - so it takes quite a lot of work to support it), but I hadn't realised that the download for 6SV1.1 had been removed, or that Py6S doesn't work with the other version available for download (6SV1.0B). Unfortunately as there are no release notes or useful documentation showing the differences between these versions, it takes quite a while to work out what the differences are (I have to diff the Fortran code, and then experiment to see how the output changes with different inputs). Hopefully Py6S will soon support all versions of 6S.

[dmwelch]

I don’t know if you have the ear of the 6S authors, but it would be SUPER helpful if the sixs executable would support some basic POSIX flags, especially the ‘—version’ flag so we could identify the sixs version from the executable directly. Right now, unless the version is in the executable’s path, I have no clue how to identify the version…

From: Robin Wilson Reply-To: robintw/Py6S Date: Monday, September 28, 2015 at 5:07 PM To: robintw/Py6S Cc: David Welch Subject: Re: [Py6S] Updated nosetests and documentation (#20)

Thanks for this. I'll look at it in more detail soon and then hopefully merge it.

I was aware that Py6S doesn't yet work with 6SV2.1 (it was only released recently, without any documentation as to what they have changed - so it takes quite a lot of work to support it), but I hadn't realised that the download for 6SV1.1 had been removed, or that Py6S doesn't work with the other version available for download (6SV1.0B). Unfortunately as there are no release notes or useful documentation showing the differences between these versions, it takes quite a while to work out what the differences are (I have to diff the Fortran code, and then experiment to see how the output changes with different inputs). Hopefully Py6S will soon support all versions of 6S.

— Reply to this email directly or view it on GitHub.

[robintw]

Unfortunately I don't - I've tried to contact the 6S author (and his co-authors) multiple times with no success. Apparently he is well-known for not responding to emails. I've run into various other problems too (for example, the 6S code isn't actually released under any particular license - so no-one explicitly has any permission to do anything with it!) and haven't managed to get any answers to any questions. I know a number of other researchers in the field who've also tried, and failed, to get hold of him.

I agree, this will make it very difficult to support different versions of 6S, and I'm not sure what the best way forward is. I've had a brief look at v2.1 and the majority of the parameters and outputs seem to be the same, but with a few extra options - and these could probably be dealt with with some try...catch blocks. Not pretty, but possible.

The other problem is that v2.1 actually produces different answers to v1.1 because it has a more complex BRDF coupling implementation - and that would play absolute havoc with automated testing as we can't tell the version (unless we guess from the executable name...which is a bad plan!).

If you have any ideas about how best to deal with this then please let me know - or feel free to contact the 6S author yourself and see if you manage to get an answer!

[dmwelch]

This is the worse idea, but I can’t think of anything else: since there’s no license, we couldn't mirror it and add a license (violates their copyright), but we could provide patches to the 6S releases (make POSIX-compliant, add internal testing, etc.). And we’d have full control over the patch sets since it’s derived work (see http://programmers.stackexchange.com/a/148236). I’ll dig some more into this and see what I can find out.

From: Robin Wilson Reply-To: robintw/Py6S Date: Monday, September 28, 2015 at 5:21 PM To: robintw/Py6S Cc: David Welch Subject: Re: [Py6S] Updated nosetests and documentation (#20)

Unfortunately I don't - I've tried to contact the 6S author (and his co-authors) multiple times with no success. Apparently he is well-known for not responding to emails. I've run into various other problems too (for example, the 6S code isn't actually released under any particular license - so no-one explicitly has any permission to do anything with it!) and haven't managed to get any answers to any questions. I know a number of other researchers in the field who've also tried, and failed, to get hold of him.

I agree, this will make it very difficult to support different versions of 6S, and I'm not sure what the best way forward is. I've had a brief look at v2.1 and the majority of the parameters and outputs seem to be the same, but with a few extra options - and these could probably be dealt with with some try...catch blocks. Not pretty, but possible.

The other problem is that v2.1 actually produces different answers to v1.1 because it has a more complex BRDF coupling implementation - and that would play absolute havoc with automated testing as we can't tell the version (unless we guess from the executable name...which is a bad plan!).

If you have any ideas about how best to deal with this then please let me know - or feel free to contact the 6S author yourself and see if you manage to get an answer!

— Reply to this email directly or view it on GitHub.

[dmwelch]

bump ;-)