Git Product home page Git Product logo

multithreadcorner / hydra Goto Github PK

View Code? Open in Web Editor NEW
107.0 24.0 21.0 136.57 MB

Header only framework for data analysis in massively parallel platforms.

License: GNU General Public License v3.0

CMake 2.32% C++ 96.95% C 0.61% Cuda 0.05% NASL 0.08%
hydra thrust high-energy-physics data-analysis parallel-data-analysis hpc-applications monte-carlo-simulation numerical-integration data-fitting parallel-computing

hydra's Introduction

DOI License: GPL v3 Documentation Status latest version


Table of Contents


What is it?

Hydra is a C++17/20 compliant and header only framework designed to perform common data analysis tasks on massively parallel platforms. Hydra provides a collection of containers and algorithms commonly used in HEP data analysis, which can deploy transparently OpenMP, CUDA and TBB enabled devices, allowing the user to re-use the same code across a large range of available multi-core CPU and accelerators. The framework design is focused on performance and precision.

The core algorithms follow as close as possible the implementations widely used in frameworks like ROOT and libraries like GSL.

Main features

Currently Hydra implementation includes:

  • Generation of phase-space Monte Carlo samples with any number of particles in the final states. Sequential decays, calculation of integrals of models over the corresponding phase-space and production of weighted and unweighted samples, which can be flat or distributed following a model provided by the user.
  • Sampling of multidimensional pdfs.
  • Multidimensional maximum likelihood fits using binned and unbinned data sets.
  • Multi-layered simultaneous fit of different models, over different datasets, deploying different parallelization strategies for each submodel.
  • Calculation of S-Plots, a popular technique for statistical unfolding of populations contributing to a sample.
  • Evaluation of multidimensional functions over heterogeneous data sets.
  • Numerical integration of multidimensional functions using self-adaptive Monte Carlo and quadrature methods.
  • Multidimensional sparse and dense histogramming of large samples.
  • Object-based interface to FFTW and CuFFT for performing Fast Fourier Transform in CPU and GPU.
  • Fitting models containing FFT based one-dimensional convolution components with arbitrary signal and kernel shapes.
  • Booststrap and real cubic spline (1D, 2D, 3D and 4D)for datasets on CPU and GPU.
  • Sobol low discrepance sequences up to 3667 dimensions.
  • Seven fast and reliable counter based pseudo-random number generators.

Hydra also provides a bunch of custom types, optimized containers and a number of algorithms and constructs to maximize performance, avoiding unnecessary usage of memory and without losing the flexibility and portability to compile and run the same code across different platforms and deployment scenarios.

For example, just changing .cu to .cpp in any source code written only using the Hydra and standard C++14 is enough to compile your application for OpenMP or TBB compatible devices using GCC or other compiler in a machine without a NVIDIA GPU installed.

In summary, by using Hydra the user can transparently implement and dispatch typical bottle-neck calculations to a suitable parallel device and get speed-up factors ranging from dozens to hundreds.

Hydra and Thrust

Hydra is implemented on top of the Thrust library and relies strongly on Thrust's containers, algorithms and backend management systems. However, since the official version of Thrust supports tuples with maximum ten elements, in order to overcome this limitation, Hydra uses an maintain an unofficial version, initially forked from the original by Andrew Currigan and collaborators. This version implements variadic tuples and related classes, as well as provides some additional functionality, which are missing in the official Thrust and is necessary for Hydra, but too specific to "pull request".
In order to keep Hydra uptodated with the latest bug-fixes and architetural improvements in Thrust, at each Hydra release, the official Thrust library is patched with the Currigan's variadic tuple implementation. This Thrust version is accessible in hydra::thrust namespace and does not conflicts in anyway with the users system Cuda Tookit installation or its deployment in applications also using Hydra. Same logics applies to Eigen and Boost.Math, which are also distributed with Hydra and are accessible in hydra::Eigen and hydra::boost::math namespaces.

Supported Parallel Backends

Hydra uses the underlying Thrust's "backend systems" to control how the algorithms get mapped to and executed on the parallel processors and accelerators available to a given application. When necessary, the backends can be specified using the symbols hydra::device::sys_t, hydra::host::sys_t, hydra::omp::sys_t, hydra::tbb::sys_t, hydra::cuda::sys_t, hydra::cpp::sys_t. The backends hydra::device::sys_t and hydra::host::sys_t are selected in compile time using the macros HYDRA_HOST_SYSTEM and HYDRA_DEVICE_SYSTEM. The following possibilities are available:

  • host: CPP, OMP, TBB
  • device: CPP, OMP, TBB, CUDA

For example, this will compile my_program.cu using OpenMP as host backend and CUDA as device backend using the NVidia's compiler nvcc:

nvcc  -I/path/to/Hydra -Xcompiler -fopenmp -DHYDRA_HOST_SYSTEM=OMP -DHYDRA_DEVICE_SYSTEM=CUDA  my_program.cu ...

The available "host" and "device" backends can be freely combined. Two important features related to Hydra's design and the backend configuration:

  • If CUDA backend is not used or available, NVCC and the CUDA runtime are not necessary. The programs can be compiled with GCC, Clang or other host compiler compatible with C++17 support directly.
  • Programs written using only Hydra, Thrust, STL and standard c++ constructs, it means programs without any raw CUDA code or calls to the CUDA runtime API, can be compiled with NVCC, to run on CUDA backends, or a suitable host compiler to run on OpenMP , TBB and CPP backends. Just change the source file extension from .cu to .cpp, or something else the host compiler understands.

The Latest Version

The latest release can be downloaded here.

Documentation

Reference manual

The complete and updated Doxygen source code documentation in HTML format is available at the Reference documentation web-page. It is also possible to browse the documentation by class, file or name using the links:

1.classes

2.files

3.names

User's guide

The Hydra User's Guide is available in the following formats:

Installation and requirements

Hydra is a header only library, so no build process is necessary to install it. Just place the hydra folder and its contents where your system can find it. The framework runs on Linux systems and requires at least a host compiler supporting C++14. To use NVidia's GPUs, CUDA 9.2 or higher is required.
A suite of examples demonstrating the basic features of the framework is included in the examples folder. All the examples are organized in .inl files, which implements the main() function. These files are included by .cpp and .cu files, which are compiled according with the availability of backends. TBB and CUDA backends requires the installation of the corresponding libraries and runtimes. These code samples uses, but does not requires ROOT for graphics, and TCLAP library for process command line arguments. Some functionality in Hydra requires Eigen, GSL, CuFFT and FFTW.

Examples

The examples are built using CMAKE with the following instructions:

  1. clone the git repository: git clone https://github.com/MultithreadCorner/Hydra.git
  2. go to the Hydra repository: cd Hydra
  3. create a build directory: mkdir build
  4. go to build directory: cd build
  5. cmake ..
  6. make or make <target> (possible targets are: examples_cpp, examples_tbb, examples_omp, examples_cuda, tests)

The compiled examples will be placed in the build/examples folder. The sub-directories are named according to the functionalities they illustrate.

The examples are listed below:

  1. async : async_mc
  2. fit : basic_fit, multidimensional_fit, extended_logLL_fit, fractional_logLL_fit, phsp_unweighting_functor_and_fit, splot
  3. histograming : dense_histogram, sparse_histogram
  4. misc : multiarray_container, multivector_container, variant_types
  5. numerical_integration : adaptive_gauss_kronrod, gauss_kronrod, plain_mc, vegas
  6. phase_space : phsp_averaging_functor, phsp_evaluating_functor, phsp_reweighting, phsp_basic, phsp_unweighting, phsp_chain, phsp_unweighting_functor
  7. phys : breit_wigner_plus_chebychev, breit_wigner_plus_polynomial, crystal_ball_plus_exponential, dalitz_plot, double_gaussian_plus_exponential, gaussian_plus_argus, ipatia_plus_argus, particle_mass, pseudo_experiment
  8. random : basic_distributions, sample_distribution
  9. root_macros : macros to run examples in ROOT

Each compiled example executable will have an postfix (ex.:_cpp, _cuda, _omp, _tbb) to indicate the deployed device backend.
All examples use CPP as host backend.

Recent publications citing Hydra and presentations at conferences and workshops

  1. A. A. Alves Junior, Hydra: a C++11 framework for data analysis in massively parallel platforms, Proceedings of the 18th International Workshop on Advanced Computing and Analysis Techniques in Physics Research, 21-25 August 2017 Seattle,USA,
  2. A. A. Alves Junior, Hydra: Accelerating Data Analysis in Massively Parallel Platforms - ACAT 2017, University of Washington, 21-25 August 2017, Seattle
  3. A. A. Alves Junior, Hydra: A Framework for Data Analysis in Massively Parallel Platforms - NVIDIA’s GPU Technology Conference, May 8-11, 2017 - Silicon Valley, USA
  4. A. A. Alves Junior, Hydra - HSF-HEP analysis ecosystem workshop, 22-24 May 2017 Amsterdam, Netherlands
  5. A. A. Alves Junior, MCBooster and Hydra: two libraries for high performance computing and data analysis in massively parallel platforms -Perspectives of GPU computing in Science September 2016, Rome, Italy
  6. D. Brundu, A. Contu, G. M. Cossu and A. Loi, Modeling of Solid State Detectors Using Advanced Multi-Threading: The TCoDe and TFBoost Simulation Packages - Front. Phys., 21 March 2022 Sec. Radiation Detectors and Imaging Volume 10 - 2022 | https://doi.org/10.3389/fphy.2022.804752*
  7. A. Loi, A. Contu and A. Lai, Timing optimisation and analysis in the design of 3D silicon sensors: the TCoDe simulator - JINST 16 P02011, https://doi.org/10.1088/1748-0221/16/02/P02011
  8. A. Loi, A. Contu, R. Mendicino, G. T. Forcolin, A. Lai, G. F. Betta, M. Boscardin, S. Vecchi, Timing optimization for 3D silicon sensors - Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment, Volume 958, 2020, 162491,https://doi.org/10.1016/j.nima.2019.162491
  9. R. Aaij et al. (LHCb Collaboration) Angular Analysis of D0→π+π−μ+μ− and D0→K+K−μ+μ− Decays and Search for CP Violation - Phys. Rev. Lett. 128, 221801
  10. D. Brundu1, A. Cardini, A. Contu, G.M. Cossu, G.-F. Dalla Betta, M. Garau, A. Lai, A. Lampis, A. Loi and M.M. Obertino,Accurate modelling of 3D-trench silicon sensor with enhanced timing performance and comparison with test beam measurements JINST 16 P09028, https://doi.org/10.1088/1748-0221/16/09/P09028

How to cite Hydra

[1]Alves Junior, A.A. - MultithreadCorner/Hydra, (2018). doi:10.5281/zenodo.1206261

bibtex:

@misc{hydra,
  
  author       = {Alves Junior, A A},
  title        = {MultithreadCorner/Hydra},
  month        = March,
  year         = 2018,
  doi          = {10.5281/zenodo.1206261},
  url          = {https://doi.org/10.5281/zenodo.1206261}
}

Licensing

Hydra is released under the GNU General Public License version 3. Please see the file called COPYING.

Contact the developers

Here’s what you should do if you need help or would like to contribute:

  1. If you need help or would like to ask a general question, subscribe and use https://groups.google.com/forum/#!forum/hydra-library-users.
  2. If you found a bug, use GitHub issues.
  3. If you have an idea, suggestion or whatever, use GitHub issues.
  4. If you want to contribute, submit a pull request https://github.com/MultithreadCorner/Hydra.

Author

Hydra was created and is maintained by Antonio Augusto Alves Jr.

Acknowledgement

Initial Hydra's development was supported by the National Science Foundation under the grant number PHY-1414736. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the developers and do not necessarily reflect the views of the National Science Foundation.

hydra's People

Contributors

aaalvesjr avatar dbrundu avatar deepanshu2017 avatar henryiii avatar marromlam avatar srstevenson avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hydra's Issues

Add method SetWeights to Decays class

The hydra::Decays class does not contain a method to set the weights indipendently from the four-vectors. Altought this can be already done event-by-event, creating a new decay instance and copying only the four vectors using custom weights, a SetWeights method would be useful, for example if we have a set of unweighted decays to reweight or to import the weights from a separate Sweights study.

fcn error when using hydra::JohnsonSUShape

Defining a hydra::JohnsonSUShape<> functor and using it in a make_loglikehood to perform a fit, like this:
fcn = hydra::make_loglikehood_fcn(model, dataset.begin(), dataset.end() );
the following error appears:

Hydra-dev/Hydra-master/hydra/detail/LogLikelihoodFCN2.inl:111:60: error: no matching function for call to ‘log(hydra::GReal_t)’
     ( this->GetPDF().GetCoefSum() - this->GetDataSize()*log(this->GetPDF().GetCoefSum() ) ) - final;

Bug in dot product in Vector3

There is a bug in the implementation of the scalar product in hydra/detail/Vector3R.inl
The product of the 0-th components is added 3 times

tgamma float or double

On a fresh checkout and build of Hydra on CentOS 7, CUDA 9.2 master or develop, I get the error:

/home/schreihf/git/fitting/Hydra/hydra/functions/detail/wigner_d_matrix.h(61): error: more than one instance of overloaded function "tgamma" matches the argument list:
            function "tgamma(double)"
            function "tgamma(float)"
            argument types are: (unsigned int)

1 error detected in the compilation of "/tmp/tmpxft_00005fc5_00000000-4_breit_wigner_plus_chebychev.cpp4.ii".

Manual, GenzMalikQuadrature example

When compiling the example giving in the manual for GenzMalikQuadrature the following error occurs:

no matching function for call to ‘hydra::GenzMalikQuadrature<5, hydra::detail::BackendPolicy<(hydra::detail::Backend)1> >::GenzMalikQuadrature(double [5], double [5], size_t [5])’
hydra::GenzMalikQuadrature<N, hydra::device::sys_t> GMQ(min, max, grid);

Using apply_filter for hydra::Decays

The hydra::apply_filter() has problems when applied to hydra::Decays containers. This seems related to type conversion and the interface of the lambda wrapper.
Please find attached a ROOT macro that emulates this issue (run it inside ROOT changing the file extension to .C or similiar).

apply_filter_issue.txt

restrict keyword

The * before the __restrict__ causes clang to report an error. GCC is happy with it before or after the __restrict__. Currently both cases are in Hydra. This issue requests a new symbol defined to take care of the different cases.

(Note: I believe the c++ restrict keyword might have a different syntax than __restrict__, does that version work?)

Fail of hydra::unweight( dataset , functor)

The following simple example, in which I'm calling the function hydra::unweight( dataset , functor), produces a compile time error:

    declarg(xvar,  double)
    declarg(yvar,  double)

    int main(int argv, char** argc)
    {
       hydra::multivector<hydra::tuple<xvar, yvar> , hydra::host::sys_t> dataset;

        for(size_t i=0; i<100; i++ ) dataset.push_back( hydra::tuple<xvar, yvar>(i, i) );
    
        auto functor  = hydra::wrap_lambda(
            [] __hydra_dual__ (xvar x, yvar y) { return  ::sqrt(x*y); } );
   
        auto dataset_unwgt = hydra::unweight( dataset, functor);

        return 0;
    }

The error remains if the multivector is instantiated in the device.

How does __CUDA_ARCH__ work?

Hello,

I am testing the dalitz_plot.cu example on an Nvidia Tesla T4 GPU, with gcc 7.5.0 and CUDA 10.0.130. The operation system is scientific linux release 6.9. The compiling finished normally, with some warnings (attached in the bottom). When running
dalitz_plot_cuda -n=1000, I got the following exception:

[Hydra::Exception]
 --> Message: Setting parameter from CUDA backend may not update the functor state completely .
 --> File: Hydra/hydra/detail/Parameters.h
 --> Function: void hydra::detail::Parameters<N>::SetParameter(Int, double) [with Int = int, <unnamed> = void, N = 2UL]
--> Line: 233

The status of the GPU was normal, according to nvidia-smi, and detect_cuda_archs.cu gave 7.5.

I have checked the line 233 in Hydra/hydra/detail/Parameters.h, and found there is a __CUDA_ARCH__ judgement. I tried to find something like #define __CUDA_ARCH__ in the project but failed.

I would like to ask, how does __CUDA_ARCH__ work? and how should I solve this exception?

Appendix: the warnings appear in compiling:

Hydra/hydra/detail/external/hydra_R123/array.h(320): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(321): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(326): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(327): warning: statement is unreachable

ROOT6/root_6.12.04/include/TVirtualQConnection.h(77): warning: statement is unreachable
          detected during:
            instantiation of "void TVirtualQConnection::SetArgs(const T &...) [with T=<>]" 
ROOT6/root_6.12.04/include/TQObject.h(126): here
            instantiation of "void TQObject::EmitVA(const char *, Int_t, const T &...) [with T=<>]" 
ROOT6/root_6.12.04/include/TQObject.h(174): here

Hydra/hydra/detail/external/hydra_thrust/detail/tuple/variadic_tuple.h(275): warning: calling a __host__ function("hydra_thrust::system::cpp::reference<double> ::operator =") from a __host__ __device__ function("hydra_thrust::__tuple_leaf<(unsigned long)0ul,  ::hydra_thrust::system::cpp::reference<double> > ::operator =<double &, void> ") is not allowed

Hydra/hydra/detail/external/hydra_thrust/detail/tuple/variadic_tuple.h(275): warning: calling a __host__ function("hydra_thrust::system::cpp::reference<double> ::operator =") from a __host__ __device__ function("hydra_thrust::__tuple_leaf<(unsigned long)1ul,  ::hydra_thrust::system::cpp::reference<double> > ::operator =<double &, void> ") is not allowed

Hydra/hydra/detail/external/hydra_thrust/detail/tuple/variadic_tuple.h(275): warning: calling a __host__ function("hydra_thrust::system::cpp::reference<double> ::operator =") from a __host__ __device__ function("hydra_thrust::__tuple_leaf<(unsigned long)2ul,  ::hydra_thrust::system::cpp::reference<double> > ::operator =<double &, void> ") is not allowed

Hydra/hydra/detail/external/hydra_thrust/detail/tuple/variadic_tuple.h(275): warning: calling a __host__ function("hydra_thrust::system::cpp::reference<double> ::operator =") from a __host__ __device__ function("hydra_thrust::__tuple_leaf<(unsigned long)3ul,  ::hydra_thrust::system::cpp::reference<double> > ::operator =<double &, void> ") is not allowed

Hydra/hydra/detail/external/hydra_thrust/detail/tuple/variadic_tuple.h(275): warning: calling a __host__ function("hydra_thrust::system::cpp::reference<double> ::operator =") from a __host__ __device__ function("hydra_thrust::__tuple_leaf<(unsigned long)4ul,  ::hydra_thrust::system::cpp::reference<double> > ::operator =<double &, void> ") is not allowed

Hydra/hydra/detail/external/hydra_thrust/mr/allocator.h(109): warning: calling a __host__ function("hydra_thrust::mr::stateless_resource_allocator<double,  ::hydra_thrust::mr::fancy_pointer_resource< ::hydra_thrust::mr::new_delete_resource,  ::hydra_thrust::system::cpp::pointer<void> > > ::stateless_resource_allocator") from a __host__ __device__ function("hydra_thrust::mr::stateless_resource_allocator<double,  ::hydra_thrust::mr::fancy_pointer_resource< ::hydra_thrust::mr::new_delete_resource,  ::hydra_thrust::system::cpp::pointer<void> > > ::stateless_resource_allocator [subobject]") is not allowed

TCLAP/tclap/include/tclap/UnlabeledValueArg.h(339): warning: type qualifier is meaningless on cast type

TCLAP/tclap/include/tclap/UnlabeledMultiArg.h(299): warning: type qualifier is meaningless on cast type

Hydra/hydra/detail/external/hydra_R123/array.h(320): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(321): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(326): warning: statement is unreachable

Hydra/hydra/detail/external/hydra_R123/array.h(327): warning: statement is unreachable

hydra::Sum not recognized as hydra functor

See error below

In file included from /Users/dicanto/cernbox/Dafne/src/test.cpp:1:
In file included from /Users/dicanto/cernbox/Dafne/include/test.inl:22:
/Users/dicanto/cernbox/Dafne/include/physics/Rate.h:88:9: error: no matching function for call to 'compose'
return hydra::compose(TimeDependentRate< typename ADIR::return_type, typename ABAR::return_type,hydra::complex,hydra::complex>(), Adir, Abar, gp, gm);
^~~~~~~~~~~~~~
/Users/dicanto/cernbox/Dafne/include/test.inl:93:15: note: in instantiation of function template specialization 'dafne::time_dependent_rate<hydra::arguments::DecayTime,
hydra::Sum<dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2, dafne::GounarisSakuraiPropagator<dafne::Resonance<hydra::PWave, 2, 3, true, false, 1,
void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>,
dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2, dafne::BreitWignerPropagator<dafne::Resonance<hydra::PWave, 1, 2, false, false, 3, void ()>, 2,
hydra_thrust::complex (double)>, hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus,
hydra::arguments::MSqMinus, 8, dafne::GLassPropagator<dafne::Resonance<hydra::SWave, 1, 3, true, false, 2, void ()>, 8, hydra_thrust::complex (double)>,
hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, hydra::Lambda<(lambda at
/Users/dicanto/cernbox/Dafne/include/physics/Amplitudes.h:44:29), 2> >, hydra::Sum<dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2,
dafne::GounarisSakuraiPropagator<dafne::Resonance<hydra::PWave, 3, 2, true, false, 1, void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2,
dafne::BreitWignerPropagator<dafne::Resonance<hydra::PWave, 1, 3, false, false, 2, void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 8,
dafne::GLassPropagator<dafne::Resonance<hydra::SWave, 1, 2, true, false, 3, void ()>, 8, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, hydra::Lambda<(lambda at /Users/dicanto/cernbox/Dafne/include/physics/Amplitudes.h:44:29), 2> > >' requested here
auto model = time_dependent_rate(tau,x,y,Adir,Abar);
^
/Users/dicanto/MySoftware/Hydra-3/Hydra/hydra/detail/Compose.h:108:1: note: candidate template ignored: requirement 'detail::all_true<false, true, true>::value' was not satisfied
[with T0 = dafne::TimeDependentRate<hydra_thrust::complex, hydra_thrust::complex, hydra_thrust::complex, hydra_thrust::complex >, T1 =
hydra::Sum<dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2, dafne::GounarisSakuraiPropagator<dafne::Resonance<hydra::PWave, 2, 3, true, false, 1,
void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>,
dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2, dafne::BreitWignerPropagator<dafne::Resonance<hydra::PWave, 1, 2, false, false, 3, void ()>, 2,
hydra_thrust::complex (double)>, hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus,
hydra::arguments::MSqMinus, 8, dafne::GLassPropagator<dafne::Resonance<hydra::SWave, 1, 3, true, false, 2, void ()>, 8, hydra_thrust::complex (double)>,
hydra_thrust::complex (hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, hydra::Lambda<(lambda at
/Users/dicanto/cernbox/Dafne/include/physics/Amplitudes.h:44:29), 2> >, Ts = <hydra::Sum<dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2,
dafne::GounarisSakuraiPropagator<dafne::Resonance<hydra::PWave, 3, 2, true, false, 1, void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 2,
dafne::BreitWignerPropagator<dafne::Resonance<hydra::PWave, 1, 3, false, false, 2, void ()>, 2, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, dafne::Amplitude<hydra::arguments::MSqPlus, hydra::arguments::MSqMinus, 8,
dafne::GLassPropagator<dafne::Resonance<hydra::SWave, 1, 2, true, false, 3, void ()>, 8, hydra_thrust::complex (double)>, hydra_thrust::complex
(hydra::arguments::MSqPlus, hydra::arguments::MSqMinus)>, hydra::Lambda<(lambda at /Users/dicanto/cernbox/Dafne/include/physics/Amplitudes.h:44:29), 2> >,
dafne::MixingG<false, hydra::arguments::DecayTime, hydra_thrust::complex (hydra::arguments::DecayTime)>, dafne::MixingG<true, hydra::arguments::DecayTime,
hydra_thrust::complex (hydra::arguments::DecayTime)>>]
compose(T0 const& F0, T1 const& F1, Ts const&...Fs){
^
1 error generated.
make[2]: *** [CMakeFiles/test_cpp.dir/src/test.cpp.o] Error 1
make[1]: *** [CMakeFiles/test_cpp.dir/all] Error 2
make: *** [all] Error 2

Capitalization in hydra dev

Some of the files that used to work in Hydra 1 are broken in Hydra dev fork because they are referred to (for example, in hydra/Events.h) with differing capitalization (#include <hydra/detail/config.h>, but the file is Config.h.

Personally recommend identical caps for all files, either TitleCase or lowercase. Thrust uses lowercase.

Missing include

There is a missing include in hydra/experimental/detail/Events.inl:

#include <thrust/count.h>

For some reason, this only breaks the CPP backend (GCC on Goofy tested). Not sure why the other backends include count some way, but not cpp.

Unguarded OMP includes

There are ~5 files with unguarded

#include <omp.h>

They should be guarded or deleted (apparently the latter since they are unused).

Adapt FindTBB.cmake also to oneAPI distributed TBB

FindTBB.cmake identifies the tbb version with include/tbb/tbb_stddef.h.
In the new oneAPI distributed TBB, the version information is in include/oneapi/tbb/version.h.
This issue adapts FindTBB.cmake also to new oneAPI distribution.

Inline missing

Hyrda has inherited an issue from MCBooster; at least one non-templated function (operator<< for hydra::Parameter) is not marked inline. If you try to use Hydra in two different files and link them, the operator<< kills the linking with multiple definition errors.

hydra::PrintLevel also.

hydra::fill_random fails to compile with declared arguments

The following code doesn't compile because "The container is not iterable, or it is not convertible from/to the functor return value". Changing X with double in the container definition fixes the compilation, which hints to an issue with the conversion/understanding of the declared argument.

declarg(X, double)
using namespace hydra::arguments;
...
hydra::device::vector<X> data(n);
hydra::fill_random(data, hydra::UniformShape<X>(0.,1.) );
...

Using namespace std in header

Please remove the

using namespace std;

from the headers of Hydra (only one slipped in, probably from MCBooster, in hydra/detail/functors/DecayMother.h, in both official version and fork).

Hydra on Nvidia A100

Cannot compile examples due to unsupported GPU architecture. The A100 should be number 80

Bootstrapping out of range

The following line in detail/BooststrappedRange.inl causes an out-of-range read of the iterable, if the extracted index is exactly equal to iterable.size(). This can lead to run time errors or undefined behaviors, depending on the use of the garbage read.

auto permutations = random_uniform_range(size_t(0), std::forward<Iterable>(iterable).size(), seed );

Should be replaced with:
std::forward<Iterable>(iterable).size() - 1
Already tested and the errors disappear.

Eigen copy does not support CUDA 9

The copy of Eigen that's baked into AAAlvesJr/Hydra does not work with CUDA 9. It uses the now removed __CUDACC_VER__. The fix has been applied to both master and 3.3 branches of Eigen.

Missing count.h in dev version

The development version is missing an include:

/Users/henryiii/git/fitting/goofit_hydra/extern/Hydra/hydra/detail/Events.inl:400:11: error: no member
      named 'count' in namespace 'thrust'; did you mean simply 'count'?
                count = thrust::count(fFlags.begin(), fFlags.end(),

Adding #include <thrust/count.h> fixes the problem.

Mismatch for LogLikelihood

Line 132 of LogLikelihoodFCN tries to call detail::LogLikelihood with 8 arguments, but it really only takes 7. The second argument seems to be the culprit.

Hydra does not compile with CUDA 10.1

Hi,

Trying to compile a fresh clone of Hydra, it turns out that it fails to compile while using CUDA 10.1 due to the deprecated CUDA SDK function cudaConfigureCall, which was depricated since CUDA 7.0.

The following compiler error is obtained:
triple_chevron_launcher.hpp(180): error: identifier "cudaConfigureCall" is undefined.

I'm using Linux Fedora 29 with gcc 8.3.1.

Is there a plan to migrate the code to the latest CUDA release?

Thanks,
Ron.

Step behaviour in hydra spline

Using the hydra spline to interpolate a simple set of data points (x_i, y_i) shows a drastic step behviour just after the data points themselves.
At the exact values x_i the spline is evaluated correctly to y_i.
In the plot attached the data points are shown in blue, and the spline in green. In this case the spline is evaluated on the high granularity x scale.

image

Run time error when using convolution

The example convolute_functions generates a run time error, after the last commit of Convolution.h
Running convolute_functions_tbb -n=10000
triggers the following error:

fft_functor_range :16385
fft_kernel_range  :16385
complex_buffer :16385
convolute_functions_tbb: /home/dbrundu/Scrivania/HYDRA_prova/Hydra-temp/Hydra3master/hydra/detail/fftw/BaseFFTW.h:253: void hydra::BaseFFTW<InputType, OutputType, PlannerType>::LoadInput(int, const InputType*) [with InputType = hydra_thrust::complex<double>; OutputType = double; PlannerType = hydra::detail::fftw::_Planner]: Assertion `size <= fNInput' failed.

It seems the correct result can be obtained leaving auto fft_product = _ComplexToRealFFT( 2*nsamples ).

Issues with ROOT missing

Hydra can't quite build if ROOT is missing. So far, unprotected includes in basic_fit and splot are causing errors. These examples could be ignored if ROOT is not found, or protection could be added around the ROOT parts.

  • basic_fit
  • splot

Fixes are needed in both Develop and 2.0rc branches (cherry-pick fixes).

In file included from /Users/henryiii/git/fitting/Hydra/hydra/FCN.h:41:0,
                 from /Users/henryiii/git/fitting/Hydra/hydra/LogLikelihoodFCN.h:32,
                 from /Users/henryiii/git/fitting/Hydra/examples/fit/basic_fit.inl:46,
                 from /Users/henryiii/git/fitting/Hydra/examples/fit/basic_fit.cpp:31:
/Users/henryiii/git/fitting/Hydra/hydra/UserParameters.h:43:10: fatal error: Minuit2/MnUserParameterState.h: No such file or directory
 #include "Minuit2/MnUserParameterState.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [examples/fit/CMakeFiles/basic_fit_tbb.dir/basic_fit.cpp.o] Error 1
make[1]: *** [examples/fit/CMakeFiles/basic_fit_tbb.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
In file included from /Users/henryiii/git/fitting/Hydra/hydra/FCN.h:41:0,
                 from /Users/henryiii/git/fitting/Hydra/hydra/LogLikelihoodFCN.h:32,
                 from /Users/henryiii/git/fitting/Hydra/examples/fit/splot.inl:48,
                 from /Users/henryiii/git/fitting/Hydra/examples/fit/splot.cpp:30:
/Users/henryiii/git/fitting/Hydra/hydra/UserParameters.h:43:10: fatal error: Minuit2/MnUserParameterState.h: No such file or directory
 #include "Minuit2/MnUserParameterState.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [examples/fit/CMakeFiles/splot_omp.dir/splot.cpp.o] Error 1
make[1]: *** [examples/fit/CMakeFiles/splot_omp.dir/all] Error 2

Runtime error in Eigen triggered by Splot constructor

The following line in Splot.h

fCovMatrix << 0.0, 0.0, 0.0, 0.0;

triggers a runtime error in Eigen, if npdfs=3:

eigen3/Eigen/src/Core/CommaInitializer.h:120: XprType& Eigen::CommaInitializer<MatrixType>::finished() [with XprType = Eigen::Matrix<double, 3, 3>]: Assertion `((m_row+m_currentBlockRows) == m_xpr.rows() || m_xpr.cols() == 0) && m_col == m_xpr.cols() && "Too few coefficients passed to comma initializer (operator<<)"' failed.

This can be easily reproduced with Eigen only:

#include <Eigen/Dense>
int main(){
    Eigen::Matrix<double, 3, 3> matrix;
    matrix << 0.0, 0.0, 0.0, 0.0;
    return 0;
}

Bug in DenseHistogram.h

In assignment operator in DenseHistogram.h are mismatching types (multidimensional and unidimensional)

CUDAless build

I haven't been able to build without CUDA. I've made a few fixes, which I'll PR shortly, but I still have the following issues (not included in the PR):

Two includes are not available without CUDA:

#include <thrust/system/cuda/execution_policy.h>
#include <math_constants.h>

I don't know if they are used, I seem to be able to comment them out.

C++14 seems to be needed on my Mac, with GCC 6.

After these changes, I now get a similar giant template error on both with and without CUDA version, Mac and SL6.

Eigen need update

Current version produces the following warning when compiled using cuda 10:
/usr/local/cuda/include/host_defines.h:54:2: warning: #warning "host_defines.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead." [-Wcpp]
#warning "host_defines.h is an internal header file and must not be used directly. This file will be removed in a future CUDA release. Please use cuda_runtime_api.h or cuda_runtime.h instead."

New/Improved facility for drawing of random numbers from distributions

For some distributions it is possible to draw random numbers analytically, from uniform random samples lying in the (0, 1) interval. In general it is always possible if the cumulative of the distribution is invertible ...

Hydra should provide a generic and simple and way to access, implement and deploys such cases transparently, independently of the back-end used in the calculation. The design constraints that cross my mind are:

  1. The presence, or not, of such method ( lets call it analytical pseudo-random number generation - APRNG) should be bound to the functor type and made available in compile time.
  2. The parameters used for APRNG should be acquired from an existing instance of of the functor of interest. It means that the only relevant state involved is the one of the functor self.
  3. The facility should be deployable parallel calculations and callable from infra-thread environment.
  4. The facility should be decoupled from the underlying PRNG engine.
  5. The whole thing should be scalable in terms of implementation and easy to extend by users
    that have their custom functors and know how to get pseudo-random numbers out of it.

Implementation/design hints and concepts involved in each point; as far as I could figure out :

  1. Template specialization. The only two relevant types here are EngineType and FunctorType
  2. No default construction. The functor should not be aware it is being sampled. It is also desirable but not crucial that the sampler facility should not store the functor. It has to be light weight enough to be instantiated in-place, and burned up when not more needed.
  3. Needs to provide a efficient and cheap discard method (jump ahead) and needs to have an interface to set a seed. Global seed + thread level discard, to be clear.
  4. Should be not engine specific, which implies compatibility with the current pseudo-random and quasi-random engines in Hydra, and future algorithms that will be made available over the time.
    So no strong assumptions on the functor anatomy at top-level.
  5. Interface to inform the framework of the presence of the method. Template specialization.

Some people in the cloud I know will be enthusiastic: @acontu , @dbrundu , @Angeloloi19, @fdordei, @JuanBSLeite , @danielsibemol

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.