KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
985 stars 242 forks source link

[All] GetSpecifications and add historical variables to processes #12506

Open rubenzorrilla opened 2 days ago

rubenzorrilla commented 2 days ago

📝 Description This PR implements the GetSpecifications to the processes following the conclusions reached by the @KratosMultiphysics/technical-committee in #11764.

At this moment, this is a draft PR for discussion, so I only show some potential usages. Nevertheless, I think that to properly leverage the mechanism we'd need to register the variables (consider the c++ case in which we right now require to pass through the KratosComponents).

loumalouomega commented 1 day ago

Looks like this is going to have a lot of conflicts due to naming convections. For example there is a test failing because cannot find the process ApplyNoslipProcess, which actual name is ApplyNoSlipProcess, this is because the name of the file is apply_noslip_process.py, should be apply_no_slip_process.py. The problem is relatively easy to solve but would imply to change GUI interface naming and update all tests and cases becuase problems of retrocompatibity, a mesh. One thing could be to generate a derived process with the second name, so it would be retrocompatible but will be little meshy.

rubenzorrilla commented 1 day ago

Looks like this is going to have a lot of conflicts due to naming convections. For example there is a test failing because cannot find the process ApplyNoslipProcess, which actual name is ApplyNoSlipProcess, this is because the name of the file is apply_noslip_process.py, should be apply_no_slip_process.py. The problem is relatively easy to solve but would imply to change GUI interface naming and update all tests and cases becuase problems of retrocompatibity, a mesh. One thing could be to generate a derived process with the second name, so it would be retrocompatible but will be little meshy.

Note that we're already assuming this in the model-parameters factory. In any case, this way of constructing is only used if the item is not registered, which is something that (ideally) won't happen in the future.