Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • dumux dumux
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 101
    • Issues 101
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 90
    • Merge requests 90
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dumux-repositoriesdumux-repositories
  • dumuxdumux
  • Issues
  • #711
Closed
Open
Issue created May 28, 2019 by Alexander Jaust@ajaustDeveloper

Access to problem quantities (like thermal conductivity) model dependent

I observed that it is problem-/model-dependent how to obtain the thermal conductivity. This make it hard to reuse some of my functions with different problems/models.

  • Would it be possible to unify the interface?
  • Is there a (smart) way to generalize functions that should work for different problems/models?

Short description

The interface to obtain model properties is not unique. Obtaining the thermal conductivity lambda looks different for different types of problems used.

  • Using SolidEnergy model: lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,problem.spatialParams(),element,fvGeometry,scv)
  • Using NavierStokesNI model: lambda = volVars.effectiveThermalConductivity()

In my case, this makes is hard to reuse an already implemented function. Moreover, it does not feel intuitive that the interface to obtain the conductivity differs (that much) between two physical models.

Longer description

Kilian and me have been recently worked on a routine that constructs the temperature on a boundary. It basically gets a heat flux Q on the face of an element and the temperature T_cc at the cell center. Together with the thermal conductivity lambda and the distance from the cell center to the face distance obtain the temperature on the face T_face from the following formula:

Q = - lambda ( T_face - T_center ) / distance
=> T_face = - Q * distance / lambda + T_center

It has been implement once for a heat equation problem that inherits from SolidEnergy. In this case heat conductivity is obtained via ThermalConductivityModel::effectiveThermalConductivity. In my particular case it looks like that:

const Scalar lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,
                                                                             problem.spatialParams(),
                                                                             element,
                                                                             fvGeometry,
                                                                             scv);

Now, I wanted to reuse the function for a Navier-Stokes based problem that inherits NavierStokesNI. I tried reuse the function we had already written, but this fails since the heat conductivity has to be obtained via the effectiveThermalConductivity member function of an object of type ElementVolumeVariables. In my case it looks like:

const Scalar insideLambda = volVars.effectiveThermalConductivity();

Due to that I had to implement the same function twice which I would like to avoid

Assignee
Assign to
Time tracking