Redesign physics

[barche]

We should discuss how the physics will finally work and if/how they should be refactored. We will do a special meeting about this.

[tlmquintino]

I would like to participate (remotely) on this meeting. We can do it over skype, since the connection here is pretty good.

[barche]

Yes, gladly, we'll keep you posted on the planning. I want to hammer out the handle stuff before we tackle this.

[wdeconinck]

We need to find a way to not sacrifice performance, but add flexibility.

A solution needs to be found to access fields from within the physics, without having to pass it as function arguments using a generic API. It should be flexible enough so that numerics will not be polluted by concrete physics. e.g. background mean flow for linearized Euler, or wall-distance for turbulence models, cell-volumes for LES.

[wdeconinck]

I am beginning to think, as does Tiago, that physics can simply not be completely separated 100% from numerics in a SIMPLE/ELEGANT fashion. The whole goal should be to keep physics as easy as possible. Creating constructs and adaptor classes will only complicate things further. Just looking at the UFEM code is a perfect example of how the physics is completely intertwined with numerics, while it is still very simple/elegant to implement new physics. Riemann solvers are both numerics and physics dependent. Boundary conditions are also both numerics and physics dependent.

However for maximum code reusability, the physics and numerics should still remain as separate as possible of course. If both numerics and physics are assembled out of small unix-style operations, it must be able for the physics developer/user, to create a simulation with a minimum of numerics knowledge. Smaller operations lead to much more flexibility for special treatments for boundaries, and other situations that I cannot foresee at this moment, but will surely surface. In fact, it is also the case with UFEM, where the smaller operations are just hidden in the proto-language operators My intent however is to do this in a dynamic way.

As the physics is then a (more isolated) PART of the numerics, it knows where and how to access all required fields, and has knowledge of which element it is working on. Yes, for discontinuous methods, physics must also know it works on element-based fields as opposed to point-based fields, as it might have to compute quantities on demand from existing fields, with the accuracy of the numerical method.

[tlmquintino]

Building on what Willem just posted...

I think that at least the physics functions that depend solely on point based data (and there are many) can be made rather independent of the numerics.

By point based data I understand for example: X,Y,Z plus the independent set of variables, e.g. [P,U,V,T], plus the derivatives of such set [P,U,V,T]_x [P,U,V,T]_y.

The problem arises when certain functions need some extra info to perform their calculations, as is the case with the fluxes in Linearized Euler in the presence of background flow.

The access to configurable physical properties and/or libraries that provide them, is also an issue that intertwines deeply into the design.

[wdeconinck]

If we decouple configuration and setting of configurable variables from the physics, the physics should not change.

The physics::Properties are then just an "advanced" state, where the solver is then responsible to set everything.

Some talks with Matteo also convince more that the physics cannot be separated from numerics.

To give another perspective: In the open-source code clawpack he is using, the Riemann-solver is one and the same with the physics. i.e. for every physics there is a riemann solver class responsible to do with a given state, and some auxiliary data what is necessary. The physics::Properties for us combines both the state and extra necessary variables.

In cf3 we would then have the solver set this physics::Properties before calling the riemann solver. The reason why in Clawpack the solver needs not to know how to compute the auxiliary data, is because of the structured data-structure, and all auxiliary data is computed and stored for every point before every time step, decoupling knowledge.

For high order methods, such as Spectral Finite Difference, reconstruction is required and precomputed storage is not feasible. I am now working on a sandbox, where I create SFD specific equation terms, also specific for different physics. These terms are composed using small reusable SFD operations such as "reconstruct to flux points", "compute gradient in flux points", "divergence in solution points from flux points". Shared cached data/operations avoids that reconstruction or data is computed twice per element, which could be shared for different terms.