Adapted for macOS and parallel processing

[mcuntz]

Dear Gerardo,

I have been running EddyPro on macOS. There were two small inconveniences in order to get it to run:

1. I had to create the base tmpdir (trim(homedir) // 'tmp') manually, and
2. I had to install p7zip and link 7za manually into the current working directory.

For the first issue, I added the -p flag to mkdir in the OS environment so that trim(homedir) // 'tmp' gets created in desktop mode as well (not only trim(homedir) // 'tmp' // slash // 'tmp' // trim(adjustl(tmpDirPadding))). The little inconvenience of this very easy fix is that trim(homedir) // 'tmp' is not cleaned up.

For the second issue, I changed the code so that the utility unzip coming with macOS is used instead of 7za. unzip might probably also be the preferable solution on Linux.

I also tried to run EddyPro in parallel using the GNU utility parallel. This failed because tmpdir used the timestamp only and the separate instances interfered with each other. I added a 5-digit random number to the tmpdir name to make them even more unique.

Kind regards,
Matthias

[geryatejina]

Hi again Matthias,
thanks a lot for the PR, this may well be the first one ever :)
From a quick look at it, these are all sound improvements. As you probably noted, we don't use this repo as a development repo, it is only intended to share the code of the released versions. The development repo is private to LI-COR. I will add the commits to that repo. I cannot guarantee that the changes will make it into the next release, because we are now in a "code frozen", testing phase for the next (minor) release. However, they will be considered and tested for sure for the next one.
Thanks again!
Gerardo

[mcuntz]

Dear Gerardo,

yes, I realised that this is not a development branch. But I do not know how to contribute in another way.
I would have thought that you had commits or pull requests from the Ameriflux people who also run EddyPro on Linux from the command line.

If I want to commit something else, I will try to keep the commit small (such as this time) so that you can transfer it by hand if accepted.

Kind regards,
Matthias

[geryatejina]

Yes, that's the best approach, keep the commits small so that I can port them to the dev repo manually. Thanks a lot Matthias!

[mcuntz]

Dear Gerardo @geryatejina ,

we are planning to reprocess our 25 years of Eddy data with EddyPro. So we need a bit of flexibility. I started to familiarise myself a bit more with the code and changed very little things for a start but which might come handy also to other people.

The first commit was just to add the option 'tlag_opt' in the subroutine TimelagHandle. The way that it was done was a bit twisted by setting the method to 'maxcov&default' before TimelagHandle and then back to 'tlag_opt' afterwards again. In this commit, I also cleaned a bit the comparisons with strings in the eddypro_rp_main.f90.

The second commit adds the possibility to stop calculations after timelag optimisation and after planar fit. I use the to_mode and pf_mode variables. If one of them is set to 2 then eddypro_rp will stop after this step. Is it advised to use no more than 2 months for calculating planar fits. So we will first calculate the fits for two months and then read it from the file for say the whole summer. So I do not want to do the whole chain for the two months where I only want the planar fit file.
These options are undocumented. I did not know how to do it.

Kind regards,
Matthias

[mcuntz]

Dear Gerardo @geryatejina ,

I thought making an extra comment for easier tracking.

I was wondering if you think that this is a a good way to move forward: I keep on submitting small commits to this PR. It might turn out that some of the commits might not be so small.

I also do not know what your policy is. Are you actually interested in user contributions? If so then a read only master branch would probably be a good idea so that users can rebase the branch before PRs and merge effort is then minimal for you.

Best,
Matthias