Changes in FluidDynamicsApplicacion for using it with ROM

[Rbravo555]

Description As discussed, if the same ROM workflow used for structural problems is employed for FluidDynamics, there are some considerations regarding the hyper-reduced order model HROM, .

In this scenario there are some conditions with no assigned element (due to the element selection algorithm used). Therefore, the check on "applications/FluidDynamicsApplication/python_scripts/check_and_prepare_model_process_fluid.py" throws an error.

Is it possible to have a flag that skips automatically this check for ROM models? The check also performs some other tasks like the re-orientation of the normals, should they be inverted.

Additional info

[rubenzorrilla]

@Rbravo555 which is the status of this? I think we fixed some of the issues at some point but not sure if all of them...

[Rbravo555]

As of now, if one uses the serial workflow implemented using the RomAnalysis, the created hyper-reduced model part (using the hrom_training_utility.py line 72: CreateHRomModelParts() ) is not readily usable.

The following problems remain:

• The created HROM model part does not contain ANY conditions, as can be seen in the above image. This results in an error being thrown at assign_vector_by_direction_process.py line 97, namely: "Direction norm is close to 0 in AssignVectorByDirectionProcess."

• On the other hand (Observed in cases other than fluid dynamics), that the hrom_training_utility.py, line 72: CreateHRomModelParts() ( which in turn calls rom_auxiliary_utilities.cpp (line 43) ) is creating a model part containing the Properties of the RootModelPart of the simulations. After the simulation has run, the RootModelPart contains properties that might not be in the core, and therefore, when reading the HROM model part, Kratos complains that it does not recognize the properties in the HROM mdpa.

I came up with a simple fix for the second point as follows: In hrom_training_utility.py, line 72: CreateHRomModelParts(), rather than using the model part of the simulation to create the new model part, use instead the ModelPartIO to read the mdpa file, and from that fresh modelpart, generate the HROM model part which of course does not contain any properties.

For structural mechanics simulations, this naive fix allowed to use the HROM model part as shwon next:

[Rbravo555]

The fluid case can be found here

[rubenzorrilla]

Thanks for the update @Rbravo555. I'll try to take care ASAP.

[rubenzorrilla]

About the assign_vector_by_direction_process.py one I think that it is what is is, that is to say, we cannot ensure that it behaves well in the HROM context if the inwards or outwards automatic detection are used. The point is that it uses the conditions in the model part to calculate the average normal, if there are no conditions, the normal is OFC zero. Also note that in the case that there are some conditions in the HROM model part, the average normal of the FOM simulation and the HROM one wouldn't be the same, so we would be imposing different BCs. In order to use this process in the HROM context we need to ask for an array direction to the user, something that it is already supported. Note that this propagates to the inlet process in the FluidDynamicsApplication.

@KratosMultiphysics/technical-committee maybe we should consider adding a bool type variable (e.g. IS_HROM) to throw meaningful errors in these cases.

About the properties issue, I think we can circumvent it without parsing the mdpa twice (note that this might take a while in large scale models). I'll try to figure out a way, but should be as easy as adding only the properties that are to be used in the HROM model part instead of all the properties in the origin model part.