Fields and Variables

[wdeconinck]

I have a proposal for the Fields and Variables.

I would propose to have only 1 variable per field.
This would really improve the handling of fields and variables.

• All variables in the "dictionary" have a unique name
  --> function-parsers could automatically use these unique variable names as arguments
• Lengths of variables are trivial
• A field has only 1 variable type
• Operations on fields are now identical to operations on variables.

A field would be defined to have only one of following variable-types:
SCALAR: 1 column
VECTOR_2D: 2 columns
VECTOR_3D: 3 columns
TENSOR_2D: 4 columns
TENSOR_3D: 9 columns
ARRAY: variable columns

There is of course the "issue" of the solution-field consisting in principle out of many variables. This is really more of an exception than a rule.
I propose to just keep that field as 1 variable "solution" of the ARRAY variable-type consisting of e.g. 5 columns in the 3D Navier-Stokes case. The solution variables (e.g. rhoE ) are usually not as important as more tangible variables such pressure and temperature.
This solution-field should then be seen as a more intermediate field, just to arrive to a set an updated set of variables. A physics module or python script is then responsible for translations.

[tlmquintino]

I fully agree. It would make things much simpler. And simpler is better ;)

Even for the solution field, often the fields do not behave as a Tensor together: rhoU, rhoV, rhoW are a vector, but rho and rhoE are not (hence the ARRAY type) -- so if you want to keep them together, you name the whole lot something like: u[] and u[0] is rho. Then what we can do is provide some sort of "alias" component, that allows you to write "rho", and internally translates to u[0].

[wdeconinck]

In literature one indeed calls it the solution "variable", with symbol Q or U or W.

I don't think this poses any issue for UFEM, as if I understand correctly, it assembles a solution-vector on the fly (?)

[barche]

Allright, looks like we have an item on the agenda for Thursday then ;) Anyway, just a short version of my thoughts about this:

I don't want to be a wet blanket, but converting what we have now to this "simpler" system is a far from easy task. When interfacing the LSS, for example, it is much easier to refer to all variables if they are in the same field, otherwise updating the solution vector becomes a nightmare. Switching to an "array" variable as a combined pressure, temperature and velocity places this burden on the author of the solver, making things much harder instead of simpler.

µThere is also the issue of parallel sync, where a field is handled in one grouped comms call, so that's an optimization we'd lose.

Basic observation: if the current API to access variables is too complicated, we should work on improving that API, and not jump head-over-heels into a structural change that will require a LOT of rewriting.

[tlmquintino]

Those are pretty good points.
Note that this issue is marked as IDEA. I don't think we need to rush and implement it -- see it as a brainstorming: exactly so the discussion can bubble up these types of issues ;)

[barche]

Absolutely! Note that I am in favor of keeping our API as simple as possible, but I'm sure we can figure out ways to have a simple API and still keep the advantages of the current data structure. It's definitely a strength that we have such radically different solvers as SDM and UFEM, that makes sure all requirements are met.

[wdeconinck]

I do think that it is a too complex system to have IN GENERAL multiple variables inside fields. It is much easier to think in terms of scalar-fields, vector-fields, tensor-fields, ... The variable-length is trivial, the variable-name as well is trivial. A variable is a component itself this way also, and can be accessed through scripts by its variable (or field) name.
The need for VariablesDescriptor is therefore not strictly needed anymore to be part of the Field component.

For SDM, I anyhow require such thing as a solution-field. This field would just be a variable-less field with column-names "Q[0], Q[1], Q[2], Q[3], Q[4]". In fact the solution-vector is thus a variable itself.
Updating and syncing of this field (as well as same-sized residual fields) is trivial, and doesn't change as it was before. Solvers thus don't need to change any algorithms, and the impact is minimal.

The compressible Navier-Stokes equations have equations for rho, rhou, rhov, rhow, rhoE. Storing these solution-variables as separate fields doesn't really make sense, as users are only intersted in more tangible variables (temperature, velocity, pressure).
The equations typically don't use these solution-values anyway computing the residual, but other variables such as rho_u_u, p, sigma, H*u etc.. These values have to be computed on the fly.
If UFEM needs it, the VariablesDescriptor SHOULD stay, but perhaps not anymore as part of the mesh::Field.
If I understood correctly, UFEM works this way already anyway, where VariablesDescriptors are stored in a VariableManager/FieldManager structure, in effect having created a "own" way to define multiple variables in one "solution-variable" or field.

Applying the initial condition of the solution-field correctly is rather not a complexity that is added to the solver, but what a user would expect to do manually with components such as "mesh::actions::InitFieldFunction", or a python loop.
A physics plugin such as NavierStokes, or the UFEM equations, or even a python-script, will have the knowledge of both the equations and the variable ordering, and can make translations from tangible fields such as temperature, velocity, pressure, to the one solution-variable (rho, rhou, rhov, rhow, rhoE) if that is necessary.

Really in practice this will not remove functionality from solver algorithms, but only serve to create new post-proc algorithms that can take better advantage of the fact that a field is a variable.
Users will not fall over the fact that the solution is called Q[0], Q[1], Q[2], Q[3], Q[4] instead.

[wdeconinck]

I propose that the dictionary then just has 2 functions to create fields:

dict.create_field( name, columns ) for ARRAY fields such as the solution

dict.create_field( name, SCALAR )
dict.create_field( name, VECTOR_2D )
dict.create_field( name, VECTOR_3D )
dict.create_field( name, TENSOR_2D )
dict.create_field( name, TENSOR_3D )
and/or
dict.create_scalar_field( name )
dict.create_vector_field( name , dim )
dict.create_tensor_field( name, dim )

[barche]

OK, after thinking about this for almost 3 years, I have to say I agree, changing the API so a field contains a single variable would indeed simplify things. I could work out a proposal in my fork, if that's OK.