OpenMP about cobaya HOT 7 CLOSED

Yes - I know Although the user could send a flag that shows if he wants Cobaya to use openmp or not - then Cobaya collects all likelihood that are flagged and run them in parallel. Of course this is wishful thinking in dreamland. And yes it does. My specific setting is Cosmolike - it takes ~0.8 seconds to evaluate everything (PS: I don’t understand why the computation of \chi+- and gamma_t are in the likelihood and not into the theory classes that would allow them to be cached - if you split the IA integrals from example - even changing IA would be fast (maybe semi-fast like inflation) - then all multiplicative biases and IA could be considered “fast” - in cosmolike we create a separate cache to try to implement this strategy). Best Vivian On Nov 12, 2018, at 7:13 AM, Jesús Torrado <[email protected]<mailto:[email protected]>> wrote: Hi Vivian, Though it sounds very useful, but I am afraid it would be a nightmare for us the developers: as you said there are non-thread-safe codes, so we would need to know in advance which one is or isn't (and that would conflict with letting the user use an arbitrary unknown-to-us python function as a likelihood). Our approach is to compute each likelihood sequentially, and rely on the likelihood authors to take advantage of OpenMP palletisation themselves in the internal of the likelihood computation. If done right, this should result in a similar performance to computing the likelihoods in parallel on different threads. Does this answer your question? Is there a specific setting that you are finding yourself into (e.g. having to evaluate tens of different likelihoods), so that we may be able to find an alternative way to speed it up? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#3 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADD96AF9KYlFuBV_Xtz8RtjHufxuZaGXks5uuYHsgaJpZM4YYO5q>.

He Prof Lewis, That seems a good opportunity for collaboration, no? CosmoLike is not that fast (~0.8 s non thread) but very general - yours are quite fast and non-general. If we can make both that could have a big impact. best Vivian

Yes - Like a derived class - the parent would be either CAMB/CLASS. That sounds amazing! Best Vivian On Nov 13, 2018, at 12:22 AM, Jesús Torrado <[email protected]<mailto:[email protected]>> wrote: Hi both, If e.g the P(k)-->gamma_t/w_theta/xi can be generalised and abstracted, we'd still need to implement some way to pipe more than one theory code (camb+that), which is in the pipeline anyway for 2.0. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#3 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADD96NHyNA84LadzBfiPIf8kaU3fmY4hks5uunM6gaJpZM4YYO5q>.