[Core] Mixed Generic Criterion - fixing error when dofs and input variables mismatch

[ddiezrod]

📝 Description
There was a bug in our code that took some time to debug. We were sending the wrong variables to the constructor, so as the dofset included different variables, new entries were being added to the mLocalKeyMap as it was using the brackets operator (added new entry if it does not exist). This caused me errors in omp as two threads might try to create this new entry at the same time. Im skipping now the dofs that do not match any of the input variables

[philbucher]

nice catch!

[ddiezrod]

FYI @pooyan-dadvand @pablobecker

[ddiezrod]

Hmm there are some tests failing in @KratosMultiphysics/geomechanics because in some cases they are only checking some variables (WATER_PRESSURE) even if they also have dofs for DISPLACEMENT. I think that is actually a fair use, so maybe instead of throwing an error we should just skip the dof if the variable was not added to mLocalKeyMap. @KratosMultiphysics/technical-committee

[matekelemen]

Why is GetNormValues not const? I would not expect this function to mutate the class' state, so the error is the correct way to go in my opinion.

[ddiezrod]

Why is GetNormValues not const? I would not expect this function to mutate the class' state, so the error is the correct way to go in my opinion.

I agree that the function should be const. But I think its also a fair use that for example in the context of a CFD problem where you have VELOCITY and PRESSURE dofs, for whatever reason you only want to check VELOCITY (that'd throw an error with current implementation in this MR)

[ddiezrod]

I just pushed my suggestion @philbucher @KratosMultiphysics/implementation-committee @KratosMultiphysics/technical-committee

[philbucher]

Why is GetNormValues not const? I would not expect this function to mutate the class' state, so the error is the correct way to go in my opinion.

I agree that the function should be const. But I think its also a fair use that for example in the context of a CFD problem where you have VELOCITY and PRESSURE dofs, for whatever reason you only want to check VELOCITY (that'd throw an error with current implementation in this MR)

perhaps there should be a setting to explicitly ignore these dofs? I feel like just neglecting them silently can cause problems too

[ddiezrod]

perhaps there should be a setting to explicitly ignore these dofs? I feel like just neglecting them silently can cause problems too

Hmm honestly I do not see it. What do you want to do with dofs that do not belong to any of the input variables? You do not even have a target error for those, relative and absolute errors are only defined for input vars...

[philbucher]

perhaps there should be a setting to explicitly ignore these dofs? I feel like just neglecting them silently can cause problems too

Hmm honestly I do not see it. What do you want to do with dofs that do not belong to any of the input variables? You do not even have a target error for those, relative and absolute errors are only defined for input vars...

then you can/should ignore those. Only a suggestion, IMO one should be fully aware of what dofs are used in a simulation, and how the convergence is checked

[philbucher]

nice!

[ddiezrod]

It seems its passing now :) @philbucher

[rubenzorrilla]

Makes perfect sense for me. It is customary to have more DOFs than the ones you might want to actually check (think for instance in any volume coupling problem). My suggestions are purely aesthetic and typos in documentation.

[ddiezrod]

comments addressed @rubenzorrilla ;)

[philbucher]

how about passing the variable? The dof is only used to access the variable

[ddiezrod]

well I used the dof to minimize the duplicated code in the trilinos side, what is the advantage on passing the variable instead?

[philbucher]

More of a philosophical question :)

I try to always pass the least amount of information possible