LoadOrbitalsFromRestartFile and miscellaneous changes

[dreamer2368]

Once merged to release branch, this PR must be merged from release to ROMFPMD.

loadOrbitalFromRestartFile

MGmol<OrbitalsType>::loadOrbitalFromRestartFile(const std::string filename) reads a restart file from a specified filename, initializes an orbitals based on the restart file.

While LocGridOrbitals::read_func_hdf5 or ExtendedGridOrbitals::read_func_hdf5 do read orbital data from a restart file, additional initialization routines are necessary to directly use an orbital from a file. These routines, at least for MD-type simulation, are spread throughout the entire workflow. The newly implemented function loadOrbitalFromRestartFile collected all these necessary routines to initialize orbitals, so that the returned orbital is ready to use right away.

Caveats:

• This only allows MD or Quench type simulations
• Only double-precision HDF5 file (restart_info = 4) is allowed for now.

Miscellaneous changes

• cmake_modules/FindSCALAPACK.cmake searches default paths for scalapack library.
• Carbyne example input files are added.
• name change: src/tools/Signal.h -> src/tools/mgmol_Signal.h
• MGmol<OrbitalsType>::orbitals_extrapol_ and OrbitalsExtrapolation::orbitals_minus1_ are initialized as nullptr at class declaration. This is a change reflecting the issue nullptr initialization of pointer member variables in class definition #223 .

[oseikuffuor1]

@dreamer2368 this looks good to me. Thanks. Have you been able to test the load functionality yet?

[dreamer2368]

@dreamer2368 this looks good to me. Thanks. Have you been able to test the load functionality yet?

In short answer, yes.
I rebased #216 into rombasis-rebase, which is a temporary PR #227 . PR #227 is only a placeholder for me to track changes. I reconciled all discrepancies caused from rebasing, and tested on LC quartz. This PR #226 cherry-picked the common part of the reconciled PR #227.

[dreamer2368]

@jeanlucf22 , I commented out some unnecessary parts. I left them commented, since we're not sure whether they may be needed in future for ROM workflow. Also see the detailed comments above.

[jeanlucf22]

I would remove most of the comments: I don't think they are useful, and some may be misleading in this context. Beside, this makes a relatively simple function look very complicated