We're reading from disk, so we go from type in disk to type in destination
The type of destination is SomeVectorType
The underlying type of destination is SomeVectorType::value_type
Therefore, we have underlying type in disk and underlying type in destination
Let's call floating the set {double, float}
underlying type ut_disk in disk is in {floating, complex, other}
underlying type ut_dest in destination is also in {floating, complex, other}
if ut_disk == ut_dest all is good
if ut_disk != ut_dest we throw unless
ut_disk == floating and ut_dest is std::complex<floating> so
that we can go from floating to complex<floating>

I won't talk too much about implementation because it might change.
Note the complication of taking Real<SomeVectorType::value_type>::Type
which is not discussed here because
"The source is fully true." (Gonzalo, 2021)

As far as disk is concerned, a name + "ComplexOrRealType" single char set
is written to the hd5 file only if
vector<floating>, with content 'R'
vector<std::complex<floating> >, with content 'C'
all other vectors aren't prepended at all and
a read for name + "ComplexOrRealType" set in the hd5 file will fail.

writing std::vector<std::complex<T> > in IoNgSerializer
now writes a marker before, with name equal to
name of vector + "ComplexOrReal" and content "C"
This marker isn't written if the vector is real.
readInternal tries to read the marker allowing
reads from real --> complex, in addition to the
real --> real, and complex --> complex.

If the file PsimagLite/src/Ainur/Config.make
doesn't exist then configure.pl
creates it by copying into it
PsimagLite/src/Ainur/Config.make.sample
This last file has been updated for
correct compilation of Ainur's examples.

PredicateAwesome ctor accepts an or separator,
which default to ,
and an and separator, which default to &
PredicateAnd accepts an and separator,
which default to &
Predicate Simple accepts a node separator,
which default to :

These preprocessor flags, when enabled,
make int long be the type used in
PsimagLite BLAS and LAPACK headers
respectively as opposed to just int

This is the reverse of lorenzian.pl: given
a file with
omega value
it gives us the location of the weights
and their height, along with the delta used.

lorentzian.pl filename omegaBegin omegaTotal omegaStep delta norm

filename is a two column formatted file, where
the first column contains weights and the second
column contains the omegas for each weight.

The loop is from i=0 to i<omegaTotal with
omega = omegaBegin +  omegaStep*i

The Lorentzian has weight delta.

The norm is optional and, if provided, the function
will be normalized so that the sum over omegas
equals norm.

(*) But signs of scalars need more testing to
make sure it's correct