code-saturne / code_saturne

code_saturne public mirror
https://www.code-saturne.org
GNU General Public License v2.0
225 stars 82 forks source link

User Field defined with dim > 9 #86

Closed burkhart68 closed 2 years ago

burkhart68 commented 3 years ago

I need to define a surface user field including a number of dimension possibly unlimited (parameter idim1 in cs_user_parameters.f90 of field_create(...) ). It seems impossible for idim > 9, as indicated in cs_path/base/cs_array_reduce.c and cs_path/base/cs_boundary_conditions.c. Is it possible to release this constraint ? Can I just modify this number in the pre-cited files and compile them in my workspace ? Regards, S Burkhart

YvanFournier commented 3 years ago

Hello,

Releasing this constraint would be quite tricky, as we use an implicit logic where dim 1 is a scalar, 3 a vector, 6 a symmetric tensor, and 9 a non-symmetric tensor. This logic is applied when exporting posttprocessing outputs, so relaxing the dimension constraint would require handling all additional cases (for example outputting multiple scalar fields instead) in quite a few places.

A higher dimensional field also assumes the matching values can be solved in a coupled manner (if a variable and not a simple property). To do things cleanly, we could add a field type test value (along with CS_FIELD_VARIABLE, CS_FIELD_PROPERTY, CS_FIELD_INTENSIVE, ... indicating it does not represent a scalar/vector/tensor (any ideas how to name this are welcome).

So you can try modifying the code, and depending on the code paths you go through, things might work, but you can expect many small issues (all easily solved, but possibly numerous). If this actually works well without too many issues, we could integrate this.

Otherwise, in most cases where multiple dimensions are needed, we simply use one scalar field per dimension.

burkhart68 commented 3 years ago

Thanks for the clarifications. I probably will proceed with your last suggestion first. I already noted some limitations to postprocess the fields when idim1 >3 (keyvis put to 1 doesn't work), so it may be safer to keep to the current limitation.

YvanFournier commented 2 years ago

Since the current logic seems OK, I'll close this bug now.

We can reopen it if this becomes an issue.