Author Topic: Cleaning the FluidDynamicsApplication  (Read 515 times)

jcotela

  • Newbie
  • *
  • Posts: 4
Cleaning the FluidDynamicsApplication
« on: April 27, 2016, 12:28:02 PM »
Dear Kratos users:

We are currently considering a reorganization of the FluidDynamics application. Since we consider it a core component of Kratos Multiphysics, we should be particularly careful in ensuring that it is stable and robust, but we find that it has been growing out of control in recent times. To manage it, we are considering the possibility of dividing it into a stable, tested and documented core and a more experimental derived application, containing extensions, innovations  and problem-specific solutions.

Before we go forward with this proposal, we would like to hear the opinion of the community. In particular, we are interested in the following:

1. Would this approach cause problems for your particular situation?
2. Are there backwards compatibility issues that should be addressed? That is: do you rely on the particular implementations of any of the current components and would moving them around (and maybe deprecating some, replacing them by newer implementations) cause trouble for you?
3. What should be considered "core" and what is "extra"? In this sense, we are proposing to consider the components at the end of this post (exclusively) as core.
4. Should turbulence models be part of the FluidDynamics application or should they be moved to a specific (derived) application?

What follows is the proposal for the new core of the FluidDynamicsApplication

SolverGeometriesEmbeddedTwo-phaseTime schemeTurbulenceNon-Newtonian
Monolithic Navier-Stokestriange, tetrahedra, quadrilateral, hexahedraNoNoBossak, BDF2YesNo
Embedded Monolithic Navier-Stokestriange, tetrahedraYesNoBDF2NoNo
Two-phase Monolithic Navier-Stokestriange, tetrahedraNoYesBDF2NoYes
Fractional step Navier-Stokestriange, tetrahedra, quadrilateral, hexahedraNoNoBDF2YesNo
Embedded FS Navier-Stokestriange, tetrahedraYesNoBDF2YesNo
Monolithic Stokestriange, tetrahedraNoNoBDF2NoYes
Two-phase Monolithic Stokestriange, tetrahedraNoYesBDF2NoYes

Monolithic Navier-Stokes Solvers:

- Monolithic solver: New implementation, using the same formulation (ASGS/OSS) as the current one but with support for quadrilaterals/hexahedra.
    Supported geometries: triangles, quadrilaterals, tetrahedra, hexahedra.
    Time scheme: Velocity Bossak (the current default) or BDF2.
    Support for turbulence: Any model based on an eddy viscosity.
    No support for non-Newtonian constitutive laws.

- Embedded monolithic solver (new implementation)
    Supported geometries: triangles, tetrahedra.
    Time scheme: BDF2 only
    Support for turbulence: Not planned.
    Support for non-Newtonian constitutive laws.

- Two-phase Monolithic incompressible Navier-Stokes (New implementaiton)
    Supported geometries: triangles, tetrahedra.
    Time scheme: BDF2 only
    Support for turbulence: No
    Support for non-Newtonian constitutive laws.

Segregated (fractional step) incompressible Navier-Stokes solvers

- Fractional Step solver (body-fitted geometries only)
   The current segregated incompressible solver implementation, extending support to quadrilaterals/hexahedra
    Supported geometries: triangles, quadrilaterals, tetrahedra, hexahedra.
    Time scheme: BDF2
    Support for turbulence: Any model based on an eddy viscosity.
    No support for non-Newtonian constitutive laws.

- Embedded fractional step (non-body-fitted meshes): current implementation.
    Supported geometries: triangles, tetrahedra.
    Time scheme: BDF2
    Support for turbulence: Any model based on an eddy viscosity.
    No support for non-Newtonian constitutive laws.

Stokes flow solvers

- Stokes flow (body-fitted geometries): New implementation
    Supported geometries: triangles, tetrahedra.
    Time scheme: BDF2 only
    Support for turbulence: No.
    Support for non-Newtonian constitutive laws.

- Two-phase Stokes flow (new implementation)
    Supported geometries: triangles, tetrahedra.
    Time scheme: BDF2 only
    Support for turbulence: No
    Support for non-Newtonian constitutive laws.

Anything not on the list would go to a new "experimental" CFD application. Solvers that support turbulence will also support wall law boundary conditions. Otherwise, only inlet, no-slip or no-penetration boundary conditions should be available.
« Last Edit: April 27, 2016, 12:31:21 PM by jcotela »

MikeA

  • Newbie
  • *
  • Posts: 21
Re: Cleaning the FluidDynamicsApplication
« Reply #1 on: April 28, 2016, 10:12:22 AM »
Hi Jordi,

- How would element functions such as GetValueOnIntegrationPoints and Calculate be managed? The reason for asking is that we sometimes calculate a quantity (e.g. vorticity using the integration_point_to_node_transformation_utility) using these functions and there may be new quantities in the future.

- It would be good if the core elements could be general with respect to time integration schemes defined elsewhere that might need to evaluate the rhs multiple times at different solution steps, e.g. Crank-Nicolson. This could help prevent code duplication in the future.

- An option to compute either lumped or consistent mass matrices would be good.

Best regards,
Mike

pooyan

  • Global Moderator
  • Newbie
  • *****
  • Posts: 33
Re: Cleaning the FluidDynamicsApplication
« Reply #2 on: April 29, 2016, 11:58:53 AM »
In general I agree with this move and the idea of having a clean FluidDynamicApplication.

Nevertheless I won't go for dividing the application by features like turbulence or Rans, etc... In my opinion if their quality of any related feature is good then it should be in the FluidDynamicApplication. In this way we reduce the knowledge (of the user) to know which specific apps must import for its problem and less problem with dependency between applications.