Issue interfacing with Matlab -- Disabling Parallelzation (--disable-omp) or passing vectors.

Issue #29 invalid
Former user created an issue

Hi! I'm currently trying to run matlab functions via C++ as part of a user function. The reason being, is that the function I want to use cannot be easily exported into C/C++. but can be easily run by the matlab kernel. Also, I do like the consistency in not fitting to multiple implementations of the same function.

The issue is that it's extremely slow, to the point of being blatantly unusable. Every time musrfit calls the fit function, the system has to spin up a matlab process, which is slow -- takes about 1 second each time AND consumes quite a bit of system memory.

The simplest thing to do would be to pass an array of values to be evaluated to matlab in the same way that built-in functions are evaluated -- as opposed to an individual function call for each point. But that does not appear to be possible with user functions.

The second solution would be to use a persistent matlab session that the user function can connect to. This is easy enough....except...minuit sends parallelized function calls to the fit function in an uncontrolled fashion, which quickly overwhelms any attempts to use a persistent matlab process.

One thing I've tried is to disable multi-threading as, while slower, would give more controlled function calls to matlab. But, I can't figure out how; the manual mentions that I can pass "-disable-omp" at the configuration level to disable omp support, but I can't figure out exactly where to do this. I can't do it in the cmake commands used to build musrfit, and it doesn't appear to fit into the xml configuration files either. I think if I could disable omp support though I could make this work, albeit in a hacky fashion.

Notes: Platform Ubuntu (WSL). Listed as bug, as the way musrfit calls user-fit functions causes massive issues with certain types of advanced functions and leads to bugs if *"operator() is expected to evaluate to reasonable values for a fixed set of parameters (but changing t) beginning with the second function call." At the same time, instruction on how to disable omp are vague and do not seem to work?

Comments (1)

  1. Andreas Suter

    Without clear stated input this "issue" is not understandable. It also looks as if the concept of the user function is not understood (here I can give a hand and try to help) since we have VERY complicated user functions running without any issues. The multi-threading interface is sound and robust.

  2. Log in to comment