Running in parallel?

[CGenie]

Hello,

I couldn't find this in the documents: is it possible to run metplus in parallel? Some things, like ascii2nc could be parallelized easily I think.

I only found the OMP_NUM_THREADS setting, but am not quite sure how to set things up with OpenMP.

[JohnHalleyGotway]

Hi @CGenie, please take a look at this OMP_NUM_THREADS documentation. As of MET version 11.0.0, basically only one thing in MET is parallelized - the computation of fractional coverage fields used by the Grid-Stat, Ensemble-Stat, and Gen-Ens-Prod tools.

There certainly is lots and lots of potential to parallelize other portions of the code base. The development team does hope to pursue those types of enhancements in the context of all of our other deliverables. But as it stands, there's really only one example of it in the current version.

[heu3becteh]

Hello!

I do get that running in parallel is not implemented in MET (for most jobs), but with independent data, you can simply run several METplus processes at the same time. However, some problems arise with such a task.
For example, for PointStat it is not enough to make LOG_METPLUS unique for each task. In some way when LOG_DIR is the same for several tasks it can affect the results for part of them. For example, we had some cases when the MODEL variable was changed to the one from parallel task, I assume it is related to some temporal config-files. Because of this, you have to create many directories, this is not the most convenient behavior.
But it just works.

Best regards,
Alexander

[georgemccabe]

Hi Alexander,

The RUN_ID METplus config variable can be used to differentiate multiple runs that have the same timestamp because they were started at the same time. This can be used to make the log timestamp unique so the log files don't contain a mix of log output from multiple runs. See the glossary content for an example. As long as the parallel instances of METplus wrappers are not writing the same file paths, you should be able to use a common output directory to write all of the output.

The RUN_ID variable was added to help alleviate some of the issues you described with parallel runs. We have not performed extensive testing of running METplus in parallel, so we realize that there may be other issues that are not solved by using this variable. Please let us know if there are other issues you encounter so we can use this information to improve our software!

[heu3becteh]

Thank you for the tip!
RUN_ID variable could be useful! I use some settings of the specific job to make LOG_METPLUS/LOG_DIR unique for each core now, but it is possible that adding RUN_ID to LOG_TIMESTAMP_TEMPLATE will help with rare issues I have encountered.