vukics / cppqed Goto Github PK

View Code? Open in Web Editor NEW

8.0 1.0 1.0 11.87 MB

C++QED: a framework for simulating open quantum dynamics

License: Boost Software License 1.0

CMake 6.54% C++ 76.74% TeX 6.25% Makefile 3.40% Python 6.43% Shell 0.25% C 0.40%

science quantum-optics monte-carlo-simulations simulation-framework scientific-computations

cppqed's People

Contributors

Stargazers

Watchers

Forkers

bartoszek

cppqed's Issues

std::forward for forwarding argument packs by rvalue reference

gcc:10.2.0 build fails "explicit template specialization cannot have a storage class"

Build fine with clang:11.0.1 but against gcc:10.2.0 build fails complaining about template specialization in Random.h
build_env:{os:Linux,distro:Arch,gcc:10.2.0,clang:11.0.1,boost:1.75.0,python:3.9.1,eigen:3.3.9,gsl:2.6:cmake:3.19.3,ninja:1.10.0}

Can this be overridden depending on compiler ?

`relevent lines:`

cppqed/CPPQEDutils/Random.h

Lines 104 to 113 in 34290ae

 static const std::string EngineID_v<GSL_Engine> = "GSL_Taus2"; 

 template<> 

 static const std::string EngineID_v<std::mt19937_64> = "STD_MT19937_64"; 

 template<> 

 static const std::string EngineID_v<pcg64> = "PCG64"; 

 template<> 

 static const std::string EngineID_v<XoshiroCpp::Xoshiro256PlusPlus> = "Xoshiro256pp";

`gcc error:`

FAILED: CPPQEDutils/CMakeFiles/CPPQEDutils.dir/Random.cc.o
/usr/lib/colorgcc/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_SERIALIZATION_DYN_LINK -DBZ_HAVE_BOOST_SERIALIZATION -DCPPQED_HAS_GSL -DCPPQEDutils_EXPORTS -DDO_NOT_USE_FLENS -DEIGEN3_FOUND -ICPPQEDutils -I/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils -I/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/thirdPartyRandom/Xoshiro-cpp -I/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/thirdPartyRandom/pcg-cpp/include -ICPPQEDutils/thirdPartyRandom -I/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/thirdPartyRandom -Iblitz -Iblitz/blitz/.. -Iblitz/blitz -I/home/bartus/AUR/cppqed-git/src/cppqed-git/blitz/blitz -I/home/bartus/AUR/cppqed-git/src/cppqed-git/blitz/blitz/array/../.. -Iblitz/blitz/array -I/home/bartus/AUR/cppqed-git/src/cppqed-git/blitz/blitz/array -Iblitz/blitz/meta -I/home/bartus/AUR/cppqed-git/src/cppqed-git/blitz/blitz/meta -isystem /home/bartus/AUR/cppqed-git/src/cppqed-git/blitz -isystem /usr/include/eigen3 -D_FORTIFY_SOURCE=2 -march=native -mtune=native -O2 -pipe -fstack-protector-strong -fno-plt -DBOOST_BIND_GLOBAL_PLACEHOLDERS -std=c++17 -O3 -DNDEBUG -fPIC -Wall -Wextra -Wpedantic -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wno-ignored-qualifiers -Wno-sign-compare -Wno-overloaded-virtual -Wunreachable-code -std=c++17 -MD -MT CPPQEDutils/CMakeFiles/CPPQEDutils.dir/Random.cc.o -MF CPPQEDutils/CMakeFiles/CPPQEDutils.dir/Random.cc.o.d -o CPPQEDutils/CMakeFiles/CPPQEDutils.dir/Random.cc.o -c /home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.cc
In file included from /home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.cc:3:
/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.h:104:1: error: explicit template specialization cannot have a storage class
  104 | static const std::string EngineID_v<GSL_Engine> = "GSL_Taus2";
      | ^~~~~~
/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.h:107:1: error: explicit template specialization cannot have a storage class
  107 | static const std::string EngineID_v<std::mt19937_64> = "STD_MT19937_64";
      | ^~~~~~
/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.h:110:1: error: explicit template specialization cannot have a storage class
  110 | static const std::string EngineID_v<pcg64> = "PCG64";
      | ^~~~~~
/home/bartus/AUR/cppqed-git/src/cppqed-git/CPPQEDutils/Random.h:113:1: error: explicit template specialization cannot have a storage class
  113 | static const std::string EngineID_v<XoshiroCpp::Xoshiro256PlusPlus> = "Xoshiro256pp";
      | ^~~~~~`

bz2 compression of state vectors doesn’t work

It seems to be silently disabled at some point, since the COMPRESSION cmake directive doesn’t seem to have any effect at all. State vectors produced with this flag have the same size as those without.

This was an old issue, explore it anew.

bz2 compression can yield orders of magnitude gains for large state vectors.

Discrepancy with boost.python in cmake

CMake Warning at /usr/lib64/cmake/boost_python-1.72.0/libboost_python-variant-shared-py3.8.cmake:74 (message):
Target Boost::python already has an imported location
'/usr/lib64/libboost_python27.so.1.72.0', which will be overwritten with
'/usr/lib64/libboost_python38.so.1.72.0'
Call Stack (most recent call first):
/usr/lib64/cmake/boost_python-1.72.0/boost_python-config.cmake:57 (include)
/usr/lib64/cmake/Boost-1.72.0/BoostConfig.cmake:120 (find_package)
/usr/lib64/cmake/Boost-1.72.0/BoostConfig.cmake:185 (boost_find_component)
/usr/share/cmake-3.17/Modules/FindBoost.cmake:444 (find_package)
CMakeLists.txt:51 (find_package)

Meson/Ninja

Consider deprecating CMake in favor of more modern build (configuration) systems like Meson/Ninja

Movable (formerly: Cloneable) QuantumSystem and Trajectory?

This is especially important in view of the removal of sharedPointerize in 829adb6 whereupon a lot of make_shared calls appeared in the UI.

Serialization enabled is not correctly identified for blitz++ by our cmake machinery.

Apparently, the identification always yields negative outcome.

`StateVectorLow` in Examples is undefined.

Recent changes makes some examples references ambiguous.

In file included from /build/cppqed-git/src/cppqed-git/CPPQEDcore/examples/ExampleMode.cc:2:
/build/cppqed-git/src/cppqed-git/CPPQEDcore/examples/ExampleMode.h:80:11: error: no type named 'StateVectorLow' in 'structure::ElementLiouvillean<1, 2, false>'; did you mean 'StateVector'?
  typedef ElementLiouvillean<1,2>::StateVectorLow StateVectorLow     ;
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          StateVector

Pumped Mode shared ladder operators to increase performance

Mode + JaynesCummings are a bit wasteful in that if the Mode is pumped, then in interaction picture the same update with the frequencies of the ladder operators happens in the pump part as in the JC part of the Hamiltonian.

This could be alleviated if a pumped Mode (or, a ModePumpedHamiltonian class) stored the a and adagger operators separately (not in a bulk Tridiagonal object), and JaynesCummings just refers to those, if they exist (that is, if the Mode is pumped). This can be very elegantly achieved by storage by shared pointers.

Of course, the same problem exists for Qbit and the MultiLevel bundle.

Restore nice user interface without sharedPointerize

After removing this unstandard/confusing sharedPointerize interface in 076f7d8d5b, the interface in scripts for StateVector/DensityOperator initial conditions became very awful. Basically all the syntactic sugar of the vector-space algebra is gone.

Solution: QuantumTrajectory should hold a shared_ptr to SV/DO. When initialized with a shared_ptr, the passed shared_ptr is simply copied into the held shared_ptr. When initialized with a bare object, create a copy of that object (using the by-reference semantics of blitz copy) as a shared_ptr, and initialize the held shared_ptr to point to this copy.

Investigate how far this approach can be pursued (also for QuantumSystems, SubSystems, etc. – these are at the moment maybe not even copyable!).

	static const std::string EngineID_v<GSL_Engine> = "GSL_Taus2";

	template<>
	static const std::string EngineID_v<std::mt19937_64> = "STD_MT19937_64";

	template<>
	static const std::string EngineID_v<pcg64> = "PCG64";

	template<>
	static const std::string EngineID_v<XoshiroCpp::Xoshiro256PlusPlus> = "Xoshiro256pp";

vukics / cppqed Goto Github PK

cppqed's People

Contributors

Stargazers

Watchers

Forkers

cppqed's Issues

Can this be overridden depending on compiler ?

relevent lines:

gcc error:

Recommend Projects

Recommend Topics

Recommend Org

`relevent lines:`

`gcc error:`