in PR #5109, the functions read/write cube file have been refactored partially, in which the trilinear interpolation functions has been moved out, this is a good practice.
However, the parameter lists of functions are still too complex, and there are still not good abstraction of functions:
bool read_cube(
#ifdef __MPI
const Parallel_Grid*const Pgrid,
#endif
const int my_rank,
const std::string esolver_type,
const int rank_in_stogroup,
const int is,
std::ofstream& ofs_running,
const int nspin,
const std::string& fn,
double*const data,
const int nx,
const int ny,
const int nz,
double& ef,
const UnitCell*const ucell,
int& prenspin,
const bool warning_flag = true);
In principle, the cube file format is fixed (http://www.paulbourke.net/dataformats/cube/), so the primitive information that can be got from reading, and the content that can be directly write into file should be no other than:
a title line
number and size of voxels in three direction
atomic index, charge (optional and can be zero), Cartesian coordinates
volumetric data
. Therefore it is obvious that "Pgrid, my_rank, esolver_type, rank_in_stogroup, is, ofs_running, nspin, ef, ucell, prenspin, warning_flag" are more or less unnecessary and should be only considered in its caller functions.
The dual function write_cube has similar problem:
void write_cube(
#ifdef __MPI
const int bz,
const int nbz,
const int nplane,
const int startz_current,
#endif
const double*const data,
const int is,
const int nspin,
const int iter,
const std::string& fn,
const int nx,
const int ny,
const int nz,
const double ef,
const UnitCell*const ucell,
const int precision = 11,
const int out_fermi = 1);
the variables "nz, nbz, nplane, startz_current" only matter when the realspace grid points are distributed, but this is not the task "writing data to cube file" should take care. Additionally, the variables "is, nspin, ef, ucell, out_fermi" are still more or less unnecessary here.
Additional Context
No response
Task list for Issue attackers (only for developers)
[ ] Identify the specific code file or section with the code quality issue.
[ ] Investigate the issue and determine the root cause.
[ ] Research best practices and potential solutions for the identified issue.
[ ] Refactor the code to improve code quality, following the suggested solution.
[ ] Ensure the refactored code adheres to the project's coding standards.
[ ] Test the refactored code to ensure it functions as expected.
[ ] Update any relevant documentation, if necessary.
[ ] Submit a pull request with the refactored code and a description of the changes made.
Describe the Code Quality Issue
in PR #5109, the functions read/write cube file have been refactored partially, in which the trilinear interpolation functions has been moved out, this is a good practice. However, the parameter lists of functions are still too complex, and there are still not good abstraction of functions:
In principle, the cube file format is fixed (http://www.paulbourke.net/dataformats/cube/), so the primitive information that can be got from reading, and the content that can be directly write into file should be no other than:
. Therefore it is obvious that "Pgrid, my_rank, esolver_type, rank_in_stogroup, is, ofs_running, nspin, ef, ucell, prenspin, warning_flag" are more or less unnecessary and should be only considered in its caller functions. The dual function write_cube has similar problem:
the variables "nz, nbz, nplane, startz_current" only matter when the realspace grid points are distributed, but this is not the task "writing data to cube file" should take care. Additionally, the variables "is, nspin, ef, ucell, out_fermi" are still more or less unnecessary here.
Additional Context
No response
Task list for Issue attackers (only for developers)