Open rubenzorrilla opened 2 days 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.
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 isApplyNoSlipProcess
, this is because the name of the file isapply_noslip_process.py
, should beapply_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.
📝 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
).