run_02_minopy times out if I process 7 years of data. Are we taking the number of acquisitions into account for wall time calculation?
run_02_minopy times out and we get emails for re-running. Shall we resubmit without lengthening the walltime? The danger is that if time for just one patch is too long it never will finish, right? We also could suppress sending emails for this step.
-make recommendation on how to check from progress of run_02 step (when it is running you are concerned that it just runs and will never finish....)
minopy.interferograms.referenceDate : option for snowfree (last image in August/February for northern/southern Hemisphere). Or something with max coherence
For wall time calculation take number of dates into account for appropriate steps
I used to get lots of timeouts for areas including water. We need an option to mask out water (e.g. preprocessing option to generate water mask). In addition, can't we have an option in the template file to lengthen wall times for known problem cases? e.g. minsar.walltime_factor or minsar.walltime_factor.minopy_unwrap_ifgram=1.2. `create_runfiles.py would run at the end a fumction to adjust the walltimes.
A user always wants to analyze an area as big as possible. We should give some advice on how big is reasonable given the available computer resources.
### Low Priority:
- for `--tmp` and no option given write jobfiles into `run_files_tmp` (that makes it consistent with minsar)
- rename --numBursts to something else
log
file. I used to have:minsar.walltime_factor
orminsar.walltime_factor.minopy_unwrap_ifgram=1.2
. `create_runfiles.py would run at the end a fumction to adjust the walltimes.