August 20, 2012 at 4:53 am #1399
is there any way to run EddyPro automated on a daily basis using batch files or similar?
BMAugust 21, 2012 at 9:55 pm #1622
Yes, there is a way to run EddyPro in batch mode. The quick way would be to create a project with the EddyPro (GUI) program and with all the processing choices that you want. Save the project with the file name processing.eddypro. Save also the metadata. You may want to run the project with a couple of files just to make sure it process the way you expect it.
Then copy two folders titled bin and ini from the installation folder (C:Program FilesLI-COREddyPro) to your desktop or a place to your liking put the project you created from before in the ini folder. You can navigate to the bin folder in command prompt and run eddypro_rp.exe. This will run the raw processing engine.
Just remember that some of the advanced features such as in situ spectral assessment will not run in batch mode.
Let us know how it goes.September 9, 2012 at 11:41 pm #1640
Great, that works well! I am trying to automate the processing on a daily basis. I might come back to you again.February 5, 2014 at 1:38 am #1942
Dear EddyPro developers,
I tested whether this batch approach could be extended by also calling “eddypro-fcc” in the batch file, after executing “eddypro-rp”, and that way be able to obtain final outputs with any preferred spectral corrections on a routine basis.
My impression was that this almost worked, were there not the following problem (bug?):
As eddypro-rp finishes, it does not seem to update the processing.eddypro file, with the consequence that the output file name (“ex_file= …”) and the paths containing spectra (“sa_bin_spectra=…” and “sa_full_spectra= …”) are still those from a previous execution. Thus, when eddypro-fcc starts, it either wrongly reprocesses old data, or if the older files have been removed, it crashes.
I tested this with Versions 4.2.1 and 5.0.0, with identical results.
Using EddyPro in normal mode (with GUI, Advanced Processing) on the same sets of raw data worked trouble-free, and the processing.eddypro file was up-to-date at the end.
Would you be able to look into this please?
Cheers, Johannes.February 5, 2014 at 2:16 am #1943
Hello Johannes and all,
you’re completely right Johannes. And that’s by design.
We did not design EddyPro to be operated in batch mode, although it can be adapted to do so. Quite simply, it is the responsibility of the GUI of EddyPro to update the project file, before running the second executable, “eddypro_fcc.exe”.
In order to perform a complete “rp + fcc” run, you’ll thus have to:
– run eddypro_rp.exe and wait for its completion
– update the project file with relevant paths as you describe
– run eddypro_fcc.exe
As you can see, this process can be easily automated.
GerardoFebruary 6, 2014 at 9:27 pm #1944
Thank you Gerardo. Just wondering:
1) Are output file name and spectral paths the ONLY parameters that need to be updated before eddypro-fcc is called?
2) The GUI must call an already-existing piece of code to do these updates, is it not possible to either make this piece of code available separately, or to include it in the code for eddypro-rp? (Seems in theory a rather small step to give the user added functionality – too hard in practice?)
Johannes.February 7, 2014 at 7:11 am #1945
1) Yes, those 3 fields are the only parameters
2) The GUI, written in C++, controls (i.e. creates, writes, modifies, saves, deletes..) that file completely, so it’s not about a “separate” piece of code, it just.. does it, in a few instructions.
Of course, the same operation (editing the file) can be performed in multiple ways, and could also be done within the “eddypro_rp.exe” file. It’s just not done. The reason dates back to the initial phase of the software project, when the edits to that file were more numerous and more complicated. So, at that time it made sense to do that within the GUI and so the eddypro_rp.exe file was never added of a capability to modify the configuration file.
I totally see your point though, and we may well change this in the (near) future.
You must be logged in to reply to this topic.