clarity of types: define type rules

[ragusa]

For example, too many size_t. Also, double vs real (float32 vs float64 or 32 vs 64 bits)

Need deeper thoughts (define type rules), followed by a refactor to clean this up.

Think of a configure option.

[andrsd]

Regarding the floating point precision: Typically this is done via a configure option. We can create an enum in the cmake script for single and double precision. We want an enum, so people do not have to type and just cycle through the options if they use ccmake (we already have this for the build type). Then, we will have cmake create a config file via configure_file. This file will define something like a Real type which will be used in the code.

Relevant bits would look like this:

CMakeLists.txt:

set(BuildValues "single;double")
if(NOT OPENSN_PRECISION)
    set(OPENSN_PRECISION "double" CACHE STRING "Floating-point precision" FORCE)
endif()
set_property(CACHE OPENSN_PRECISION PROPERTY STRINGS ${BuildValues})
...
if (OPENSN_PRECISION STREQUAL "single")
    set(OPENSN_PRECISION_TYPE "float")
elseif(OPENSN_PRECISION STREQUAL "double")
    set(OPENSN_PRECISION_TYPE "double")
else()
    message(FATAL_ERROR "Unsupported precision type: " ${OPENSN_PRECISION})
endif()
...
configure_file(config.h.in config.h)

config.h.in:

#pragma once

namespace opensn {
using Real = @OPENSN_PRECISION_TYPE@;
}

Similar approach can be used for various indices. In libMesh, they have things like dof_id_type for indexing into global solution vectors, boudary_id_type, subdomain_id_type, etc. PETSc has only PetscReal and PetscInt, IIRC. I Definitely see this happening for integers.

A lot of times I have seen this done via macros, but we should avoid those and use real C++ types as shown above...

Note that the names above are picked just for demonstration, the final names could change.