refactor: nested namespace structure

[paveltomin]

implement proposal from #1876, for flow solvers only for now

also move zformulation into a separate namespace and simplify flux compute kernel call logic a bit

[paveltomin]

This builds and tests are ok, ready for a look

[Copilot]

Pull Request Overview

This PR refactors the nested namespace structure for flow solver kernels, implementing a cleaner organization pattern with nested namespaces under kernels. The refactoring primarily affects the flow solver components, moving kernel classes into structured namespaces like kernels::fluidFlow::singlePhase, kernels::wells::compositional, etc. Additionally, the zformulation functionality is moved into a separate namespace and some code is simplified.

Key changes include:

• Reorganization of kernel namespaces from flat structures to nested hierarchies
• Introduction of using namespace declarations to maintain compatibility
• Moving zFormulation kernels to dedicated namespace structure
• Minor code simplifications in flux computation logic

Reviewed Changes

Copilot reviewed 144 out of 144 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Test files (.cpp)	Updated namespace usage with new using declarations for compositional and single phase well kernels
Kernel headers (.hpp)	Restructured namespace declarations from flat to nested (e.g., singlePhaseWellKernels → kernels::wells::singlePhase)
Implementation files (.cpp)	Updated namespace declarations to match new nested structure
Physics solver files	Simplified flux computation logic and updated namespace references
zFormulation files	Moved to dedicated zformulation namespace and renamed some classes/files for consistency

Comments suppressed due to low confidence (4)

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[MelReyCG]

Why not having a kernel namespace per namespace? (when needed)

Suggested change

	m_minCompDens( kernels::fluidFlow::compositional::minDensForDivision ),
	m_minCompDens( fluidFlow::compositional::kernels::minDensForDivision ),

As it is proposed here, it seems like a duplicated tree of solver namespaces.

[paveltomin]

@rrsettgast @MelReyCG current version is like that:

i think what @MelReyCG is suggesting makes a lot of sense and i can swap it around, just confirm that this is the choice
i can also try to wrap solvers into namespaces in a follow-up

[rrsettgast]

@paveltomin I would agree with swapping the kernels to the end

[tjb-ltk]

@rrsettgast @MelReyCG @paveltomin
Thinking about future consolidation or not... In Jacobian assemble singlePhase and compositional specialization implement the same interfaces... separation of single phase and compositional introduces a layer that may not be needed. Ideally there would be one fluid flow and inside its assemble/update/check methods, switches/factories to call the specialized versions based on model definition. Why duplicate the algorithmic flow code when it doesn't provide any performance optimizations. having single algorithmic flow at a higher level with specializations inside the algorithmic component methods might be easier to maintain.. going down that path maybe something like fluildFlow:kernels:: would be more appropriate...

[paveltomin]

i switched to
fluidFlow::kernels::compositional::...
that seems logical and it matches the file structure, and it allows to share some kernels and definitions defined at top level between single-phase and compositional in a more clean way

[paveltomin]

@MelReyCG @rrsettgast @tjb-ltk is it good now?

[OmarDuran]

I’m not fully involved in this discussion, but I agree that matching the namespace to the file structure is more logical and cleaner.

[dkachuma]

Should there be a thermal version of this?

[paveltomin]

this one is general, both for thermal and isothermal

[dkachuma]

Do we no longer need the jump stabilised version of this?

I see now where this is moved to.