scienza / schroedinger Goto Github PK

Schroedinger Equation in the finite potential well off by factor 2 on the height of the potential. Eigenenergy to be checked.

generalize the implementation of different dimensions in basis class

In file Numerov.cpp function operator<<, modify format of printing wavefunction (in the future this will belong to class States).

Modify the priting format, to include coordinate (from basis). Also to be done for Potential class printing.

prefer spaces to tabs for ASCII compatibility.

Way better to print all together

x (from the basis)         waveFunction         Probability
0.000000                    1.234e-10            2.012e-20
0.100000 ...
...

Could be made into a easy issue for @Bhez

Originally posted by @AndreaIdini in https://github.com/Scienza/Schroedinger/diffs

Getter should be made const according to @GabrielePisciotta

Be careful about memory management in methods and fix with known recipes.

Question 1:

Numerov::Numerov(Potential potential, int nbox) : Solver(potential, nbox)
Al momento inizializza la wavefunction, che in realta' andrebbe inizializzata quando si lancia l'algoritmo di bisezione.
Dato che numerov quello che fa e' lanciare la bisezione una volta, va bene anche cosi' istanziarlo col costruttore, pero' se si cancella quella parte e si fa un init vuoto va tutto in vacca anche inizializzando dentro la bisezione... perche'?

Question 1.5:
wave function should be initialised in Solver, because the initialisation is valid for every type of solver. It could be more convenient to initialise it directly in the routine that does the actual solving to avoid propagating errors in asymmetric solvers. E.g. wave function(border) = 0, 10^-5 is recognised as solution at first matching with 0; 10^-4 at second iteration matching with 10^-5; 10^-3 matching with 10^-4...etc... Evaluate what's best practice.

Question 2:
Numerov::Numerov(Potential potential, int nbox) takes Potential as input. But potential is already a member of class Solver. Is there a reason for it?

Question 3:
Can we make more clear or efficient the current implementation of scanning + bisection?
At the moment the solver start scanning from the lowest energy with a certain step, once found conditions for sign changes looks at the bisection solution in the middle of the last step.

Change the CMakeLists in order to compile:

• library
• main CLI bin
• tests bin

The base class is arguably the most critical part of the program.
A detailed description of a proposed implementation is available in the wiki

Be sure that each class and major routine has comments that explain how it works in a concise way. Great exercise to understand what happens in the code

From: I would write a little comment about what this class is about, but it's a minor thing...

Originally posted by @Pandry in #43

circleci shield does not update with circleci status

Implement CMake and/or installer to compile the program and gtest.

Verify compiler version/compatibility and eventual additional libraries.

Continuous basis can be real, but also complex (cf. Berggren basis).
Implement a creation that takes into account complex basis.

Maybe through template objects.

Implement the solver class:

• interface method: keep the option open to use more solvers
• modify the structure to be more "C++ like" (less pointers and list, more std::)
• prototype how to handle the centrifugal term for spherical and cilindrical, 3D and 2D

• Compare box at zero potential with trigonometric wave function.
• Compare eigenfunction of the harmonic oscillator with Hermite polynomials
• ... for different sizes
• Compare with Numerical potential respect to a professional solution

Construct a trapezoidal numerical integration routine that generalizes to integrals in many dimensions.

Just shut up already!

Right now tests are don by absolute differences with the analytic wave function. The threshold is eyeballed.

Find something more clear and meaningful.

One possible Numerov precision limited when treating discontinuous potentials.

Implement boundary condition property, to be used in Numerov. I believe the best place to set the property is basis, while the setup in Numerov should be done when calling the Numerov::Solve method.

This initialisation (of Numerov wf[0]=0.; wf[1] = 0.1; ndR) does not belong to the start of class, but to something that should be called before findWavefunction. That is, the setup of the boundary conditions, that should be in solve and bisection.
Now bisection is too coupled with solved, so it cannot be generalized, so there is fine. (cf. later comment)

Originally posted by @AndreaIdini in https://github.com/Scienza/Schroedinger/diffs

At the moment, the program gets only one state composed of

• energy
• wavefunction

It is needed to introduce a system to find a mange all the states in a given range.

The automatic testing is now implemented using Google Tools. As it is in 23/01/18 it does not work as intended.

• Make it work comparing analytical wavefunction and numerov solution point-by-point (eventually).

• Compare Eigenvalues too.

Come mi unisco?

Requisites to consider:

• implementation of different bases (now is in cartesian 1D, one can be willing implement spherical, Bessel, cylindrical, multiD ...etc...) and potentials.
• different method of solution (stationary and time-dependent Schroedinger, relativistic)
• introducing different many--body nature of particles (fermions, bosons)
• possible expansion towards many--body and field--theory methods (MBPT, Coupled Cluster)...etc...

Applicate principles discussed here

For some problem it is convenient to work in momentum space, and be able to go back and forth from it to the real space.
Implement a routine that does the latter.

Make a working example of interactive custom_workflow() in main.cpp

Grande idea. Da far completare a @Pandry e @Bhez ?

Originally posted by @AndreaIdini in https://github.com/Scienza/Schroedinger/diffs

WfTest.HarmonicOscillator test, only on Windows, raises a "vector subscript out of range" error.

We should use a proper library (I propose https://github.com/gabime/spdlog ) to manage logs. Have a look
at it, there are examples of how to use it and it's explained its flexibility.

This have to be included as an external module (as we did with googletest module), also modifying the main CMakeLists.txt in order to compile it.

setting err = 1e-10 the box wave function tests ok.
However, setting a lower error threshold implies false test. The numerov solution output is up to 10^-11 precise, but setting a lower precision does not put it in infinite loop. Probably the limit on bisection blocks the infinite loop, and the 0.1 mesh implies the limit on precision.

To be verified.

Thread to evaluate possible pro-cons of Graphical Libraries that can be used in the project. Feel free to edit this message and comment.
Cf. wikipedia List

• GTK
  - Pro: Native C++
  - Cons: Not top notch (?)
• [QT]
  - Pro: native C++, standard
  - Cons: Heavy, difficult, compatibility
• OpenGL, maybe JUCE (C++)
  - Pro: native C++, very standard
  - Cons: ExtraHard (maybe not?).
• PyGame (Python)
  - Pro: Easy to use (?)
  - Cons: not really fashionable 2D Engine
• Kiwy (Python)
  • Pro: looks beautiful
• Unity (C#)
  • Pro: is pro
  • Cons: is pro (hard?)
• d3j (Javascript)
  • Pro: is beautiful and gold standard for data viz, can be interactive
  • Cons: 2D only. Is it bindable to C++?

The multidimensional test for harmonic oscillator does not work. The state has the correct energy, but the wave function keeps its 0s initialisation.

The code is an exact copy of the code in main.cpp that prints the wave function with good results! Might be a mishandling of pointers?

TODO: once fixed the wave function output, I will do multidimensional tests on Finite Well potential, and maybe higher eigenvalues options.

Given an ASCII file for potential, e.g.,

0.0   2.1
0.2   2.2
0.4   2.7
...
20.0  0.01 

reads the potential and the basis mesh (implying either 1D or radial, for example)

Once the States class has been implemented in issue #47 this is an easy enhancement.

@mechanapoleon this Find Energy routine can be easily modified to find all the eigenstates between e_min and e_max.
At the moment, it is a simple scan of the zero starting from e_min with mesh e_step. Once a change of sign has been found, it starts a bisection to find the correct Energy and break from loop.

Once the class States able to manage different states is introduced, it is easy to modify this routine to not break when the solution is found but to save the solution and continue scanning.

To be made issue

Originally posted by @AndreaIdini in https://github.com/Scienza/Schroedinger/diffs

State

In the last commit before this issue, there is a stub for a public class (also commutable to structure) initializer.

The idea behind this is to get an intuitive and versatile initialisation of basis states.

It is related to problems throughout the last instance of the code #33 #30 #22 #8

Problem

The problem is that the state can be initialized in several different ways, and operator overload is boring, complicated and sometimes not straightforward to implement. E.g. we want to implement as continuous basis as int unsigned nbox; double mesh, or double start, end; int nbox and also double start, end, mesh;.
A way to solve this is to overload operators.

But, when we want to initialise a spherical basis, other than one continuous r coordinate we need also quantized angular momentum quantum numbers. Therefore we can implement a spherical basis (l coupling) providing only maximum l either with 1 double and 2 int, or 2 double and 2 int, or 3 double and 1 int. But what if we want to provide min and max l? how could you overload? there are several possible overload combinations, and

Solutions:

• A possible solution is considering specific factory methods
  buildSpherical3D(...)
buildCartesian1D(...)

pro - easy and straightforward to implement.
cons - tedious implementation; many methods that can confuse user.

Implement in [this commit]
(230a020)

• Another solution uses a further abstraction layer between Base class and DiscreteBase
  Implemented in [this commit(?)](3a04d6b 2) by Gabriele.

pro - versatile, agile, amazing, computersciency... etc...
cons- as it is doesn't really fit the story

• A final try is with this last commit. and the public class instance initializer

pro - easy
cons- ?

Stories

Ideally we want the user (and us) to build factorized basis with ease. In pseudocode we could think to build a 3D spherical, j-coupled or ls-coupled basis, just like this in pseudocode:

Mesh = 0.1
Nbox = 1000
Lmax = 20
spin = 1/2
build(SphericalJ)

Or a 3D Cartesian

Mesh = 0.1
Nbox = 1000
build(Cartesian, 3)

Or directly providing the vector for cartesian

std::vec<double> x
build(Cartesian, 1)

or otherwise basis

std::vec<double> x
Lmax = 20
spin = 1/2
build(SphericalJ)

(Harmonic oscillator)

Basis::ContinuousBasis . coord cannot be tested as vector but only if considered elements of a vector.

This from implementation of Base test: 17795e4